Use the common ref counting and the common destroy entrypoint.
Signed-off-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17818>
Updating PC_TESSFACTOR_ADDR could race with the next draw which uses it.
Fixes GL CTS tests running via Zink:
KHR-Single-GL46.enhanced_layouts.glsl_contant_values
KHR-GLES32.core.tessellation_shader.tessellation_shader_point_mode.point_rendering
KHR-GLES32.core.tessellation_shader.winding.quads_cw
KHR-GLES32.core.tessellation_shader.winding.triangles_cw
And probably more.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6815
Suggested-by: Connor Abbott <cwabbott0@gmail.com>
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17833>
Now, only one instance of virgl_screen exists for a device
(/dev/dri/cardX), and it is shared by different frontends (eg GLX,
GBM, etc.). There is a problem with this, as follows:
/* Init GLX */
...
glXCreateContext(...);
...
/* GBM */
gbm_fd = open("/dev/dri/card0", O_RDWR);
dev = gbm_create_device(gbm_fd);
bo = gbm_bo_create(dev, ...);
plane_handle = gbm_bo_get_handle_for_plane(bo, ...);
drmPrimeHandleToFD(gbm_fd, handle.u32, flags, &plane_fd);
The above drmPrimeHandleToFD() call will fail with ENOENT.
The reason is that GBM and GLX share the same virgl_screen (file
descriptor), and it is not gbm_fd that is used to create gbm_bo,
but other fd (opened during GLX initialization). Since the scope
of prime handle is limited to drm_file, the above plane_handle is
invalid under gbm_fd.
By canceling the sharing of virgl_screen between different drm_files,
GBM can use the correct fd to create resources, thereby avoiding the
problem of invalid prime handle.
Signed-off-by: Feng Jiang <jiangfeng@kylinos.cn>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16738>
Bspec 53421 says:
"A URB fence memory is typically performed prior the thread
exit message, so that the next thread dispatch that reads
that URB memory will see it."
Cc: 22.1 <mesa-stable>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16665>
Found by code inspection.
There's an assert later checking that we haven't overflown
this array, so this change probably doesn't matter for any
workload.
Cc: 22.1 <mesa-stable>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16665>
This allows the software scoreboarding pass, scheduler, and so on
to handle the individual instructions and handle them, rather than
trusting in the generator to do scoreboarding correctly when expanding
the virtual instruction to multiple actual instructions.
By using SHADER_OPCODE_READ_SR_REG, we also correctly handle the
software scoreboarding workaround when reading DMask/VMask.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17530>
The hwconfig api may change unexpectedly prior to public release of
new platforms. Also, public documentation of the hwconfig api
sometimes lags the release.
For these reasons, warnings about unhandled hwconfig keys are noisy,
likely to occur, and unhelpful to most users. This commit drops those
warnings, in favor of a separate internal process for tracking
hwconfig api changes.
Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17846>
Currently, res->maybe_busy is false by default. If wait immediately
after the resource is created, virgl_drm_resource_wait() will return
directly without checking the actual state of the kernel, which will
cause synchronization problems, such as:
On Guest:
pipe_buffer_create [mesa]
virgl_drm_winsys_resource_create
virtio_gpu_resource_create_ioctl [kernel]
virtio_gpu_fence_alloc
virtio_gpu_object_create
virtio_gpu_cmd_resource_create_3d
VIRTIO_GPU_CMD_RESOURCE_CREATE_3D
virtio_gpu_object_attach
virtio_gpu_cmd_resource_attach_backing
VIRTIO_GPU_CMD_RESOURCE_ATTACH_BACKING
resource_wait [mesa]
virgl_drm_resource_wait /* return directly without fence waiting */
pipe_buffer_map [mesa]
virgl_drm_resource_map
virtio_gpu_map_ioctl [kernel]
os_mmap
memcpy /* <== here */
On Host (with QEMU):
VIRTIO_GPU_CMD_RESOURCE_CREATE_3D
virgl_cmd_create_resource_3d [qemu]
virgl_renderer_resource_create [virglrenderer]
VIRTIO_GPU_CMD_RESOURCE_ATTACH_BACKING
virgl_resource_attach_backing [qemu]
virtio_gpu_create_mapping_iov
virgl_renderer_resource_attach_iov [virglrenderer]
virgl_resource_attach_iov
vrend_pipe_resource_attach_iov
vrend_write_to_iovec /* <== here */
virtio_gpu_cleanup_mapping_iov [qemu]
In the example above, there is a race condition between memcpy and
vrend_write_to_iovec.
Signed-off-by: Jiang Feng <jiangfeng@kylinos.cn>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17592>
When we don't want to communicate with minio, e.g. running
lava_job_submitter script locally, MINIO_RESULTS_UPLOAD should be unset.
But this variable is already set by generate-env script, so we need to
remove it from the /set-job-env-vars.sh to avoid declaring it in
unexpected scenarios.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17645>
../src/util/libsync.h:134:33: warning: suggest braces around initialization of subobject [-Wmissing-braces]
struct sync_merge_data data = {0};
^
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17816>
Is a phi source is an undef, there's no point in copying it or really
caring about it at all. We would just end up inserting a mov from an
undef to a register. Instead, treat phi sources which point to an undef
as if the phi source doesn't exist.
This also prevents them from being included in phi webs which should
reduce the overall interference seen in the shader. Currently, if two
phis share an undef, their phi webs are consdiered to interfere. By
ignoring undefs we can get rid of this false interference and reduce the
size of phi webs. Reducing the number of things being copied by the
parallel copy instructions should also free up the paralle copy
algorithm and reduce the over-all churn of movs.
Shader-db results on Haswell:
total instructions in shared programs: 8156608 -> 8155406 (-0.01%)
instructions in affected programs: 164838 -> 163636 (-0.73%)
Shader-db results on Skylake:
total instructions in shared programs: 18227370 -> 18227359 (<.01%)
instructions in affected programs: 519 -> 508 (-2.12%)
helped: 6
HURT: 0
Shader-db results on Tigerlake:
total instructions in shared programs: 21167987 -> 21168025 (<.01%)
instructions in affected programs: 23701 -> 23739 (0.16%)
helped: 21
HURT: 27
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16817>
Undefs can happen even in real GLSL shaders so it's best to handle them.
Lowering to zero is a perfectly valid implementation. Also, run DCE
because some of the undefs may be dead after from_ssa and there's no
point in processing those in the back-end.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16817>
This was disabled ages ago because it provoked bugs between us and
xserver about context creation attributes, hopefully those servers are
out of circulation by now, let's find out.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17756>
These tests predate using GTest in the compiler. Now that we do, we'd like to
have the tests together so they run regularly.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17824>
I copy-and-pasted one of these and people noted that we had a better tool,
so make sure nobody else copy and pastes it.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17664>
The nir_opt_conditional_discard pass is called anyway and covers
discard/demote/terminate.
iris shader-db:
total instructions in shared programs: 8933422 -> 8933426 (<.01%)
instructions in affected programs: 48 -> 52 (8.33%)
helped: 0
HURT: 4
which is a synmark shader going from 12 to 13 instrs.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17664>
This pattern almost always gets peephole-selected out anyway, but I
noticed it once I removed glsl opt_conditional_discard.
iris shader-db:
total instructions in shared programs: 8933934 -> 8933158 (<.01%)
instructions in affected programs: 75575 -> 74799 (-1.03%)
helped: 179
HURT: 15
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17664>
As it is needed to have V3D_DEBUG defined. For the v3d case, I did it
restoring v3d_process_debug_variable, as it is at v3d_debug.c that
DEBUG_GET_ONCE_FLAGS_OPTION is called.
Fixes: 106b33405e ("vc4/v3d: stop adding NORAST when SHADERDB debug option is used")
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17812>
