The skqp runner gets us parallel execution, automatic caselist handling,
nice reports, and the same xfail/flake handling you know and love from
deqp and piglit.
And, now that we have flake handling, we can turn the tests back on!
Reviewed-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20070>
The skqp runner gets us parallel execution, automatic caselist handling,
nice reports, and the same xfail/flake handling you know and love from
deqp and piglit.
Reviewed-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20070>
The skqp runner gets us parallel execution, automatic caselist handling
(which would have prevented a recent regression due to some skqp tests
having been forgotten in the checked in caselists), nice reports, and the
same xfail/flake handling you know and love from deqp and piglit.
Reviewed-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20070>
Some GL entrypoints would be aliased in an API sense but have different
GLX protocol. The only one that matters to us is EXT_texture_object,
which is the pre-GL-1.1 API. We're just going to drop support for that
and assume you have 1.1 or better, since 1.0 + EXT_texture_object is a
vanishingly rare combo at this point.
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20300>
This is sort of a spiky way to do it, but the effect is to send the
appropriate SetClientInfo twice for indirect screens, where the second
one fills in the GL extensions. We can get away with this because the
only place the string is used is when the server computes the reply for
glGetString(GL_EXTENSIONS), which never matters for direct contexts.
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20300>
GLX is a means to the end of direct rendered GL, really. Our indirect
protocol support has been largely untouched forever, anyone who wants it
can find it in amber. We're not going to drop or intentionally break it
(indirect support), but we're also not going to try super hard to
preserve its quirks anymore.
xserver has typically supported GLX 1.4 since 2009 (xserver 1.8, ad5c0d9e)
and unconditionally since 2016 (xserver 1.19, 36bcbf76). Assuming GLX
1.3 internally will let us fix some GLX drawable lifetime issues.
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20300>
It's not our job to filter this out, it's the server's job to not send
events that haven't been selected for. We'll still throw the event away
if we don't have any client-side state for it though.
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20300>
We currently convert it twice for unknown reasons, first when
translating from TGSI and later in constant folding. Not only is this
unnecessary, the first translation doesn't check for non-native
swizzles, so removing it actually saves few instructions and gains
a single Unigine shader for R300 at the expense of few more constant
loads and temps.
Also fixes few dEQPs because we could previously generate code like
TEX temp[1], none.01__, 2D[0];
and the native swizzle rewrite pass was not ready for it.
RV370 shader-db:
total instructions in shared programs: 84441 -> 84436 (<.01%)
instructions in affected programs: 63 -> 58 (-7.94%)
helped: 4
HURT: 0
total temps in shared programs: 12398 -> 12400 (0.02%)
temps in affected programs: 10 -> 12 (20.00%)
helped: 1
HURT: 3
total consts in shared programs: 79081 -> 79090 (0.01%)
consts in affected programs: 12 -> 21 (75.00%)
helped: 0
HURT: 7
GAINED: shaders/tropics/465.shader_test FS
No shader-db change with RV530.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Tested-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20484>
Texturing instructions can't read from constant sources, however this
can work when the constant was transformed to constant swizzles and
hence RC_FILE_NONE.
Prevents a regression in single Unigine Tropics shader that uses
constant (0.5,0.5) as a TEX coordinate in a next patch. We now
convert to constant swizzles twice, first when translating from TGSI
and than in constant folding. If we disable the first conversion
rc_transform_tex will emit a mov from constant to temporary. With this
patch, copy propagate will clean it up later.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Tested-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20484>
Transforming
0: MOV temp[1], -none.1111;
1: KIL temp[1];
to
0: KIL -none.1111;
Doesn't work on R300 while it works just fine with R500.
Prevents a regression when we enable the copy propagate of RC_FILE_NONE
to texture instructions in the next commit.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Tested-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20484>
Similar to 1387d1d4, this offset was being applied twice (once in
translate_generic, and once when the buffer is mapped).
This fixes 7972, which was initially thought to be an endianness
specific issue.
CC: mesa-stable
Tested-by: Filip Gawin <filip@gawin.net>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20468>
This was found while debugging venus-lavapipe ci failure. It's a real
bug though no tests have caught this yet, but fixing this would regress
venus-lavapipe non-templated push tests if without the dependent lvp
fix. The sampler in the descriptor write can be garbled if the binding
has immutable samplers.
cc: mesa-stable
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Corentin Noël <corentin.noel@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20471>
The issue is hidden due to a overly relaxed cts:
dEQP-VK.binding_model.shader_access.primary_cmd_buf.with_push*
that doesn't scrub the sampler from descriptor writes for immutable
samplers. The issue is exposed via venus-lavapipe ci because venus must
ignore the potentially garbled sampler. This change aligns the
VK_DESCRIPTOR_TYPE_SAMPLER path with the
VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER path by removing a false check
against the provided sampler from push since the sampler can be null. An
alternative is to also check against !binding->immutable_samplers there.
Test: venus-lavapipe with venus push descriptor support
cc: mesa-stable
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20471>
This probably could/should be split up into multiple commits, but
it's simpler to make this a monolithic change.
This change inlines a bunch of logic from spirv_to_dxil into the
spirv2dxil tool so that linking can be done on the nir shaders.
Probably the linking functionality should be exposed in the lib/dll
form too, which means that a helper for freeing intermediate nir
would be needed too. That's TODO for now.
The tool now requires arguments to be in-order, and once a filename
is encountered, will use the previous arguments to compile the shader.
If multiple graphics shaders are passed, they're linked as if they
were forming a pipeline together.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20440>
The functions that upgraded VkFooMemoryBarrier to VkFooMemoryBarrier2
dropped the pNext pointers. It loses VkSampleLocationsInfoEXT, and may
lose additional structs too if VkFooMemoryBarrier receives further
extensions in the future.
Signed-off-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20477>
The frame_num variable must be updated for encode entrypoint disregarding
the outcome of the PIPE_VIDEO_CAP_REQUIRES_FLUSH_ON_END_FRAME cap check
fixes: 229c6f79a6 ("frontends/va: Implement vaSyncBuffer")
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20490>
this should be bug-free, as it passes cts/piglit/gaming on multiple drivers,
but since it's new, it stays behind an env var for at least one release
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20489>
After using task shader, we need to emit a zero URB state and a
nullprim (empty pipe control) before rendering with primitives.
After this, a normal URB state needs to be returned, this will
happen when pipeline batch is emitted during pipeline switch.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20334>
Specifically when shrinking load_const with number of components
> 5, if the final number of components is not allowed (for example 8->6)
it would report false for progress even if we actually did some
reshuffling and also it would skip on the rewrite of the readers.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20213>
This will clean code like:
vec3 32 ssa_8 = frcp ssa_7.www
vec3 32 ssa_9 = fmul ssa_7.xyz, ssa_8
into
vec1 32 ssa_8 = frcp ssa_7.w
vec3 32 ssa_9 = fmul ssa_7.xyz, ssa_8.xxx
This helps r300 driver because we can only do single channel for math
ops at a time, so the first version would result in three frcp
instructions. The nir_opt_shrink_vectors comments even claim the pass
should be doing this, however it actually does it only for nir_op_vecx
instructions, so extend this for generic alu instructions.
RV530 shader-db:
total instructions in shared programs: 135032 -> 133707 (-0.98%)
instructions in affected programs: 46121 -> 44796 (-2.87%)
helped: 452
HURT: 26
total temps in shared programs: 17051 -> 17033 (-0.11%)
temps in affected programs: 1509 -> 1491 (-1.19%)
helped: 91
HURT: 30
12.02->12.08 (+0.5%) fps gain in Unigine Sanctuary (n=5) with RV530
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7051
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reiewed-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20213>
The goal is to make files at the root of src/compiler/ apply to both Bifrost and
Valhall, while ISA-specific code (e.g. instruction packing) code goes in
compiler/bifrost/ or compiler/valhall/. This is what Valhall is already doing,
the Bifrost specific stuff was just grandfathered in.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20455>
This functionality is now available on Linux with drm-shim + shader-db, and I
suspect the version bundled here is broken anyway. Strictly this drops
Windows/macOS support for the known-broken frontend to the shader compiler but I
can't say I'm terribly worried about that.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20455>
This is the compiler for both Bifrost and Valhall, and presumably future
Mali GPUs too. Give it a more generic name so we can use the bifrost/ path for
something a bit more specific.
For historical reasons the compiler's name is still "bifrost" and uses the
prefix `bi_`. I think that's ok in the same way that i915 in the kernel supports
way more than just i915.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20455>
