this makes debugging the shader header a little easier
Acked-by: Pierre Moreau <pierre.morrow@free.fr>
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Use 2D_ARRARY instead of RECT to fetch texels for weave compute
shader.
Problem 2,3: Fixed interpolation issue with weave de-interlace
Fixes: 9364d66cb7 (Add video compositor compute shader render)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109646
Signed-off-by: James Zhu <James.Zhu@amd.com>
Acked-by: Leo Liu <leo.liu@amd.com>
Tested-by: Bruno Milreu <bmilreu@gmail.com>
Using draw area for grid setting instead of destination
buffer size.
Signed-off-by: James Zhu <James.Zhu@amd.com>
Acked-by: Leo Liu <leo.liu@amd.com>
Tested-by: Bruno Milreu <bmilreu@gmail.com>
Increase shader_params size to pass sampler data to
compute shader during weave de-interlace.
Signed-off-by: James Zhu <James.Zhu@amd.com>
Acked-by: Leo Liu <leo.liu@amd.com>
Tested-by: Bruno Milreu <bmilreu@gmail.com>
The OpenMAX state tracker will use this.
RadeonSI is adapted to use pipe_grid_info::last_block instead of its
internal state.
Acked-by: Leo Liu <leo.liu@amd.com>
We have a native op for this, which was just found in a disassembly --
so instead of lowering, use it!
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Previously, we were caching this incorrectly; there's no real reason to
given how variable it is (sensitive to changes in viewport, framebuffer
dimensions, and scissors) and how cheap it is to recompute. So, just do
it on the fly each draw.
Fixes glmark-es2 -bshadow and -brefract.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
For inexplicable reasons, the depth buffer is faster if kept as linear,
whereas the colour buffers are faster if AFBC. Given both code paths are
available, we'll choose the faster one of each (which also helps with
testing coverage).
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
It's not clear why the hardware "spills" a little bit, but if we don't
do this, we get MMU faults with linear depth buffers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
While a depth buffer may be supplied, it only needs to be written to if
the depth writemask is set for any draw AND if the depth buffer is not
immediately invalidated (as is the case for scanout). This refactors
panfrost_job to provide a depth write requirement, which is now
implemented for MFBD depth buffers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
This removes a clunky hack where the depth buffer was enabled during the
*clear*, instead of during depth buffer linking. That said, this does
not yet support writeback like AFBC depth buffers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
The fragment framebuffer descriptor should not be a context entry;
rather, it should be constructed only at fragment time to keep analysis
tractable.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
This substantially cleans up the corresponding logic at the expense of a
bit of code duplication; nevertheless, it's a net win since otherwise
incompatible hardware code is mixed confusingly.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Not mutating the boxes is arguably cleaner.
Split from a patch by Chris Wilson but reworked to use a pointer to the
original box rather than making a copy at all.
Now that we are properly resolving buffers before giving them to the
window system, let's enable aux support again.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
In i965, we disable the use of RGBX formats, so the higher layers of
Mesa choose the equivalent RGBA format, and swizzle the alpha channel to
1.0.
However, Gallium won't do that. We need to explicitly convert it to
RGBA.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The flush_resource hook is supposedly called when the resource content
needs to be made visible to external (okay, that's pretty vague). For
instance, it gets called before a surface gets handled to the window
system. So we need to resolve it if it's not resolved yet.
v2 (Ken):
- Check mod_info in iris_flush_resource instead of ISL_AUX_USAGE_NONE
- Drop my old broken resolve code from iris_resource_get_handle() now
that Rafael's got it hooked up in the right place.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Always use the streaming load (since we know we have Broadwell+, all of
our target CPU support sse41) for reading back form the tiled surface
for mapping the resource. This means we hit the fast WC handling paths
on Atoms (without LLC), and for big Core (with LLC) using the streaming
load is no less efficient as we do not require the tiled buffer to be
pulled into the CPU cache.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
On !llc machines (Atoms), reading from a linear buffers is slow and so
copying from one resource into the linear staging buffer is still slow.
However, we can tell the GPU to snoop the CPU cache when reading from and
writing to the staging buffer eliminating the slow uncached reads.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This reduces the runtime of dEQP-GLES3.functional.shaders.precision.* from
11.5s to 3.3s. This brings CTS runs down to 4 hours on one of my target
devices.
This reduces compilation time for my shader-db collection from around 40
seconds to 30, vs. 19 seconds for TGSI. There are still some shaders
that TGSI caches but NIR doesn't, partly because of more aggressive
cross-stage optimizations with NIR.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
The fragment_extra structure contains additional fields extending the
MRT framebuffer descriptor, snuck in between the main framebuffer
descriptor and the render targets. Its fields include those related to
transaction elimination and depth/stencil buffers. This patch identifies
the flags field (previously just "unk" with some magic values) as well
as identifying some (but not all) flags set by the driver.
The process of identifying flags brought a bug to light where
transaction elimination (checksumming) could not be enabled unless AFBC
was in-use. This issue is now resolved.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
This bit, if set, causes the depth buffer to be copied from GPU tile
memory to the provided depth buffer in main memory. If not set, the GPU
will not access the main memory (saving considerable memory bandwidth if
depth results are not actually used).
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
This combination has not yet been seen "in the wild" in traces, but to
support linear depth FBOs, ~bruteforce reveals this bit pattern is
necessary. It's not yet clear why the meanings of 0x1 and 0x2 are
essentially flipped (tiled vs linear for colour, linear vs some sort of
tiled for depth).
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Previously, linear BOs shared memory with each other to minimize kernel
round-trips / latency, as well as to work around a bug in the free_slab
function. These concerns are invalid now, but continuing to use the slab
allocator for BOs resulted in memory allocation errors. This issue was
aggravated, though not introduced (so not a real regression) in the
previous commit.
v2 (unreviewed): Fix bug in v1 preventing munmaps from working
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Again, these formats are only properly known at the time of fragment job
emit. Rather than hardcoding the format, at least for MFBD we begin to
construct the format bits on-demand. This cleans up the code,
futureproofs for ES3 framebuffer formats, and should fix bugs regarding
FBO colour swizzles.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Tomeu Vizoso <tomeu.visozo@collabora.com>
In an effort to cleanup framebuffer management code, we delay
colour buffer setup until the FRAGMENT job is actually emitted, allowing
the AFBC and linear codepaths to be unified.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Tomeu Vizoso <tomeu.visozo@collabora.com>
AFBC, tiled, and linear BO layouts are mutually exclusive; they should
be coupled via a single enum rather than ad hoc checks of booleans.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Tomeu Vizoso <tomeu.visozo@collabora.com>
I'm not sure why we were checking for these additional criteria (likely
inherited from some other driver); remove the needless checks to cleanup
the code and perhaps fix some bugs down the line.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Tomeu Vizoso <tomeu.visozo@collabora.com>
