[qt/qt/qtbase]: Summary of bulk changes made

KDE Git Services - Bulk Change <[email protected]>
Newsgroups gmane.comp.kde.cvs
Message-ID <[email protected]>
Git repository change summary for qt/qt/qtbase
Pushed by mirror-service into branch '6.12'.
Changed from 5cd1efb7cf1ab5c5a0fdb8bb8bbf593ed458432e to 3624cfe1a407e595cb973451f7a2bfbf03145219
Acknowledgement was received that this change introduces only existing code that has been pushed to another public open source repository.

This change contains the following new commits:

Git commit d17644917a00ef41dac1bed21eaeb65cd2bce01d by Qt Cherry-pick Bot (on behalf of Laszlo Agocs) on 01/08/2026 at 22:51..
rhi autotest: Do not read back an uninitialized cubemap face

renderToTextureCubemapFace reads back not only the face it renders
into, but also another one, in order to verify that the layer
parameter is not ignored. That face was never written to, and so the
results of reading it back are undefined. With D3D12 it also makes the
debug layer complain, because the subresources of a placed resource
must be initialized with a Discard, Clear, or Copy operation before
they can be used for anything else.

Upload a known content to that face instead. This is a Copy, so it
initializes the subresource, and it makes the readback result
deterministic, which allows checking the uploaded color as well.

Pick-to: 6.11 6.8
Change-Id: Ia0b5e21a3d57e3c598903242a77acb92736f2b70
Reviewed-by: Andy Nichols <[email protected]>
(cherry picked from commit b96197efff3b5ac03d554df92c6fa444e64ef711)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/d17644917a00ef41dac1bed21eaeb65cd2bce01d

Git commit b1433c8016909d971a148d56418a3b9e96a92518 by Qt Cherry-pick Bot (on behalf of Laszlo Agocs) on 01/08/2026 at 22:51..
rhi: d3d12: Fix descriptor aliasing in the CPU descriptor pool

In QD3D12CpuDescriptorPool::allocate() only marks the first descriptor
as used. This is incorrect when count > 1 since a later allocate() would
then hand out entries still marked as free that are in fact in use.

Then, allocate() hands out descriptors in two ways: while the last heap
has enough room at the end, it takes [head..head + count) via
QD3D12DescriptorHeap::get(), which advances head and never consults the
bitmap; when it does not, it scans the bitmaps of all heaps for a free
run instead and returns that via QD3D12DescriptorHeap::at(), which
leaves head untouched. The get() based path is only safe if heap.head is
advanced when hitting the other (at()-based) path. This is currently
missing, so add it.

None of these are a problem in practice atm, because every call site
passes count == 1, which hides the issues since a successful bump test
already implies head < capacity. Fix it nonetheless.

Change-Id: Iedb7b5ab83b14545d518e58969b3ca2ba5576f90
Reviewed-by: Andy Nichols <[email protected]>
(cherry picked from commit a7f4d5bd760974b0591b35b9100da98897846656)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/b1433c8016909d971a148d56418a3b9e96a92518

Git commit 2ae2439a831d26d5a29eba5e5cbde3c189a25f49 by Qt Cherry-pick Bot (on behalf of Laszlo Agocs) on 01/08/2026 at 22:51..
rhi: d3d12: Cache the srb-to-binding translation

setShaderResources() ran QD3D12ShaderResourceVisitor over all bindings
for all stages on every call. With typical QRhi-based renderers, such as
Qt Quick, that in many cases mean once per draw call because consecutive
draws use different srbs, and so srbChanged is very often true.

Do this only once. The result of the binding visitors now lives in
QD3D12ShaderResourceBindings::bindingCache and is rebuilt only when the
srb or the pipeline it is used with changes. The callbacks that collect
it move from QD3D12CommandBuffer to the srb and are renamed to cache*,
so QD3D12CommandBuffer::VisitorData is gone altogether.

What is cached must not depend on the frame slot or on the dynamic
offsets, so the uniform buffer entries keep the QRhiBuffer and the
binding number, and both the per-frame-slot resource and the dynamic
offset are resolved when binding.

