Here are two facts, each mildly unpleasant, quite nasty taken together:
- xcb_wait_for_special_event retries its poll() if the fd woke up but
no matching event arrived, without verifying that the special event
queue is still registered.
- Present gives no in-band notification of window destruction.
Now if the window is destroyed before the swapchain we're in trouble.
Our WSI thread might be stuck in xcb_wait_for_special_event as we're
awaiting a completion that won't come (the pixmap was being presented as
the window, and then the window was destroyed, so no more events can
happen on that window).
The solution is to use xcb_poll_for_special_event, which is
non-blocking, and handle the appropriate edge cases. If we've run the
event queue but we still don't have an image to acquire, we poke the X
server with a request that gently verifies that the window exists,
allowing the thread to exit gracefully in the above case. We detect
when we're busy-looping, and poll on the X connection for up to 1ms in
response to avoid burning the CPU.
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13564>
This reverts commit 9823b970fb.
From VkPhysicalDeviceLimits [1]:
> maxVertexInputAttributeOffset is the maximum vertex input attribute
offset that can be added to the vertex input binding stride. The offset
member of the VkVertexInputAttributeDescription structure must be
less than or equal to this limit.
The maxVertexInputAttributeOffset is a limit on the offset of a vertex
attribute within a vertex rather than a limit on offsets for vertex
buffer bindings. The code to bind temporary buffers can be removed.
[1] https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkPhysicalDeviceLimits.html
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14572>
Beginning of Quake II RTX, 50% resolution scale, RX 6800: 54 -> 56 FPS.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14011>
Beginning of Quake II RTX, 50% resolution scale, RX 6800: 48 -> 54 FPS.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14011>
EXT_vertex_input_dynamic_state
When both EXT_vertex_input_dynamic_state and EXT_extended_dynamic_state
are not available stride is never set and nothing is rasterized as all
triangles are degenerate.
This fix copies stride into the VkVertexInputBindingDescription array
when the graphics pipeline is created when those extensions aren't
available.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14549>
For example the previous code generates the following sequence of
SPIR-V instructions ending with a redundant cast to uint:
%2018 = OpExtInst %uint %1 PackHalf2x16 %2017
%2019 = OpBitcast %uint %2018
The new code generates:
%2018 = OpExtInst %uint %1 PackHalf2x16 %2017
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14568>
Fixes InconsistentSpirv validation errors reporting that PackHalf2x16
outputs uint rather than float.
For example the previous code generates the following SPIR-V with
PackHalf2x16 output as a float:
%2018 = OpExtInst %float %1 PackHalf2x16 %2017
%2019 = OpBitcast %uint %2018
The new code generates:
%2018 = OpExtInst %uint %1 PackHalf2x16 %2017
%2019 = OpBitcast %uint %2018
cc: mesa-stable
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14568>
This makes a lot of lines shorter.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14455>
Zero isn't really a valid write mask. If it's provided, use a full write
mask.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14455>
When we create a image view with D24S8 format we made a reformatting
to RGBA8UI if the aspect selected is just STENCIL. But when
configuring the stores we select the aspects based on the attachment
format. Quoting from cmd_buffer_render_pass_emit_stores:
/* From the Vulkan spec, VkImageSubresourceRange:
*
* "When an image view of a depth/stencil image is used as a
* depth/stencil framebuffer attachment, the aspectMask is ignored
* and both depth and stencil image subresources are used."
*
* So we ignore the aspects from the subresource range of the image
* view for the depth/stencil attachment, but we still need to restrict
* the to aspects compatible with the render pass and the image.
*/
const VkImageAspectFlags aspects =
vk_format_aspects(ds_attachment->desc.format);
So we could ending trying to store on a Z+Stencil buffer, using a
RGBA8UI format.
So far this only affected some tests when using the simulator
(assert). Those were working on the real hw, but probably would fail
on other situations, so lets use the original image format on that
case.
v2 (Iago)
* Improve comment grammar
* Do the same on load too (not just store)
v3 (Iago)
* Re-word comments.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14635>
We track last submitted jobs by queue type. After all cmd buffer
batches have been submitted, we emit a noop job that waits all jobs
submitted to each GPU queue complete and signals the fence.
Signed-off-by: Melissa Wen <mwen@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13178>
With multiple semaphores support, we can use a GPU job to handle
multiple signal semaphores in the end of a cmd buffer batch. It
means, the last job in the last cmd buffer will be in change of
signalling semaphores as long as it meets some conditions:
1 - A GPU-job signals semaphores whenever we only have submitted
jobs for the same queue (there is no syncobj created for any
other type). Otherwise, we emit a noop job that waits on the
completion of all jobs submitted and then signals semaphores.
2 - A CPU-job is never in charge of signalling semaphores. We
process it first and emit a noop job that depends on all jobs
previously submitted to signal semaphores.
Signed-off-by: Melissa Wen <mwen@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13178>
With multiple semaphore support, we can improve the way we handle
wait semaphores considering different job types and cmd buffer
batch scenarios, that means:
- A GPU job depends on wait semaphores whenever it is the first job
submitted to a queue in this command buffer batch (the `first` flag
for the job's queue type is set).
- For the first CPU job, if there are wait semaphores, we should
wait for the CPU and GPU being idle to process the job.
Signed-off-by: Melissa Wen <mwen@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13178>
The order in which a GPU job is scheduled is guaranteed within the
same queue type (CL, TFU, CSD), but the order of completion of jobs
from different queues cannot be guaranteed. Since we have multiple
semaphores support now, we can track the completion of the last job
submitted to each queue and therefore better determine when gpu is
idle. We do it using an array of syncobj (last_job_syncs) for each
GPU queue (CL, TFU, CSD). With this, job serialization also become
more accurate. We also keep tracking the very last job submitted
(last_job_sync became an element of the last_job_syncs array as
V3DV_QUEUE_ANY) for the case we don't have multisync support.
To help in handling wait semaphores, we set a flag per queue to
indicate we are starting a new cmd buffer batch and a job submitted
to this queue will be the first.
Signed-off-by: Melissa Wen <mwen@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13178>
In addition to keep a copy of wait semaphores, extend
v3dv_submit_info_semaphores to hold a copy of signal semaphores too.
With a copy of wait and signal semaphores, we can enable GPU jobs to
handle more than one wait and signal semaphores.
By now, we don't change the way as we signalling semaphores when all
jobs complete, i.e., we still use the master thread to signal
semaphores. In this context, no GPU job is actually in charge of
signalling, but the support for multiple signal semaphores is done
here.
Signed-off-by: Melissa Wen <mwen@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13178>
Whenever v3d kernel-driver supports multisync extension, use it to
enable more than one semaphores in a tfu job.
Signed-off-by: Melissa Wen <mwen@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13178>
Whenever v3d kernel-driver supports multisync extension, use it to
enable more than one semaphores in cl submission. In CL, we have two
kind of job (bin and render), therefore, we need also to determine
the stage to sync, that means to add job dependencies/wait
semaphores.
Also, as we currently process all signal semaphores of a cmd buffer
batch together in the submit master thread (when the last wait
thread completes), there isn't now a situation in which GPU jobs
need to handle signal VkSemaphores.
Signed-off-by: Melissa Wen <mwen@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13178>
Extends command submission ioctls to support multiple semaphores through
generic ioctl extension design. In this approach, a multisync extension
subclasses a generic ioctl extension struct (base) and enables more than
one wait and signal semaphores. Multisync extension also uses v3d_queue
to specify the wait_stage, i.e. which job should sync before start (wait
semaphores).
Signed-off-by: Melissa Wen <mwen@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13178>
Instead of a boolean (sem_wait) in v3dv_event_wait_cpu_job_info,
that is used to determine wait condition for jobs put in a wait
thread, copy the wait semaphores data and store it as struct
v3dv_submit_info_semaphores. In the following patches we enable
multiple semaphores in GPU jobs, and therefore we need this data
to add wait semaphores as job dependencies for pending jobs
submitted from a wait thread.
Signed-off-by: Melissa Wen <mwen@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13178>
Instead of pass pSubmit to queue_submit_cmd_buffer, create a struct
v3dv_submit_info_semaphores to wrap semaphores data from VkSubmitInfo.
In the next commit, this struct will help to handle wait condition for
jobs submitted in a wait event context, since we need to hold this
data when handle wait events and pass it to queue_submit_job() called
from wait threads. The main goal is to allow multiple wait semaphores
in a job submission. Later, this struct will be extended to include a
copy of signal semaphores too.
Signed-off-by: Melissa Wen <mwen@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13178>
is_wait_thread is passed, but not actually used; and cpu_queue_handle_idle
is in charge to handle wait threads spawned before this one.
Signed-off-by: Melissa Wen <mwen@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13178>
Fixes the following valgrind warnings:
Conditional jump or move depends on uninitialised value(s)
at 0x5D1298C: draw_pt_so_emit_prepare (draw_pt_so_emit.c:95)
by 0x5D89FD7: llvm_middle_end_prepare (draw_pt_fetch_shade_pipeline_llvm.c:319)
by 0x5D13BFF: vsplit_prepare (draw_pt_vsplit.c:229)
by 0x5D0D5D8: draw_pt_arrays.isra.0 (draw_pt.c:124)
by 0x5D0DA08: draw_instances (draw_pt.c:484)
by 0x5D0DEB9: draw_vbo (draw_pt.c:610)
by 0x5E847D6: r300_swtcl_draw_vbo (r300_render.c:901)
by 0x5D67125: u_vbuf_draw_vbo (u_vbuf.c:1470)
by 0x5CFCAD3: cso_multi_draw (cso_context.c:1639)
by 0x58FEC37: st_draw_gallium (st_draw.c:186)
by 0x5A486BA: _mesa_draw_arrays.part.0 (draw.c:1323)
by 0x48B4E27: stub_glDrawArrays (piglit-dispatch-gen.c:12421)
Uninitialised value was created by a stack allocation
at 0x5E90D3F: r300_draw_init_vertex_shader (r300_vs_draw.c:313)
Conditional jump or move depends on uninitialised value(s)
at 0x5D175D9: draw_create_vertex_shader (draw_vs.c:70)
by 0x5E90E7A: r300_draw_init_vertex_shader (r300_vs_draw.c:366)
by 0x5E8751F: r300_create_vs_state (r300_state.c:1950)
by 0x594453B: st_create_common_variant (st_program.c:888)
by 0x594720C: st_get_common_variant (st_program.c:973)
by 0x59484B6: st_precompile_shader_variant (st_program.c:1994)
by 0x59484B6: st_finalize_program (st_program.c:2056)
by 0x58F0571: st_program_string_notify (st_cb_program.c:128)
by 0x5928C9B: st_link_tgsi (st_glsl_to_tgsi.cpp:7514)
by 0x5904B53: st_link_shader (st_glsl_to_ir.cpp:178)
by 0x58D3E08: _mesa_glsl_link_shader (link_program.cpp:91)
by 0x58865C7: link_program (shaderapi.c:1363)
by 0x58865C7: link_program_error.part.0 (shaderapi.c:1474)
by 0x48DBC5A: stub_glLinkProgram (piglit-dispatch-gen.c:34426)
Uninitialised value was created by a stack allocation
at 0x5E90D4F: r300_draw_init_vertex_shader (r300_vs_draw.c:313)
Based on Filip Gawin's
r300: set new_vs.type to PIPE_SHADER_IR_TGSI
CC: mesa-stable
Reviewed-by: Emma Anholt <emma@anholt.net>
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14620>
Adam Jackson
Bas Nieuwenhuizen
Charles Baker
Rhys Perry
Alejandro Piñeiro
Melissa Wen
Pierre-Eric Pelloux-Prayer
Samuel Pitoiset
Pavel Ondračka
Dave Airlie