rhi: Add basic support for specifying a view format for a texture

We have to be able to strip the _SRGB nonsense from the render target
view formats when rendering into textures that are provided from an
external engine (e.g. OpenXR) and are forced onto us with formats such
as VK_FORMAT_R8G8B8A8_SRGB.

This highlights some limitation of the current system, which has very
limited handling of sRGB stuff since proper renderers such as Qt Quick
3D have first class support for linearization and converting to sRGB
at the end of their shading pipeline, so _SRGB format textures are
never used in practice.

OpenGL has an issue which is different from everything else, namely
that we do not correctly do the glEnable/Disable on GL_FRAMEBUFFER_SRGB.
The QOpenGLExtensions flag is not what we need. We need to know if the
sRGB-conversion-on-write is supported or not, not that some framebuffer
is sRGB-capable. So do our own query based on the desktop and the ES
extension (GL_EXT_sRGB_write_control is something we never checked for,
but that is the appropriate GLES extension, supported on the Quest 3
for instance) This is now corrected in the gl backend. This means that
the colors will no longer be "too bright" with OpenGL ES and multiview
on the Quest 3 for example.

Unlike OpenGL, Vulkan and D3D automatically convert in shader reads and
writes when the shader resource view or the render target view has a
_SRGB format. (which we get by default since we pass on the texture
format) Getting a second linear->sRGB conversion on the already sRGB
data generated by e.g. Qt Quick 3D is just wrong.

Allow solving this by a new function that can be optionally called to
say we want (RGBA8, srgb=false), i.e. VK_FORMAT_R8G8B8A8_UNORM, for
the views.

Of course, reality is more complicated. D3D11 for instance does not
allow "casting" a fully typed texture, we'd need to use a _TYPELESS
format for that (possibly with other consequences), so skip D3D11.
For D3D12 this should work from Windows 1703 on.

Implementing for Metal is also left as a future exercise - it is neither
needed at the moment within Qt, nor is it trivial, because view textures
have to be created explicitly in Metal, normally we just work with the
MTLTexture as-is, not with views.

Task-number: QTBUG-122288
Task-number: QTBUG-122614
Change-Id: I8aea4e892b308d48f0bf18bdef481e460fbc9d47
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>

1 files changed, 5 insertions, 1 deletions

diff --git a/src/gui/rhi/qrhivulkan_p.h b/src/gui/rhi/qrhivulkan_p.h
index d2b91a424e..a364634676 100644
--- a/src/gui/rhi/qrhivulkan_p.h
+++ b/src/gui/rhi/qrhivulkan_p.h
@@ -103,7 +103,7 @@ struct QVkTexture : public QRhiTexture
 
     bool prepareCreate(QSize *adjustedSize = nullptr);
     bool finishCreate();
-    VkImageView imageViewForLevel(int level);
+    VkImageView perLevelImageViewForLoadStore(int level);
 
     VkImage image = VK_NULL_HANDLE;
     VkImageView imageView = VK_NULL_HANDLE;
@@ -124,6 +124,8 @@ struct QVkTexture : public QRhiTexture
     VkFormat vkformat;
     uint mipLevelCount = 0;
     VkSampleCountFlagBits samples;
+    VkFormat viewFormat;
+    VkFormat viewFormatForSampling;
     int lastActiveFrameSlot = -1;
     uint generation = 0;
     friend class QRhiVulkan;
@@ -212,6 +214,7 @@ struct QVkTextureRenderTarget : public QRhiTextureRenderTarget
 
     QVkRenderTargetData d;
     VkImageView rtv[QVkRenderTargetData::MAX_COLOR_ATTACHMENTS];
+    VkImageView dsv = VK_NULL_HANDLE;
     VkImageView resrtv[QVkRenderTargetData::MAX_COLOR_ATTACHMENTS];
     int lastActiveFrameSlot = -1;
     friend class QRhiVulkan;
@@ -996,6 +999,7 @@ public:
                 VkFramebuffer fb;
                 VkImageView rtv[QVkRenderTargetData::MAX_COLOR_ATTACHMENTS];
                 VkImageView resrtv[QVkRenderTargetData::MAX_COLOR_ATTACHMENTS];
+                VkImageView dsv;
             } textureRenderTarget;
             struct {
                 VkRenderPass rp;