Caching means a resource recreated (as in, the renderer calling
QRhiBuffer::create() again after setting a different size, for example)
without the srb itself being touched has to invalidate it. Follow the
D3D11 backend and track the id and generation of each bound resource,
checked in the loop that walks the bindings for the barriers anyway.
QD3D12Texture already had a generation that was never read; QD3D12Buffer
and QD3D12Sampler had none, so add and bump those.

lastUsedGraphicsPipeline and lastUsedComputePipeline now clear each
other, otherwise a graphics, compute, same-graphics sequence on one srb
reports no pipeline change on the third bind and would get the cache
built for the compute pipeline. And a new lastUsedPipelineGeneration
catches a pipeline recreated in place.

Also, copy the SRVs into the shader-visible heap with a single
CopyDescriptors instead of one CopyDescriptorsSimple per descriptor.

Results with a heavy qmlbench test scene on one particular machine:
changing_over_isolated_with_clip_rotated:
OpenGL       1176
Vulkan       1980
D3D11        1543
D3D12 before 1867
D3D12 after  2193

With QCanvasPainter's qcpainterbench, default window size,
item count set to 64:
OpenGL       54
Vulkan       78
D3D11        58
D3D12 before 67
D3D12 after  78

Change-Id: I91c88b1e7d7cced5777b1306b5adfd7aa51a9bb9
Reviewed-by: Andy Nichols <[email protected]>
(cherry picked from commit b6b81f00cd396c98f0f3492461a88559c27fcf46)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/2ae2439a831d26d5a29eba5e5cbde3c189a25f49

Git commit a8b7fcabc770abf8630e8eb6fb4738e8659bc887 by Qt Cherry-pick Bot (on behalf of Laszlo Agocs) on 01/08/2026 at 22:51..
rhi: d3d12: Batch the transition barriers in setShaderResources

QD3D12ResourceBarrierGenerator exists to collect transition barriers and
submit them as one ResourceBarrier() call, but the call site defeated
that: the enqueue sat inside the loop over the bindings, so N textures
needing a transition produced N calls with one barrier each instead of
one call with N. Barrier batching is worth real GPU time, on AMD and
Intel in particular. beginPass() already does it the right way.

Move the enqueue out of the loop. The reason for not doing this before
were probably the UAV barriers issues from within the loop, and
attempting to keep a strict ordering for all the barriers. But that is
not a problem in practice.

Change-Id: Ia2ae09c89d9be9bf5676b214c525b161b16f5b7b
Reviewed-by: Andy Nichols <[email protected]>
(cherry picked from commit d3e20737be0d3d2e6a287add51dc2a6d491a2dc9)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/a8b7fcabc770abf8630e8eb6fb4738e8659bc887

Git commit 3624cfe1a407e595cb973451f7a2bfbf03145219 by Qt Cherry-pick Bot (on behalf of Tor Arne Vestbø) on 01/08/2026 at 22:51..
visionOS: Use the Swift driver to generate the bridging header

We were invoking swiftc with -frontend, which bypasses the driver.
The driver is what works out the macro plugin search paths for the
target platform, passing -plugin-path, -external-plugin-path, and
-in-process-plugin-server-path on to the frontend.

Without them the frontend can't expand any Swift macros, which broke
as of the Xcode 27 SDKs, where SwiftUI's @State is a macro rather
than a property wrapper:

    error: external macro implementation type 'SwiftUIMacros.StateMacro'
    could not be found for macro 'State()'; plugin for module
    'SwiftUIMacros' not found

Passing the plugin paths ourselves is not much of an option, as
SwiftUIMacros lives in the platform directory rather than the
toolchain, so it needs the per-platform -external-plugin-path with
the plugin server path appended. We let the driver work it out.

Pick-to: 6.11
Change-Id: I98ba5c3bc8d9a9d0ff8f4b0caf3a28f6e3e49090
Reviewed-by: Alexandru Croitor <[email protected]>
(cherry picked from commit ebeca6b9490146c3f46b52b8a317f2d60ff8c595)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/3624cfe1a407e595cb973451f7a2bfbf03145219
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.