unsetting zink from GALLIUM_DRIVER is required in order for lavapipe to
work, but setting it back is totally broken in the case where an app
creates a ton of screens simultaneously
instead, just leave it set to llvmpipe, and if a race condition occurs,
at least llvmpipe isn't going to fail a test that zink passes
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10120>
Again, NVIDIA supports this on every fbconfig, Mesa alternates it on and
off for some reason but only on some drivers, and in particular llvmpipe
doesn't try to create sRGB-ful fbconfigs. Nerf it out of the fbconfig.
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1648>
Mesa marks accumful fbconfigs as slow (for no especially good reason,
it's only accum operations that aren't accelerated, and we could fix
that). NVIDIA doesn't. All that mismatching on this attribute can do is
prevent a config from working exactly as well as it possibly can.
Trust the server's opinion here (but warn if you ask for warnings).
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1648>
For hardware drivers we've never set this to anything interesting so
there's no benefit to validating it. For drisw we're at the mercy of
whatever the X server sent to us anyway, and it's not like any server is
going to vary two fbconfigs by _just_ these values.
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1648>
Let's preface this all by noting that the accum buffer is unused even by
legacy feature standards, and that anybody needing it to be performant
is probably not using Mesa to begin with since we've never accelerated
it. This fix is really about making drisw work under hostile GLX
environments, since it doesn't have any control over what's running on
the server side.
NVIDIA's driver simply lists RGBA16 accumulation buffers for every
fbconfig, and the accum buffer's alpha channel is always non-zero even
if the color buffer is RGBX. If we try to point llvmpipe at such a
screen, then _none_ of the depth-24 fbconfigs will find a matching DRI
config, since DRI's accumful config will have 0 accum alpha bits. This
is somewhat limiting since most X applications are expecting an RGBX
config and will be accidentally translucent at depth 32.
Due to the somewhat ugly nature of how xserver constructs fbconfigs, if
you run a driver with this fix against a server from before this fix (or
vice versa), you will find the opposite result: none of your RGBX
fbconfigs will have an accum buffer, though the RGBA ones still will.
That's a pretty acceptable tradeoff to me since what we're gaining is
the ability to use llvmpipe at all.
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1648>
a synchronous driver can use PIPE_MAP_ONCE to infer that a buffer is
guaranteed to not be mapped multiple times, as this is only used when
doing map -> memcpy -> unmap directly
a threaded driver performs maps/unmaps asynchronously, so this flag
can only be used by the driver to confirm that the mapped region is accessed
exactly once, not that it will not need to remain mapped for other transfer_map
uses after it is unmapped
in short, consider this scenario:
transfer_map(A) -> memcpy(map, data) -> transfer_unmap(map_A) ->
transfer_map(A) -> memcpy(map, data) -> transfer_unmap(map_A)
when a synchronous driver executes this, the call chain is unmodified
when a tc driver executes this, the call chain may become:
transfer_map(A) -> memcpy(map, data) ->
transfer_map(A) -> memcpy(map, data) ->
transfer_unmap(map_A) -> transfer_unmap(map_A)
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10113>
GPUs with the feature bit PE_NO_ALPHA_TEST set have no fixed-function
alpha test unit and we want to let st lower it with a shader variant.
For GC7000K this fixes all fbo-alphatest-formats piglits like:
spec@ext_framebuffer_object@fbo-alphatest-formats
spec@ext_packed_float@fbo-alphatest-formats
spec@ext_texture_srgb@fbo-alphatest-formats
This only works with the NIR compiler backend.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Tested-by: Lukas F. Hartmann <lukas@mntmn.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9871>
getenv is not working well with Android VM. Instead, use os_get_option
to read Android system property.
e.g. adb shell setprop mesa.vn.debug drm
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10112>
They were used for tracking whether SSA needed to be repaired,
but now the repair is done for all functions with structured control flow.
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Signed-off-by: Andrii Simiklit <andrii.simiklit@globallogic.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7755>
This fixes OpSwitch corner case when switch doesn't have any targets
just a `default` and SSAs defined in it is used after switch block
directly without phis.
v2: Just use `repair_ssa` for all structured control-flow cases
( - Jason Ekstrand <jason@jlekstrand.net>
- Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> )
Closes: #3787
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Signed-off-by: Andrii Simiklit <andrii.simiklit@globallogic.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7755>
v2: Instead of fixing unitialized member 'fs_visitor::input_vue_map'
(as reported by Coverity Scan in defect CID 1474559),
remove unused members 'vec4_tcs_visitor::input_vue_map' and
'fs_visitor::input_vue_map'.
Also fixed 'debug_enabled' argument skipped in a fs_visitor constructor
call from brw_compile_tes().
Signed-off-by: Yevhenii Kharchenko <yevhenii.kharchenko@globallogic.com>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10040>
vn_ring is a fast way to submit commands, skipping vn_renderer entirely.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5800>
There are a virtio-gpu renderer and a vtest renderer. The vtest
renderer must be enabled with VN_DEBUG=vtest.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5800>
It only has enough stubs to be loadable by the loader.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5800>