This shouldn't do anything but will make testing a later patch easier.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8056>
This shouldn't do anything but will make testing a later patch easier.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8056>
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>
We were handling the case where we had an unassigned output in the
middle of the outputs array, but v->outputs can be smaller than the
shader's info.num_outputs when an output at the end isn't assigned. This
lead to us reading garbage after the end, and assuming that it
corresponded to r0.x and overwriting the xfb entry for some other random
output with the unassigned output's entry.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12310>
Fixes warning during the build and unnecessary rule execution:
***
ninja: Missing `restat`? An output file is older than the most recent input:
***
Fixes: 8621bd8d5e ("android: Add scripts to build using meson")
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Tested-by: Mauro Rossi <issor.oruam@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12304>
mesa3d require up-to-date version of libdrm.
Hardcoding it to 2.4.105 is wrong.
Fixes: 8621bd8d5e ("android: Add scripts to build using meson")
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Tested-by: Mauro Rossi <issor.oruam@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12304>
Add a value discovered when investigating how the blob implements
GL_KHR_blend_equation_advanced.
Note that everything added here is a bit speculative, because it's
assuming the blob's implementation of GL_KHR_blend_equation_advanced is
sane. In particular a value of 0x3 seems to solve the UBWC problem as
well, so I'm not sure whether my description of the difference between
0x1 and 0x3 is correct. I'm also surprised that it uses the same value
for the coherent and non-coherent cases when forcing sysmem.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12360>
There are some places in the code in which we search for a certain
format in the u_vector. This new function help us to avoid repetition.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12117>
In wsi_wl_display_init(), the format vector is initialized only when the
caller sets the function to query the formats/modifiers. But
wsi_wl_display_finish() always release the vector, no matter if it has
been initialized or not.
For now it just works because the u_vector_foreach() macro works when
the format vector is uninitialized, but it is a weird design to try to
release something that has not been initialized.
So in this patch we start to always initialize the format vector, even
when not querying formats/modifiers.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12117>
Instead of having hard-coded lists of modifiers for argb8888 and
xrgb8888, store a list of modifiers alongside each VkFormat. To
achieve this goal, introduce a new struct wsi_wl_format that holds
both a VkFormat and a modifier list, and use it for the items in
the formats list.
This commit unlocks non-{A,X}RGB8888 formats, which were previously
always disabled for linux-dmabuf.
Signed-off-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12117>
The two structs wsi_wl_display_swrast and wsi_wl_display_dmabuf have in
common the list of formats and the only difference between both is the
interface object.
As we know that only one of the arrays is populated (we never bind to
wl_shm and the dmabuf interface simultaneously), we can move the members
of these structs to wsi_wl_display and simplify the code.
This is based on previous work of Simon Ser <contact@emersion.fr>.
Signed-off-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12117>
When force_bgra8_unorm_first is true, we access display->formats and
change the order of certain formats. The final result is BGRA8_UNORM
being the first in the format list, as some clients require this.
But we are trying to do this before before setting up display->formats,
so it should result in a crash. Fix this by changing the order of
things. Now we first set up display->formats before trying to access it.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12117>
When we call wsi_wl_display_init() with get_format_list set to false
there's no need to dispatch the events from the interfaces. This allow
us to remove a check in the event handlers to verify if we're querying
the formats or not, what makes the code easier to read.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12117>
Until now we had a weird way to bail out if we could not get any
globals. Instead, add a direct check, what makes the code easier to
read.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12117>
Nowadays, all Wayland compositors implement linux-dmabuf. We
shouldn't need to support the legacy wl_drm interface anymore.
Signed-off-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12117>
drm_fourcc.h is the canonical source for DRM formats. Instead of
using the values from wl_drm, use the canonical header.
Signed-off-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12117>
This reverts commit ad363913e6.
This code was added to be able to compare the output file while porting
the script from python2 to python3, but this has long been finished and
the extra complexity is not needed anymore.
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3674>
Ubuntu has dropped the `python` symlink to `python2` [1] instead of
redirecting it to `python3` like other distros are doing, which means
that if we want to build Mesa on Ubuntu we need the `python3` shebang.
[1] https://lists.ubuntu.com/archives/ubuntu-devel/2020-January/040882.html
Reported-by: Vinson Lee <vlee@freedesktop.org>
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Acked-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3674>
If a loop is followed by a barrier, the ordering between a load inside
the loop and other memory operations after the barrier may have to be
preserved depending on the type of memory involved. This is relevant
when the memory is writeable by other invocations. In such case, it
is not valid to completely eliminate the loop.
This commit doesn't attempt to precisely catch the barrier case, as
analysis could become too complex. It simply assumes it can't drop
the loops that contain certain types of loads unless those are known
to be safe to reorder (via the access flag).
Fixes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4475
Acked-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9938>
Rhys Perry
Alyssa Rosenzweig
Icecream95
Jesse Natalie
Connor Abbott
Roman Stratiienko
Leandro Ribeiro
Simon Ser
Emma Anholt
Eric Engestrom
Caio Marcelo de Oliveira Filho