Introduce per-component CI_BUILD_COMPONENTS_* variables to allow
more flexible composition of CI_BUILD_COMPONENTS, and add these to
every container job by listing them in .container.
Also rework the -arm64 and -x86_64 definitions, which were still
based on the old kernel+rootfs layout. Split them into -gl and -vk,
but keep -arm32, which builds fewer components.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34813>
Replace HWCI_KVM="true" with HWCI_ENABLE_X86_KVM=1 for consistency with
other integer-based toggles (e.g. HWCI_START_WESTON,
PARALLELISE_VIA_LP_THREADS).
The new name also makes the variable’s purpose clearer by explicitly
referencing X86.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34813>
Including the kernel image in test-base requires rebuilding every
x86_64 container image on each kernel uprev, even though only the
crosvm jobs use this kernel.
Move the download to runtime and update the distribution tags to avoid
triggering container rebuilds on kernel changes.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34813>
This improves blend shader performance slightly over loading the
constants from the sysval UBO. On bifrost, we have 128 FAU words, so
reserving 4 words for blend constants is not a significant cost. On
midgard, register mapped uniforms share space with working registers.
With high working register pressure, we only allocate 32 uniform
registers, and so would lose 1/8 of available space to blend constants
if we implemented the same optimization.
This improves gfxbench gl_driver FPS on G610 from 40.48 to 42.39. I did
not measure any regressions on benchmarks I tested that did not use
blend shaders.
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Ryan Mckeever <ryan.mckeever@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34666>
This is similar to the approach in panvk, where we pass blend constants
to the blend shader in fixed FAU slots instead of specializing the
shader on blend constants. TODO: explain midgard stuff
This eliminates the blend shader variant cache, which performed very
badly when the working set of blend constants in an application was >32
(the maximum number of variants stored). Just increasing the cache size
like we did in f1f39fa645 ("panfrost: Increase the limit for blend
shader variants") would help for applications with a larger static set,
but we would still have cache thrashing on applications which change the
blend constants dynamically.
For gfxbench gl_driver, which uses 386 blend constant values, this
improves FPS on a G610 from 6.06 to 40.48. Most applications are
unaffected, because they don't use enough constant values to cause
thrashing.
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Ryan Mckeever <ryan.mckeever@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34666>
We want the sysval UBO at a fixed index in order to pass dynamic blend
constants to blend shaders, which share UBOs with the fragment shader.
This requires shifting the existing UBOs to make space for a new UBO at
a low index. This remapping happens late, once we know whether sysvals
are actually used by a variant, so applications still use the original
indices.
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Ryan Mckeever <ryan.mckeever@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34666>
This warning message has been annoying people for a long time. Let's
just get rid of it. I don't think it's really helping anyone with
anything and it's just burning logging space.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34853>
We represent vectors as packed anyway so all these ops are just data
motion that we already know how to do. Calling into NIR for these
doesn't really help. It also avoids potential optimization loops in NIR
where pack op lowering conflicts with itself. It's simpler just to
handle it all in the back-end and trust our prmt optimization and copy
propagation to clean it all up.
Reviewed-by: Mel Henning <drawoc@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34849>
The vdrm_vpipe_connect() prototype defined in vdrm.c doesn't match
vdrm_vpipe_connect() defined in vdrm_vpipe.c. This leads to a compilation
warning about the wrong proto when Mesa linked with enabled LTO. Fix the
vdrm_vpipe_connect() definition.
Fixes: bf0e3d6274 ("virtio/vdrm: Add vtest backend")
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34819>
When copying between buffers, find the biggest possible block size usable
for all copy regions. A common block size is used since using different
block sizes can require additional flushing between different blocks.
Besides the single-byte and 4-byte block sizes, also allow for 16-byte
block size and the appropriate corresponding format. Using bigger block
size when possible helps potentially reduce the number of required
CP_BLIT operations. Tested on the Crucible benchmarks, especially for
larger copy regions this can improve throughput up to 3x.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34587>
Will be useful if app doesn't specify depth direction correctly.
E.g. the capture of "Sons of The Forest" I have has a shader
where `gl_FragDepth` has `layout(depth_less)`, but the output for different
fragments is actually sometimes less, sometimes more than the original depth
by a tiny margin.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34423>
Specifying depth write direction in shader may help us. E.g.
If depth test is GREATER and FS specifies FRAG_DEPTH_LAYOUT_LESS
it means that LRZ won't kill any fragment that shouldn't be killed,
in other words, FS can only reduce the depth value which could
make fragment to NOT pass with GREATER depth test. We just have to
enable late Z test.
There is the same concept in D3D11 and it is seen e.g. in "Stray" game.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34423>
Add a debug option which checks the status of a command buffer, if
it has completed execution on the GPU, before it's reset or
destroyed.
This works by getting the GPU to write to a specific memory address
on vkBeginCommandBuffer and vkEndCommandBuffer, so the CPU can check
that the GPU has written the TU_CMD_BUFFER_STATUS_IDLE to the slot
before actually resetting or freeing the command buffer.
This can to help in debugging sync issues within the driver.
Signed-off-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34383>
This is getting complicated and depends on some inter-linked details for
safety such as values being in-range. It's safer if the rest of the IR
is forced to use public interfaces.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34794>
Collabora's Gfx CI Team