Thank you for your report. This does not seem to be a legitimate driver behavior. Would you mind providing an example application which reproduces this issue? Modifying SDK's cube application to do the job would be just fine.
Attached is a simple application which displays a 24-bit 512x512 BMP file using 1 of 4 methods using the variables enable_transfer_queue and use_buffer_copy:
enable_transfer_queue makes use of the first available queue family for transfer operations only.
use_buffer_copy adds a intermediate buffer to move data from host memory to device memory.
Possible transfer configurations:
* Buffer (host-visible) ===> Image (device-local)
* Buffer (host-visible) ===> Buffer (device-local) ===> Image (device-local)
Because the minimum image transfer granularity on my transfer queue family is (8, 8, 8), I transfer a 3D image with a depth of 8 and simply blit the 1st layer to the swap chain.
The problem is that enable_transfer_queue=true and use_buffer_copy=false does not work.
main2.cpp.zip 6.6 KB
OK, so this one is an issue we recently fixed. I'm not sure if the necessary changes have already gone out, but what I certainly can tell is that the driver you are using is outdated :-) Please consider checking if you can reproduce the problem with the latest driver version (APU)
I get the same behavior.
I've been using [Radeon Software Crimson Edition 16.7.3 Driver Version 16.30.2311] for the past week to no avail.
I upgraded to [Radeon Software Crimson Edition 16.8.3 Driver Version 16.30.2511] today to re-test the issue.
Vulkan Device Properties:
* MD5: be12504d74301bcc97f5ebeec17ce6b9