dEQP has poor coverage of clear colours with odd formats, and doesn't
check that we dither as expected. This functionality is trivial to unit
test, so there's no excuse not to. Nontrivial reference values are
captured from pandecode of the Mali G52 DDK but should be valid for all
Midgard/Bifrost.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12365>
We support B5G6R5 as blendable, this is just a swizzle away. Reduces the
amount we hit blend shaders, and will fix a clear colour packing unit
test in a moment.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12365>
At the beginning of a render pass, the hardware will fill the tilebuffer
with an arbitrary 128-bit word. To implement colour clears, the driver
must pack the API-specific clear colour according to the 128-bit layout
of the tilebuffer. This layout depends only on the render target format.
The existing code to handle this was based on loose guesswork. It works
for the format / clear colour combinations tested in dEQP-GLES3, but it
is severely deficient in the general case. It works by matching on the
PIPE format of the render target (not the layout of the tilebuffer). For
special cased PIPE formats, it open codes a buggy pack routine.
Otherwise, it defaults to util_pack_color in the hope that will work.
Since util_pack_color doesn't know anything about Mali tilebuffer
layouts, that means it's defaulting to wrong behaviour.
Now that we understand internal tilebuffer layouts, let's rewrite the
packing code. Instead of matching PIPE formats, map the PIPE format to
the internal tilebuffer layout using the common table, ensuring the
mapping remains in sync with the render target descriptor. Then for
blendable tilebuffer formats, pack using a common float -> fixed point
path supporting optional sRGB translation. Raw formats use
util_pack_color as before.
For formats with less than 8 bits per channel, the new code uses the
fractional bits of the fixed-point representation. This is required for
correct dithering if the clear colour is not exactly representable in
the final low precision format.
In summary, at least the following bugs in the old code are fixed:
* Swapped R/B channels with sRGB
* Swapped R/B channels with some missing formats
* Incorrect dithering with RGB565, RGB5_A1
Fixes the following test cases:
dEQP-EGL.functional.wide_color.window_8888_colorspace_srgb
dEQP-EGL.functional.wide_color.pbuffer_8888_colorspace_srgb
dEQP-EGL.functional.wide_color.window_888_colorspace_srgb
dEQP-EGL.functional.wide_color.pbuffer_888_colorspace_srgb
Later in the series, unit tests are added for the new implementation.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12365>
Transfer ownership of the render node fd to the panfrost_device (minor
change to panvk), and then close the file descriptor for the render node
bound to the panfrost_device when destroying the panfrost_device. Of all
the users of panfrost_open_device, panvk is the only one that correctly
closed the fd before. Accordingly, this fixes an fd leak in the Gallium
driver (and performance counter utilities).
This fix still applies to the Gallium driver when renderonly is in use--
although renderonly closes its own fd, the fd is _duplicated_ in
panfrost_drm_winsys.c, so renderonly and panfrost must _both_ close
their respective fd to fix the leak.
This fixes a crash when running dEQP-EGL for more than two hours.
dEQP-EGL creates a new screen for every test case and then immediately
destroys it. If destroying a screen leaks the fd, this causes the number
of open file descriptors to increase monotonically until the process
ends. This will eventually hit the system limit for number of open files
and abort the process.
This bug was identified while attempting to run the OpenGL ES
conformance tests via cts-runner, and then confirmed with `lsof`. With
the fix, the number of file descriptors reported by `lsof | wc -l` is
now constant while running dEQP-EGL as expected.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12346>
Bifrost adds a value for the C factor equaling 2*src. This does not
correspond directly to API blend modes so it is not too useful in
general. However, it's required for src*dest + dest*src blending to be
done in hardware instead of a blend shader. GFXbench uses that blend
mode, so it must be important ;-)
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12152>
Add unit tests for the fixed-function blending helpers in pan_blend.c.
Each test consists of a Porter-Duff blend mode and the associated
hardware state. In this commit, we add tests for the most common modes.
For motivation, this code has NOT been properly tested in CI. True,
functional correctness of the blend module as a whole is tested by
dEQP-GLES3.functional.fragment_ops.blend.* among other integration
tests. However, this testing is insufficient to check for regressions.
Crucially, the following broken patch would clear CI:
bool pan_can_fixed_function(...) {
return false;
}
In that case, blend shaders are used 100% of the time, which will
regress performance horribly but still pass dEQP. The only clue
something went wrong would be some traces changing checksum due to the
fixed-function blender producing slightly different output than
equivalent blend shaders. By unit testing the fixed blend path, we
ensure we always use the fixed-function path when we expect it to.
Similarly, using incorrect values for the blend metadata may not affect
functional correctness but will increase power consumption. Let's check
all the data we export to drivers.
Note: due to additive commutativity, there are many pairs of equivalent
Mali blend modes. Unfortunately, the vendor is... inconsistent about how
to resolve ambiguous modes. Our algorithm for computing modes is
correct; the "preferred" values are left in comments since otherwise our
tests fail despite correct code. I want to blame Bifrost for this, but
Midgard was patient zero.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12152>
This is required to disable dithering on a per-draw basis when OPAQUE
output is used (bypassing the blender which normally uses the
round_to_framebuffer_precision flag to do the same).
This functionally reverts:
ebc07f4b2f ("panfrost: Remove padded unorm blendable formats")
fae90a7940 ("panfrost: Always pick dithered tb formats")
while adding the functionality to make them useful.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12152>
If we return inside a pan_pack() the descriptor packing doesn't happen.
Cc: mesa-stable
Fixes: 8ba2f9f698 ("panfrost: Create a blitter library to replace the existing preload helpers")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12239>
This is safer, since it allows the thing being concatenated to itself be
an expande macro, which we'll use as a stopgap to construct tiler jobs
with unified code. It's also a bit more readable, I think.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11851>
Midgard calls this nearest but Bifrost calls it point sample. Of the
two, nearest is the standard term, so change the Bifrost XML to use that
name. That way we can share more code constructing samplers.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11851>
Tells you how much use Mali T720 gets that nobody noticed but
Icecream95...
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reported-by: Icecream95 <ixn@disroot.org>
Acked-by: Icecream95 <ixn@disroot.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12027>
This was useful when panvk was being bootstrapped, allowing the blitter
to be tested against a known-working driver. With panvk in-tree, I don't
see a compelling reason to keep pan_blitter support wired in but
off-by-default. Keeping it will complicate the GenXML change we're about
to make.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11785>
This allows us to unify the midgard and bifrost tables and just #ifdef
the differences. It will soon also allow us to fix a bunch of enums and
specialize blendable formats.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11785>
This will become the home for little GenXML-aware helpers, suitable to
be #include'd from pan_cmdstream.c (or panvk equivalent).
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11785>
Bifrost has a new type of job called 'index-driven vertex', which takes
in two shaders. The primary shader, called for all values, performs
position shading to a cacheline-aligned attribute buffer. The secondary
shader, called for values still live after culling, performs varying
shading.
It is the responsiblilty of the implementation to ensure that vertices
from different instances do not share a cacheline.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11413>
