In some situations we can have multiple present queued
with the same target_msc and in this case we might get
the last one signaled before the previous ones. Here's
an example with some debug logs added to the relevant
functions:
loader_dri3_swap_buffers_msc: new send_sbc=2323 - target_msc=337
dri3_handle_present_event: old recv_sbc=2322 msc=338 new_recv_sbc=2323
loader_dri3_swap_buffers_msc: new send_sbc=2324 - target_msc=338
dri3_handle_present_event: old recv_sbc=2323 msc=338 new_recv_sbc=2324
loader_dri3_swap_buffers_msc: new send_sbc=2325 - target_msc=338
dri3_handle_present_event: old recv_sbc=2324 msc=338 new_recv_sbc=2325
loader_dri3_swap_buffers_msc: new send_sbc=2326 - target_msc=338
loader_dri3_swap_buffers_msc: new send_sbc=2327 - target_msc=338
loader_dri3_swap_buffers_msc: new send_sbc=2328 - target_msc=338
dri3_handle_present_event: old recv_sbc=2325 msc=338 new_recv_sbc=2327
loader_dri3_swap_buffers_msc: new send_sbc=2329 - target_msc=338
dri3_handle_present_event: old recv_sbc=2327 msc=338 new_recv_sbc=2328
loader_dri3_swap_buffers_msc: new send_sbc=2330 - target_msc=338
dri3_handle_present_event: old recv_sbc=2328 msc=338 new_recv_sbc=2329
loader_dri3_swap_buffers_msc: new send_sbc=2331 - target_msc=338
dri3_handle_present_event: old recv_sbc=2329 msc=338 new_recv_sbc=2330
dri3_handle_present_event: old recv_sbc=2330 msc=338 new_recv_sbc=2326 # oops
dri3_handle_present_event: old recv_sbc=2326 msc=339 new_recv_sbc=2331
It's usually harmless, except if Mesa ends up using
loader_dri3_swapbuffer_barrier right after the out-of-order event.
In this example it's ok because more swaps are executed after 2330, so
waiting for read_sbc>=2330 would work anyway.
But if this wasn't the case, loader_dri3_swapbuffer_barrier would never
return, waiting for recv_sbc to become >= 2330 while it's stuck at 2326
because the later swaps were processed earlier.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39857>
This prevents re-entering the flush if during the flush
of a context X we end up in vbo_exec_FlushVertices_internal.
I had this issue on one machine, with the following simplified
call sequence:
glthread_unmarchash_batch
...
vbo_exec_FlushVertices(ctxA)
...
st_validate_state
...
dri3_get_buffer
loader_dri3_blit_context_get
...
dri_destroy_context(ctxB)
...
_mesa_make_current(ctxB)
vbo_exec_FlushVertices(ctxA)
The last vbo_exec_FlushVertices would hit the assert checking
flush_call_depth == 1.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39857>
I don't know why but these seem to fail only intermittantly now.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
As a side-effect, we're now also respecting storeOp for separate Z/S.
For interleaved, we still always store because interleaved is annoyingly
complicated.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
The new framebuffer code properly handles attachments without a store
and the incremental rendering code doesn't rely on the store, either, so
we don't need to always store.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
This is mostly a matter of reworking the frame shader code to pull image
views from a temp struct instead of always reaching for the pan_fb_load.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
We already have this check for the JM back-end but the CSF back-end
based the choice on whether or not the shader is writing color which
isn't quite what we want.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
This makes cmd_emit_dcd() about actually emitting the DCD and moves the
bit that's operation-specific to the operation-specific function.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Also rename some stuff internally to stop using the word "preload".
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Instead of having the pan_fb code have to `max(rt_count, 1)` add then
constantly be doing the same in the driver, just make the condition an
assert and do the `max(colorAttachmentCount, 1)` up-front. This way
we're not constantly worried if everyone has the same count or not. The
pan_fb code will handle having an empty render target just fine.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
The resolve sits between the render pass and the write at the end. This
adds the resolve ops themselves, support in the shader builder for
building the post-frame shaders to handle them, and an optimization pass
that attempts to fold the resolve op into the store and potentially
eliminate the post-frame shader.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
This commit both adds a couple more MSAA modes and adds support for them
in shaders. While resolving an image into a framebuffer isn't that
interesting, most of the code to do it will be reused for resolving
render targets, which we do want. The refactor is also nice.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
This generalizes the shader building code at the cost of an additional
level of abstraction through the pan_fb_shader_op enum. This will let
us share code between load and resolve shaders while keeping the client
interfaces to both of those clean and idiomatic.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Right now, we have this concept of sections where one packet can be
broken up into multiple sub-packets. Currently, we handle ths by every
packet's `_packed` struct is just an array of `uint32_t` and we do
pointer math and cast to get at the subset of the `uint32_t` array
belonging to the given section. This works okay if we're operating on
`void *` but it blows up on strict aliasing rules if we're ever trying
to pack sections into a `struct foo_packed` on the stack.
To work around this, make it so that anything with sections emits
something like this:
struct foo_packed {
union {
uint32_t packed[N];
struct {
struct foo_sec1_packed sec1;
struct foo_sec2_packed sec2;
};
};
};
This is entirely safe because C allows unions and structs to overlap as
long as the members that have the same base type end up on top of each
other. Since everything is a `uint32_t` internally, this is safe
according to the C pointer rules. And now that everything is a
substruct, everything is nicely named and we can easily get to sections
without pointer magic.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Now that we're doing a merge to fill out the various enable bits, we
don't actually need the pan_fb_info in the attachment helpers.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Previously, when we had an unaligned render area, we would flush to
force a full FB load and then clear the render area manually after
loading. This means we're doing a full FB load and then throwing most
of that data away.
The new FB load shaders, however, are capable of doing partial loads,
with the inside of the render area loaded or cleared as we wish and the
border pixels loaded. This way we can handle partial clears directly in
the load shaders instead of having to do this dance. This should
improve perf whenever a non-trivial render area is used.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
We already had this for LOAD_OP_DONT_CARE but we also need it for
LOAD_OP_NONE.
Cc: mesa-stable
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
The current code looks a lot like how you might do this in GL. We start
off with the load, which might be loads or clears. Then, after the
first flush, we replace that with the spill load. This doesn't really
fit the load/spill/store that the new pan_fb code wants.
Instead, this commit add a couple of separate tracker bits to keep track
of whether or not we've loaded yet and whether or not we're in the final
EndRendering and want to do the "real" store. This allows us to track
where we are in the render pass and do the right load/spill/store
operations.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
The old code was all out of order and made no sense. There's a reason
it made no sense. It was wrong. Cleaning this up fixes a solid 1/3 of
the remaining Bifrost CTS fails in CI.
Cc: mesa-stable
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
cc: mesa-stable
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
The Vulkan spec says that aspects are ignored for Z/S attachments so we
shouldn't consider that as a factor when deciding whether or not to
create other aspect descriptors. This will be irrelevant in a couple of
commits but we need it for the backport anyway.
Cc: mesa-stable
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Instead of smashing the pan_fb_info, use the spill pan_fb_load to
re-generate it from scratch. This should make basically the same change
to the pan_fb_info that we made before, just using the decisions made at
CmdBeginRendering() time as a guide.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
The only functional change is that the new code doesn't reserve space
for dummy allocations. However, the old code never actually took dummy
allocations into account when placing RTs so they end up overlapping
anyway and it's not causing problems. Also, we set rt_count when there
are no attachments and that doesn't reserve dummy space so clearly
running with zero attachments is fine.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
For now, both exist simultaneously and we'll try to keep them in sync.
Eventually, everything will be converted to the new structs and we'll
drop the old.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
