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.)
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’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.