Vulkan errors report

Actually the spec allows this for linear tiling :

Images created with tiling equal to VK_IMAGE_TILING_LINEAR have further restrictions on their limits and capabilities compared to images created with tiling equal to VK_IMAGE_TILING_OPTIMAL. Creation of images with tiling VK_IMAGE_TILING_LINEAR may not be supported unless other parameters meet all of the constraints:

imageType is VK_IMAGE_TYPE_2D
format is not a depth/stencil format
mipLevels is 1
arrayLayers is 1
samples is VK_SAMPLE_COUNT_1_BIT
usage only includes VK_IMAGE_USAGE_TRANSFER_SRC_BIT and/or VK_IMAGE_USAGE_TRANSFER_DST_BIT
Implementations may support additional limits and capabilities beyond those listed above. To determine the specific capabilities of an implementation, query the valid usage bits by calling vkGetPhysicalDeviceFormatProperties and the valid limits for mipLevels and arrayLayers by calling vkGetPhysicalDeviceImageFormatProperties.

In my case the driver reports linear tiling support for VK_IMAGE_USAGE_SAMPLED_BIT for RGBA8 format. Unfortunatly the mipLevel constraint applies.
The backend should not only check for VkFormatProperties::linearTilingFeatures bits but also calls vkGetPhysicalDeviceImageFormatProperties (https://www.khronos.org/registry/vulkan/...Properties ).

I tried to enforce optimal tiling for sampled image here :

https://github.com/RPCS3/rpcs3/blob/mast...e.cpp#L226

but then it crashes in this block:
https://github.com/RPCS3/rpcs3/blob/mast...e.cpp#L375

Actually the spec allows this for linear tiling :

Images created with tiling equal to VK_IMAGE_TILING_LINEAR have further restrictions on their limits and capabilities compared to images created with tiling equal to VK_IMAGE_TILING_OPTIMAL. Creation of images with tiling VK_IMAGE_TILING_LINEAR may not be supported unless other parameters meet all of the constraints:

imageType is VK_IMAGE_TYPE_2D
format is not a depth/stencil format
mipLevels is 1
arrayLayers is 1
samples is VK_SAMPLE_COUNT_1_BIT
usage only includes VK_IMAGE_USAGE_TRANSFER_SRC_BIT and/or VK_IMAGE_USAGE_TRANSFER_DST_BIT
Implementations may support additional limits and capabilities beyond those listed above. To determine the specific capabilities of an implementation, query the valid usage bits by calling vkGetPhysicalDeviceFormatProperties and the valid limits for mipLevels and arrayLayers by calling vkGetPhysicalDeviceImageFormatProperties.

In my case the driver reports linear tiling support for VK_IMAGE_USAGE_SAMPLED_BIT for RGBA8 format. Unfortunatly the mipLevel constraint applies.
The backend should not only check for VkFormatProperties::linearTilingFeatures bits but also calls vkGetPhysicalDeviceImageFormatProperties (https://www.khronos.org/registry/vulkan/...Properties ).

I tried to enforce optimal tiling for sampled image here :

https://github.com/RPCS3/rpcs3/blob/mast...e.cpp#L226

but then it crashes in this block:
https://github.com/RPCS3/rpcs3/blob/mast...e.cpp#L375

Its odd that it crashed; even with optimal tiling, writing data usually goes okay on radeon, just that textures display as garbage. Memory layout issues maybe? To use mipmaps, it seems every layer will have to be uploaded individually, so the staging texture should have only one mipmap level in cases where linear tiling is limited to 1 mipmap level. The resulting allocated block with linear tiling may be too small to actually fit all the miplevels since the texture is only allowed one level. You could try forcing the texture upload functions to only deal with one mipmap level and see if it works ok.

Hey All!
I tryed new builds and 74affbbf there is a crash the entire system (full reset PC) when working on the emulator api Vulkan. Builds on earlier does not. Checked several times - crash stable.
[Image: 754EBA51-E52D-1453-C5BB-6F94D28204B1.jpg]
---
Spec: Intel i3-3240, gtx 750ti, 8Gb ram, win7 x64 and win10 x64 pro, driver Nvidia 364.51 with Vulkan support

Hey All!
I tryed new builds and 74affbbf there is a crash the entire system (full reset PC) when working on the emulator api Vulkan. Builds on earlier does not. Checked several times - crash stable.
[Image: 754EBA51-E52D-1453-C5BB-6F94D28204B1.jpg]
---
Spec: Intel i3-3240, gtx 750ti, 8Gb ram, win7 x64 and win10 x64 pro, driver Nvidia 364.51 with Vulkan support

There are known problems with the given PR. You should only use the latest master build for testing.

There are known problems with the given PR. You should only use the latest master build for testing.

Thanks!
---
Update
Oops. Last Master build It does not start nothing, both vulkan and opengl.
That the best (for me at least) is build 779a30aa
Fixed

I see improvement of the work of the Vulkan api, but still only half of the screen Bomberman
[Image: CB3207FC-BA85-ED26-C191-BD3078E4F45D.jpg][Image: E26787C3-17FB-3ED1-A8A0-6045C7989059.jpg][Image: BA084766-7E3B-5394-1764-23A7E8609873.jpg]

BTW the big issue with Vulkan (the API not the backend) is that it lacks feature level equivalent.
If some Vulkan code works on a specific gpu there is virtually no way to ensure that it will also work on another one even from the same ihv and generation. The debug layers only check limits for the currently running device.

This means it's very important to check Vulkan backend as often as possible on as much gpus as possible.