Move calculate_tess_lds_size and get_tcs_num_patches to radv_shader.h
ACO will need to call these functions too.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3964>
The assert introduced by 24f2b0a856 triggers when an application
requests a chroma_type that's different to the one from the
PIPE_VIDEO_CAP_PREFERED_FORMAT (before this change the chroma_type
was set but ignored).
So restore this behavior and ignore the chroma_type.
Reported-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Fixes: 24f2b0a856 ("gallium/video: remove pipe_video_buffer.chroma_format")
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4104>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4104>
Print each op at new line and add unit name suffix for each op.
It improves readability a bit and gives us a hint what unit
was used for particular op.
Reviewed-by: Andreas Baierl <ichgeh@imkreisrum.de>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4110>
Since we keep other constants there as well it's useful for reading disassembly.
Reviewed-by: Andreas Baierl <ichgeh@imkreisrum.de>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4110>
When trying to build mesa/master under AOSP, I've run into the
following error:
external/mesa3d/src/gallium/auxiliary/hud/hud_context.c:1821:31: error: braces around scalar initializer [-Werror,-Wbraced-scalar-init]
struct sigaction action = {{0}};
^~~
1 error generated.
This patch addresses this by switching to using memset instead of
using an initializer.
Signed-off-by: John Stultz <john.stultz@linaro.org>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4141>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4141>
It seems pan_afbc.c was added to the wrong Makefile.sources file.
So fix this, so we don't run into build issues with mesa/master
trying to build under AOSP.
Signed-off-by: John Stultz <john.stultz@linaro.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4141>
This patch adds missing ir3_cf.c and ir3_delay.c files to
the Makefile.sources file to address build issues seen
when trying to build mesa/master on AOSP
Signed-off-by: John Stultz <john.stultz@linaro.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4141>
With the live shader cache, equivalent shaders can be backed by the same
CSO. This breaks the logic that identifies whether the shader being deleted
is bound.
For example, having shaders A and B, you can bind shader A and delete
shader B. Deleting shader B will unbind shader A if they are equivalent.
Pierre-Eric figured out the root cause for this issue.
Fixes: 0db74f479b - radeonsi: use the live shader cache
Closes: #2596
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4078>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4078>
Since we can get a zero for free and a one inlined into the constant,
the obvious turns out to be efficient (while allowing flexibility for
boolean size).
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4139>
Only on supported GPUs at the moment; for older Bifrost that don't
support these, I'm not sure yet where the right place to do the lowering
is. NIR algebraic rules would be "nice" but probably impractical -- but
it wouldn't be hard to do it directly in BIR (as a lowering pass or
alternative implementation).
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4139>
These are all regular ALU ops found in GLES2 which makes them
particularly nice targets at the moment. Just translate straight to our
IR.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4139>
Soon we'll have a NIR support to handle this the Right Way along with
pos and sat_signed support, but we'll always need the fallback anyway.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4139>
This will allow us to optimize out the constant moves (although that
will require a DCE pass which has yet to be written).
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4139>
We do the bare minimum translation, just enough for fmov/fadd/fmul right
now with no modifiers / inlined constants / etc. The rest is to come!
But hopefully I got bitsize handling right this time around.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4139>
I feel so dirty. But this will let the IR be a lot more flexible seeing
as we really are vector in a certain sense (I/O, small types)
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4139>
We'd really rather not emit extracts. We are approaching on a vector IR
anyway which is annoying but really necessary to handle I/O and fp16
correctly. So let's just go all the way and deal with swizzles and masks
within reason; it'll still be somewhat saner in the long-term.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4139>
In the second (scalar pass) use the information about # of registers
used in the first pass as the target max, and round-robin within that
range. This generally gives the post-RA sched pass more opportunities
to re-order instructions to remove nop's.
Also, we can be a bit clever when assigning dest registers for SFU
instructions, by picking the register used for it's src (if available
and already assigned). This avoids some (ss) syncs caused by write
after read hazards. (Ie. the SFU instruction will read it's own src
before writing dest.)
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4071>
In the select_reg callback, I want to be able to determine if a given
node is already assigned, and if so what physical register has been
assigned.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4071>
Add a parameter so the callback can know which node it is selecting a
register for. And remove the graph parameter, as it is unused by
existing users, and somewhat unnecessary (ie. the callback data could
be used instead).
And add a comment so $future_me remembers how this works.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4071>
Doesn't take into account stalls that result from a register written in
a different block, etc. But this should be more useful than just using
number of (ss)'s by trying to estimate how costly a given sync is.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4071>
