Several web sites block clients with "Apple" in the WebGL renderer
string if the reported OS is not one of Apple's.
This check seems to implemented via a 3rd party product which is slowly
rolled out over more web sites. Instead of playing whack-a-mole with
web sites in multiple browsers override the OpenGL renderer in mesa for
known browsers.
Backport-to: 25.3
Signed-off-by: Janne Grunau <j@jannau.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38845>
This change improves evergreen_apply_scissor_bug_workaround().
It provides a fully functional workaround for cayman.
Note: this was the last functionality which was working
properly on evergreen but not on cayman.
Here are the tests fixed:
spec/arb_framebuffer_no_attachments/arb_framebuffer_no_attachments-atomic/glscissor: fail pass
spec/arb_framebuffer_no_attachments/arb_framebuffer_no_attachments-query/glscissor: fail pass
deqp-gles31/functional/fbo/no_attachments/interaction/1x1ms0_default_2048x2048ms4: fail pass
deqp-gles31/functional/fbo/no_attachments/npot_size/1x1: fail pass
Fixes: 87a5b07f90 ("gallium/radeon: add R600/Evergreen/Cayman support to common viewport code")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38743>
Don't sink alu that uses ballot(true), as that can a local system value
and moving the alu then requires a new mov in the old location.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38829>
bit_size <= 32 does not actually guarantee a single component, which
nir_src_as_uint() requires. We could just check num_components == 1 but
it's easy enough to support any vector that fits in 32 bits.
Cc: mesa-stable
Reviewed-by: Romaric Jodin <rjodin@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38772>
Before every emit_vertex(stream_id = n), we would insert stores for all
outputs, including outputs that are not meant for that stream.
Those stores would end up having no effect while potentially reducing
performance.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38100>
For 64K x 64K textures.
The regular expressions used to find potentially overflowing multiplications:
(width.*\*.*height|height.*\*.*width|stride.*\*.*height|height.*\*.*stride|row.*\*.*height|height.*\*.*row)
(height.*\*.*depth|depth.*\*.*height|size.*\*.*depth|depth.*\*.*size)
A few things were authored by Pierre-Eric using static analysis to
detect potential overflows.
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38587>
While v7+ checks this on HW, older architectures depend on SW to do it.
Fixes: c43882ad54 ("panfrost: Allow pixels using discard to be killed")
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38522>
Setting this flag is valid as long as the fragment shader doesn't have
any side effects on v7+. v6 requires an extra check for earlyzs.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38522>
Running nop sched before opt_jump runs into issues because at that
point, we might have branches like this:
getone x
jump y
which becomes this after nop sched:
(rpt5)nop
getone x
(rpt5)nop
jump y
and then opt_jump may remove the jump leaving the block without a
terminator. This in turn causes ir3_calc_reconvergence to calculate (jp)
incorrectly.
Sync sched is fine but let's keep the two together.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38833>
Fix for deqp:
dEQP-VK.api.device_init.create_instance_device_intentional_alloc_fail.basic
Signed-off-by: Nick Hamilton <nick.hamilton@imgtec.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38827>
Fix for deqp:
dEQP-VK.api.device_init.create_instance_device_intentional_alloc_fail.basic
Signed-off-by: Nick Hamilton <nick.hamilton@imgtec.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38827>
The min/max funcs are designed to operate solely on the source and
destination colors directly, without any scaling or multiplication by a
factor.
Test: dEQP-GLES3.functional.fragment_ops.blend.* pass with enabled FPK
Cc: mesa-stable
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38824>
This fixes a biases in texture linear sampling,
which can be very noticeable when strong lighting
is applied on mipmapped textures generated at
runtime using successive linear blitting.
More bits aren't actually needed for lerp and the
intrinsic rounding is wrong, so it is removed in
favour of a correct uniform codegen.
Reviewed-by: Jose Fonseca <jose.fonseca@broadcom.com>
Reviewed-by: Roland Scheidegger <roland.scheidegger@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37986>
The accumulation of biased results leads to images
that are slighly too bright or dark. This is particularly
noticeable in specular highlights, which magnify errors
a lot.
Reviewed-by: Jose Fonseca <jose.fonseca@broadcom.com>
Reviewed-by: Roland Scheidegger <roland.scheidegger@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37986>
