From 8e27e31649f68470e8e2caf955d272da4a990637 Mon Sep 17 00:00:00 2001 From: Laszlo Agocs Date: Mon, 6 Mar 2023 19:00:29 +0100 Subject: [PATCH] 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 --- tests/auto/gui/rhi/qrhi/tst_qrhi.cpp | 32 ++++++++++++++++++---------- 1 file 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 ca5f48dc3e0..f0b9904834f 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] {