When creating the framebuffer, I am selecting the format VK_FORMAT_B8G8R8A8_SRGB for the color attachment. Once set-up, color values rendered into that framebuffer get gamma corrected before being stored in the color attachment.
On Nvidia and Intel GPUs, everything works as expected. But with an AMD RX 550, the color values do not get gamma corrected before being stored (although the format is the same as stated above; and the format is supported by the physical device). Could there be something that needs to be enabled explicitly with a framebuffer, renderpass, or graphics pipeline to enable proper sRGB conversion also on the AMD RX 550?
Should actually just setting the format to an sRGB format be enough to instruct the GPU to perform gamma correction, or must it be enabled explicitly somehow? (On Nvidia and Intel, that wasn’t required so far… but maybe it just worked coincidentally? There are no validation errors, though.)
How do you know that? Is the attachment a swapchain image? If not, do you copy this image to a swapchain image, and if so, how? And what is the format of the swapchain image?
I just compare the resulting rendering from an Intel GPU and an Nvidia GPU to the result of the AMD RX 550. Gamma correction is performed with the former two, but not with the RX 550.
Choosing non-sRGB formats on Intel/Nvidia produces a different result (darker) than using an sRGB format. On AMD, both non-sRGB and sRGB produce the very same (dark) result.
Yes, it is a swapchain image that is rendered into directly with an ordinary graphics pipeline.
VK_FORMAT_B8G8R8A8_SRGB and VK_COLOR_SPACE_SRGB_NONLINEAR_KHR
(same as on Intel, same as on Nvidia)
Were you able to solve it?
I am wondering if there is something that needs to be enabled (like glEnable(GL_FRAMEBUFFER_SRGB) in OpenGL), or if just selecting an sRGB format for the framebuffer attachment (like it works on Intel and Nvidia) is sufficient, i.e., the proper way to go in Vulkan for enabling gamma correction?
P.S.: I am obviously replyig to a spam account ^^
P.P.S.: The spam post is now gone (just in case you are wondering)
I have always only rendered on the AMD GPU, but presented through a different GPU when the problems occured.
If I render on AMD → present through AMD => all good.
If I render on NVIDIA → present through AMD => all good.
If I render on AMD → present through NVIDIA => sRGB conversion broken/does not happen when drawing into the swap chain image with an ordinary renderpass, which is in format B8G8R8A8_SRGB.
Now I wonder if this is an AMD-driver issue or if it could also be some other driver’s issue.
Whom shall I report this problem to?
I’m not doing anything special, actually. I am just requesting swap chain images and render into them with a render pass using the AMD GPU as VkPhysicalDevice/VkDevice.
When I write that I “present through NVIDIA” I mean that the monitor is connected to the NVIDIA GPU. So in some way, the presentation must go through the NVIDIA GPU, which to me as programmer is handled transparently by the operating system/presentation engine/whatever.
But I noticed that the sRGB conversion problem does not exist if I plug the monitor into the AMD GPU (regardless if i use the NVIDIA GPU or the AMD GPU as VkPhysicalDevice/VkDevice).
handled transparently by the operating system/presentation engine/whatever.
Is it though? Last time I have been trying something like this, it requires something like LucidLogix driver installed or something to make it happen. And as I remember it was always hairy. I used to get like 5 s of latency when trying to crosspresent one way.
Anyway, yea. Sounds like a driver problem. Whichever driver component is dealing with this…
As far as I can tell, yes! I’m doing it all the time. I have two GPUs in my PC and often switch between the two in the physical device selection stage of my Vulkan application(s). The monitor mostly stays connected to the NVIDIA GPU.
But I tested it the other way round as well, getting the results described above. I have yet to test what happens if I have two AMD GPUs in my system, render on #1 and present through #2.
How exactly it is handled by whichever driver component I don’t know. But I think, an B8G8R8A8_SRGB image is an B8G8R8A8_SRGB image—and therefore, automatic gamma correction should be applied in any case when rendering into it.
PS: I wonder what happens if you try to disable VK_LAYER_NV_optimus and VK_LAYER_AMD_switchable_graphics layers. They could be dealing with this nowadays. I don’t really know anymore…
So, don’t know what else I should try… I should probably open an issue w.r.t. AMD Vulkan drivers. You don’t happen to know where the right place for that is, do you?
They have a bug report link which I think is now accessible in the Radeon Software. But they never get back to you except a “feedback received” email.
