For gl_FragDepth, passes dEQP-GLES3.functional.shaders.fragdepth.* and piglit
fragdepth_gles2.
For stencil export, passes piglit glsl-fs-shader-stencil-export.
For gl_FragDepth together with stencil export, passes
dEQP-GLES3.functional.fbo.blit.*
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20365>
The hash table needs a key pointer with at least the lifetime of the
hash entry, which the key pointer we get does not have (since it is
stack-allocated by agx_build_meta). Copy it into the shader struct
itself and use that for the hash table.
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20365>
It seems triangle merging is incompatible with calculating derivatives
along primitive edges correctly. Take the appropriate NIR shader info
flags in the compiler and pass them down as a flag to the driver, so it
can set the disable triangle merging flag (formerly called "lines or
points").
TODO: Is this what macOS does when you set a sample mask there (which
apparently fixes the same bug on the Darwinia Metal backend)? Do we
also need to set this when sample masks are used?
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Fixes Darwinia and dEQP2 projected tests.
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20365>
Shared resources are in an unknown state, so we have to assume they
may contain valid data.
Fixes Xorg+Kwin random full-screen garbage on mouse cursor present.
However, we still get black flashing in some circumstances (that was
garbage flashing before this commit), which indicates that something
is reading an uninitialized/fresh shared framebuffer and expecting
valid data (prior screen contents?) TBD.
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20365>
We were only dereferencing the resource in the PIPE_MAP_WRITE path of
agx_transfer_unmap, which means that read-only transfers leaked the
staging resource/BO. Always free the staging resource unconditionally.
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20365>
Without globalFencing, exportable fences and semaphores must instead
have their proxy vn_renderer_sync installed in the same renderer
ring_idx as ther last queue submissions to ensure they signal after
all work previously submitted to the same ring_idx. Exportable
fences/semaphores with a temporary (imported) payload don't need a proxy
vn_renderer_sync, since they already have a `poll()`able fd available.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19691>
With implicit fencing, the image has a fence that blocks scanout until
rendering is complete. virtgpu doesn't support implicit fencing yet, but
Sommelier (a VM Wayland compositor) does the wait by exposing the bo as
a GEM handle and waiting on all fences in userspace with a
DRM_IOCTL_VIRTGPU_WAIT before issuing the wl_surface commit.
During vkQueueSubmit involving wsi images, we follow with an empty
renderer submission on the corresonding ring_idx to install a fence
on the appropriate virtgpu fence context after the last rendering
submission.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19691>
For submissions to renderers that support multiple timelines, put
them on the virtgpu fencing timeline (dma fence context) specified by
the VkQueue's bound ring_idx. CPU-sync'd renderer submissions
can be sent in the same manner by using ring_idx = 0.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19691>
Pick DEBUG_GET_ONCE_BOOL_OPTION as a example:
The intention of DEBUG_GET_ONCE_BOOL_OPTION are returned the same value across
thread, before this commit, on different thread call the function generated by
DEBUG_GET_ONCE_BOOL_OPTION may return different value if called setenv in the
middle of debug_get_bool_option, so use debug_get_option_cached along with
new exposed function debug_parse_bool_option to solve this issue
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19554>
struct hash_table is not thread-safety, need guard by mutex,
but with thread local storage, we can simplify the code and also
got the thread safety without the need of mutex.
Another advantage is by using thread local storage, os_get_android_option
will have the same actions like getenv does, that it's not cached the
value, each call will access the property_get, like getenv will be affected
by putenv
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19554>
Getting debug_get_num_option to return int64_t, as long under 64 bit Linux are 64 bit size,
so using fixed int64_t for cross platform consistence, as long under win32 is 32 bit size.
Getting DEBUG_GET_ONCE_FLAGS_OPTION to return uint64_t to getting it to be
consistence with debug_get_flags_option.
DEBUG_GET_ONCE_NUM_OPTION is not accessed in codebase, so add unittest for it, it maybe
used in future, remove it is not consistence
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19554>
error messages:
src/compiler/glsl/glcpp/glcpp-parse.c:1691:9: error: variable 'glcpp_parser_nerrs' set but not used [-Werror,-Wunused-but-set-variable]
int yynerrs = 0;
^
src/compiler/glsl/glsl_parser.cpp:2370:9: error: variable '_mesa_glsl_nerrs' set but not used [-Werror,-Wunused-but-set-variable]
int yynerrs = 0;
^
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19875>