Otherwise the compiler generates an extra MOV to load the constant into
a register first because reasons. 🤷 vote_any, vote_all, vote_ieq,
and vote_feq handling already do this.
No shader-db changes on any Intel plaform.
Fossil-db results:
All Intel platforms had similar results. (Ice Lake shown)
Totals:
Instrs: 165592451 -> 165557937 (-0.02%)
Cycles: 15133282615 -> 15133059360 (-0.00%); split: -0.00%, +0.00%
Totals from 33779 (5.15% of 656115) affected shaders:
Instrs: 4396576 -> 4362062 (-0.79%)
Cycles: 86867412 -> 86644157 (-0.26%); split: -0.37%, +0.11%
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27044>
The problem seems to have been related to
nir_intrinsic_load_global_block_intel being marked as non-divergent.
No shader-db or fossil-db changes on any Intel platform.
v2: Rebase on splitting ELK from BRW. Remove devinfo->ver >= 8 check.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27044>
This is divergent because it specifically loads sequential values into
successive SIMD lanes.
No shader-db or fossil-db changes on any Intel platform.
Fixes: 9f44a26462 ("nir/divergence: handle load_global_block_intel")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27044>
This is almost a 1:1 copy of the same function in libwayland. If the version
with the symbol propagates far enough the fallback can be removed again.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27511>
The fast-clear value is now the same for SNORM and UNORM, so our trick
of reinterpreting SNORM as UNORM when copying now works with UBWC. We
can also freely reinterpret UNORM, SNORM, and UINT formats, as tested by
dEQP-VK.image.mutable.*.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27506>
We used to loop like this:
foreach (config_supported_by_driver) {
foreach (config_wl_knows_about) {
dri2_add_config(wl_config.rgba_masks, wl_config.rgba_shifts)) {
if (wl_config.rgba_masks != driver_config.rgba_masks ||
wl_config.rgba_shifts != driver_config.rgba_shifts) {
return NULL; /* driver config != wl config */
}
}
}
}
This is a pretty painful way to discover the relationship between the
different sets of configs, especially as we can just look up our Wayland
visual entry directly.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27709>
This extension has been broken ever since the initial commit. It created
an XRGB DRIImage for the driver to render to, so whilst the presentation
was opaque, the buffer also completely lacked an alpha channel.
Fix it by making sure we only modify the FourCC we send to the Wayland
server when creating a buffer.
Closes: mesa/mesa#5886
Fixes: 9aee7855d2 ("egl: implement EGL_EXT_present_opaque on wayland")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27709>
This entire pattern really wants to be a shared helper, to allocate a
shadow linear image from another device and then import it across into
the rendering GPU. Querying the FourCC from the DRIImage makes it easier
to pull out into shared code.
This temporarily makes the implementation more ugly, however it's
already pretty hard on the eyes, so probably no great loss.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27709>
When we create a texture, we allocate a pipe_resource for it with a
given format. When we export the texture to an EGLImage, we go look
up what the GL format was and try to re-derive the pipe_format back
again.
Instead of doing that, just immediately reuse the pipe_format for the
image's format.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27709>
When we create a renderbuffer, we allocate a pipe_resource for it with a
given format. When we export the renderbuffer to an EGLImage, we go look
up what the GL format was and try to re-derive the pipe_format back
again.
Instead of doing that, just immediately reuse the pipe_format for the
image's format.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27709>
When the DRI frontend generates configs to pass to the APIs, store the
pipe_format in the internal gl_config structure. Doing this allows us to
nuke a few places where we try to retcon our way back from the config to
a pipe_format.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27709>
When populating DRI configs, driconf allows us to exclude
10bpc/RGBA/float configs. Rather than having a hardcoded set of formats
which satisfy those properties, just check the actual format
definitions.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27709>
