Note:
* a3xx change based on available register documentation
* a4xx guesses (RB_RENDER_CONTROL2 bits especially)
* a5xx change based on a6xx, these registers seem identical
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5582>
Marge only merges an MR if the pipeline passed. Running the pipeline
again after merging is redundant.
v2:
* Add rule to ensure docker images are up to date in the main project
registry (Eric Anholt)
Reviewed-by: Eric Anholt <eric@anholt.net>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5680>
It's generally considered good practice to use underscore-prefixes for
directories that contains non-doumentation files, so let's do this for
our custom extensions as well.
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Acked-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5691>
We have much more blocks that are of no particular language (mostly
custom ASM variants), so let's instead opt in if we want
syntax-highlighting.
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Acked-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5691>
This label was removed a long time ago, let's also remove the reference
to it.
Fixes: 3acd7a34ab ("st/vega: Remove.")
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Acked-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5691>
Fixes: 0caf74bbcd ("gallium: add PIPE_CAP_FRAMEBUFFER_MSAA_CONSTRAINTS")
Fixes: 8632626c81 ("gallium: add pipe_resource::nr_storage_samples, and set it same as nr_samples")
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Acked-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5691>
add_description_unit has been deprectated for a really long time, and was
finally removed (seemingly in Sphinx 2.0, but this doesn't seem to be
properly documented anywhere I can find), so we shouldn't be using this
any more.
Anyway, let's update the code.
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Acked-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5691>
This code was broken, but it worked by accident, as the
pad and the edgeflag were reversed, however when Roland
removed the cliptest field back in 2015, he stopped copying
the pad which actually stopped copy the edgeflag.
Fix the function to actually copy the edgeflag.
Fixes: 1b22815af6 ("draw: don't pretend have_clipdist is per-vertex")
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5679>
These values were getting casted up to 32-bit, but then extracted
via 16-bit pointer later. Just store via 16-bit.
Fixes a lot of piglit on s390
Fixes: f96a69f916 ("mesa: replace GLenum with GLenum16 in common structures (v4)");
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5679>
Casting to u8 arrays and picking the lowest byte is fairly LE specific
grab the other byte.
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5679>
In a piglit run on s390 a lot of double tests fail, explicitly
packing/shifting things rather than using memcpy seems to help
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5679>
This explains what they are, what they do and how to use them.
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Clayton Craft <clayton.a.craft@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2250>
The fast version is apparently not accurate enough. I wrote a very
simply test program that called logf2 and the old LOG2 function 100000
times. Across that the two functions had very similar run times, neither
appeared meaningfully faster, so the optimization of bringing back yet
another way to calculate log2f seems pointless.
Fixes: bd4e769515
("replace LOG2 with util_fast_log2")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2856
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5406>
Since a few versions, mesa now needs c++14 and compiling with gnu++11
on ppc64el fails.
Let's use the default standard and fix the collision of types between
c++ and altivec in a another patch.
Cc: mesa-stable
Signed-off-by: Frédéric Bonnard <frediz@debian.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4948>
For that, we undefine bool, vector, pixel as advised by altivec.h in the
specific case that defines them.
Cc: mesa-stable
Signed-off-by: Frédéric Bonnard <frediz@debian.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4948>
If we have code like:
('f2f16', ('vec2', ('f2f32', 'a@16'), '#b@32'))
We would like to eliminate the conversions, but the existing rules can't
see into the the (heterogenous) vector. So instead of trying to
eliminate in one pass, we add opts to propagate the f2f16 into the
vector. Even if nothing further happens, this is often a win since then
the created vector is smaller (half2 instead of float2). Hence the above
gets transformed to
('vec2', ('f2f16', ('f2f32', 'a@16')), ('f2f16', '#b@32'))
Then the existing f2f16(f2f32) rule will kick in for the first component
and constant folding will for the second and we'll be left with
('vec2', 'a@16', '#b@16')
...eliminating all conversions.
v2: Predicate on !options->vectorize_vec2_16bit. As discussed, this
optimization helps greatly on true vector architectures (like Midgard)
but wreaks havoc on more modern SIMD-within-a-register architectures
(like Bifrost and modern AMD). So let's predicate on that.
v3: Extend for integers as well and add a comment explaining the
transforms.
Results on Midgard (unfortunately a true SIMD architecture):
total instructions in shared programs: 51359 -> 50963 (-0.77%)
instructions in affected programs: 4523 -> 4127 (-8.76%)
helped: 53
HURT: 0
helped stats (abs) min: 1 max: 86 x̄: 7.47 x̃: 6
helped stats (rel) min: 1.71% max: 28.00% x̄: 9.66% x̃: 7.34%
95% mean confidence interval for instructions value: -10.58 -4.36
95% mean confidence interval for instructions %-change: -11.45% -7.88%
Instructions are helped.
total bundles in shared programs: 25825 -> 25670 (-0.60%)
bundles in affected programs: 2057 -> 1902 (-7.54%)
helped: 53
HURT: 0
helped stats (abs) min: 1 max: 26 x̄: 2.92 x̃: 2
helped stats (rel) min: 2.86% max: 30.00% x̄: 8.64% x̃: 8.33%
95% mean confidence interval for bundles value: -3.93 -1.92
95% mean confidence interval for bundles %-change: -10.69% -6.59%
Bundles are helped.
total quadwords in shared programs: 41359 -> 41055 (-0.74%)
quadwords in affected programs: 3801 -> 3497 (-8.00%)
helped: 57
HURT: 0
helped stats (abs) min: 1 max: 57 x̄: 5.33 x̃: 4
helped stats (rel) min: 1.92% max: 21.05% x̄: 8.22% x̃: 6.67%
95% mean confidence interval for quadwords value: -7.35 -3.32
95% mean confidence interval for quadwords %-change: -9.54% -6.90%
Quadwords are helped.
total registers in shared programs: 3849 -> 3807 (-1.09%)
registers in affected programs: 167 -> 125 (-25.15%)
helped: 32
HURT: 1
helped stats (abs) min: 1 max: 3 x̄: 1.34 x̃: 1
helped stats (rel) min: 20.00% max: 50.00% x̄: 26.35% x̃: 20.00%
HURT stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1
HURT stats (rel) min: 16.67% max: 16.67% x̄: 16.67% x̃: 16.67%
95% mean confidence interval for registers value: -1.54 -1.00
95% mean confidence interval for registers %-change: -29.41% -20.69%
Registers are helped.
total threads in shared programs: 2471 -> 2520 (1.98%)
threads in affected programs: 49 -> 98 (100.00%)
helped: 25
HURT: 0
helped stats (abs) min: 1 max: 2 x̄: 1.96 x̃: 2
helped stats (rel) min: 100.00% max: 100.00% x̄: 100.00% x̃: 100.00%
95% mean confidence interval for threads value: 1.88 2.04
95% mean confidence interval for threads %-change: 100.00% 100.00%
Threads are [helped].
total spills in shared programs: 168 -> 168 (0.00%)
spills in affected programs: 0 -> 0
helped: 0
HURT: 0
total fills in shared programs: 186 -> 186 (0.00%)
fills in affected programs: 0 -> 0
helped: 0
HURT: 0
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4999>
This allows doing occlusion queries in one frame and getting the
results in the next frame without having to flush.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5676>
Commit e369b8931c ("freedreno: Use explicit *_NONE enum for undefined
formats") only partially converts ~0 to *_NONE enum. It breaks texture
support, and glmark2 texture scene gives a black screen.
Adding the missing conversion of ~0 to *_NONE enum fixes the issue.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5693>
Phase two of our network reconfiguration is happening this afternoon, so
we need to drop our RK3399 out for a little while. (Part of this
reconfiguration is to shard our devices across networks and racks, so
losing one part of our infrastructure doesn't mean losing any particular
device type.)
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5689>
Let's try this and see how it goes.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5689>
Build job artifacts capture Meson logs from _build, so we can analyse
what Meson did during configuration, as well as the full output of any
test jobs.
We were previously calling our build directory 'build', which meant it
wouldn't have been captured by the artifacts, and we were also deleting
it to make really sure there was no chance of logs getting captured
either.
Rename the build directory to '_build' to match the others, and don't
delete it either, so we can keep our configure/test logs.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5689>
This might make linking a bit less prone to OOM when trying to pull in
LLVM.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5689>
Getting assertion failures is helpful to have, even if we are doing a
release build.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5689>
GLSL shares functionality with ARB_vertex_program but the GLSL
spec defines the gl_LightSource builtin with a member order that
is different from the packing expected in ARB_vertex_program.
This difference introduces a need for specialist lowering code
when handling builtin structs that is not required for normal
uniform structs due to member location mismatches.
Since gl_LightSource can't be redefined it shouldn't matter if
we add the members in the order listed in the spec, just so long
as we add them all. So here we rearrange the definition of the
glsl builtin to reflex our internal layout and that of
ARB_vertex_program. This required for the following patch.
CC: <stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5656>
This allows us to query the uniform size required to store the
state value.
CC: <stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5656>
If the underlying X11 window gets destroyed, the event we're waiting
for may never be delivered, in which case xcb_wait_for_special_event
would hang indefinitely.
Solution:
1. Use xcb_poll_for_special_event to check if an event has arrived yet.
2. If not, Wait up to ~1s for XCB's file descriptor to become readable;
if it does, go back to step 1.
3. If the file descriptor didn't become readable, make a round-trip to
the X server to check that the window still exists. Go back to step
1 if it does, otherwise bail.
Also add an early bail-out when it's known that the window was
destroyed.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/116
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5368>
Before, if one thread ended up waiting in dri3_wait_for_event_locked
and another one in loader_dri3_wait_for_msc at the same time, one thread
could end up processing an event the other thread was waiting for, which
could result in the latter thread waiting longer than necessary
(possibly indefinitely).
Noticed by inspection.
v2:
* Drop xcb_flush call from loader_dri3_wait_for_msc in favour of the one
in dri3_wait_for_event_locked (Kenneth Graunke)
Fixes: 7b0e8264dd "loader/dri3: Try to make sure we only process our
own NotifyMSC events"
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5368>
We weren't initializing the VCM bits in the !gs path, but v33 doesn't have
GS so we can just mark it unreachable.
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2952>
