Add workaround for threeDimTexture case failing with some drivers

Not relevant for the CI as that does not run with any real Vulkan
implementation. (and Lavapipe works if that's used)

As the investigation in the Jira issue shows, there is no proper
conclusion yet on why rendering to a slice of a 3D texture breaks
the content of other slices that have image data written to them
before that render pass targeting the slice. It would seem that
transitioning to COLOR_ATTACHMENT_OPTIMAL has some unexpected
consequences for slices that are not targeted by the render pass
with Mesa on Intel.

(NB rendering to a given 3D texture slice works via
VK_IMAGE_CREATE_2D_ARRAY_COMPATIBLE_BIT; and how often this is needed
in practice is unclear, typical volume rendering cases will anyway
likely just upload data to the slices of a 3D texture, not rendering
to them)

The problem is still clearly visible in the tex3d manual test (when run
on affected Linux machines), this we keep unchanged for the time being
so that the issue can be examined further. However, the autotest is
changed to prevent the issue from occurring (render to slice first,
then upload to other slices) since it causes confusion when the test
is run locally on various developer machines.

Pick-to: 6.5
Task-number: QTBUG-111772
Change-Id: I4dc4c2413f8c518f377a33065992ad786a5ff44f
Reviewed-by: Andy Nichols <andy.nichols@qt.io>

1 files changed, 21 insertions, 11 deletions

diff --git a/tests/auto/gui/rhi/qrhi/tst_qrhi.cpp b/tests/auto/gui/rhi/qrhi/tst_qrhi.cpp
index ca5f48dc3e..f0b9904834 100644
--- a/tests/auto/gui/rhi/qrhi/tst_qrhi.cpp
+++ b/tests/auto/gui/rhi/qrhi/tst_qrhi.cpp
@@ -4828,26 +4828,36 @@ void tst_QRhi::threeDimTexture()
         rt->setRenderPassDescriptor(rp.data());
         QVERIFY(rt->create());
 
-        QRhiResourceUpdateBatch *batch = rhi->nextResourceUpdateBatch();
-        QVERIFY(batch);
-
-        for (int i = 0; i < DEPTH; ++i) {
-            QImage img(WIDTH, HEIGHT, QImage::Format_RGBA8888);
-            img.fill(QColor::fromRgb(i * 2, 0, 0));
-            QRhiTextureUploadEntry sliceUpload(i, 0, QRhiTextureSubresourceUploadDescription(img));
-            batch->uploadTexture(texture.data(), sliceUpload);
-        }
-
+        // render to slice 23
         QRhiCommandBuffer *cb = nullptr;
         QVERIFY(rhi->beginOffscreenFrame(&cb) == QRhi::FrameOpSuccess);
         QVERIFY(cb);
-        cb->beginPass(rt.data(), Qt::blue, { 1.0f, 0 }, batch);
+        cb->beginPass(rt.data(), Qt::blue, { 1.0f, 0 });
         // slice 23 is now blue
         cb->endPass();
         rhi->endOffscreenFrame();
 
+        // Fill all other slices with some color. We should be free to do this
+        // step *before* the "render to slice 23" block above as well. However,
+        // as QTBUG-111772 shows, some Vulkan implementations have problems
+        // then. (or it could be QRhi is doing something wrong, but there is no
+        // evidence of that yet) For now, keep the order of first rendering to
+        // a slice and then uploading data for the rest.
+        QRhiResourceUpdateBatch *batch = rhi->nextResourceUpdateBatch();
+        QVERIFY(batch);
+        for (int i = 0; i < DEPTH; ++i) {
+            if (i != SLICE) {
+                QImage img(WIDTH, HEIGHT, QImage::Format_RGBA8888);
+                img.fill(QColor::fromRgb(i * 2, 0, 0));
+                QRhiTextureUploadEntry sliceUpload(i, 0, QRhiTextureSubresourceUploadDescription(img));
+                batch->uploadTexture(texture.data(), sliceUpload);
+            }
+        }
+        QVERIFY(submitResourceUpdates(rhi.data(), batch));
+
         // read back slice 23 (blue)
         batch = rhi->nextResourceUpdateBatch();
+        QVERIFY(batch);
         QRhiReadbackResult readResult;
         QImage result;
         readResult.completed = [&readResult, &result] {