Add support for DRI3 v1.1, which allows pixmaps to be backed by
multi-planar buffers, or those with format modifiers. This is both
for allocating render buffers, as well as EGLImage imports from a
native pixmap (EGL_NATIVE_PIXMAP_KHR).
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
The DRI3 drawable info struct currently stores a boolean for whether the
last completed operation was a flip or not. As we need to track the full
completion mode for handling suboptimal returns, change the 'flipping'
field to the raw present completion mode from the server.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Removing this callback caused rendering corruption in some multi-screen cases,
so it is reinstated but without the drawable argument which was never used
by implementations and was confusing since the drawable could have been
created with another screen.
Cc: "17.3 18.0" mesa-stable@lists.freedesktop.org
Fixes: 5198e48a0d (loader_dri3/glx/egl: Remove the loader_dri3_vtable get_dri_screen callback)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105013
Reported-by: Daniel van Vugt <daniel.van.vugt@canonical.com>
Tested-by: Timo Aaltonen <tjaalton@ubuntu.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
It was assumed that fromPlanar() could return NULL to mean
that the planar image is the same as the parent DRI image.
That assumption wasn't made everywhere though.
Let's fix things and make sure that all callers understand
a NULL result
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
We were using a sequence counter value to wait for a specific NotifyMSC
event. However, we can receive events from other clients as well, which
may already be using higher sequence numbers than us. In that case, we
could stop processing after an event from another client, which could
have been received significantly earlier. This would have multiple
undesirable effects:
* The computed MSC and UST values would be lower than they should be
* We could leave a growing number of NotifyMSC events from ourselves and
other clients in XCB's special event queue
I ran into this with Firefox and Thunderbird, whose VSync threads both
seem to use the same window. The result was sluggish screen updates and
growing memory consumption in one of them.
Fix this by checking the XCB sequence number and MSC value of NotifyMSC
events, instead of using our own sequence number.
v2:
* Use the Present event ID for the sequence parameter of the
PresentNotifyMSC request, as another safeguard against processing
events from other clients
* Rebase on drawable mutex changes
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> # v1
Upon reception of an event that lowered the number of active back buffers,
the code would immediately try to free all back buffers with an id equal to or
higher than the new number of active back buffers.
However, that could lead to an active or to-be-active back buffer being freed,
since the old number of back buffers was used when obtaining an idle back
buffer for use.
This lead to crashes when lowering the number of active back buffers by
transitioning from page-flipping to non-page-flipping presents.
Fix this by computing the number of active back buffers only when trying to
obtain a new back buffer.
Fixes: 15e208c4cc ("loader/dri3: Don't accidently free buffer holding new back content")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104214
Cc: "17.3" <mesa-stable@lists.freedesktop.org>
Tested-by: Andriy.Khulap <andriy.khulap@globallogic.com>
Tested-by: Vadym Shovkoplias <vadym.shovkoplias@globallogic.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
To allow DRI3/Present buffer sharing for 10 bpc buffers.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
It turned out that with recent changes that call into dri3 from glFinish(),
it appears like different thread end up waiting for X events simultaneously,
causing deadlocks since they steal events from eachoter and update the dri3
counters behind eachothers backs.
This patch intends to improve on that. It allows at most one thread at a
time to wait on events for a single drawable. If another thread intends to
do the same, it's put to sleep until the first thread finishes waiting, and
then it rechecks counters and optionally retries the waiting. Threads that
poll for X events never pulls X events off the event queue if there are
other threads waiting for events on that drawable. Counters in the
dri3 drawable structure are protected by a mutex. Finally, the mutex we
introduce is never held while waiting for the X server to avoid
unnecessary stalls.
This does not make dri3 drawables completely thread-safe but at least it's a
first step.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102358
Fixes: d5ba75f888 "st/dri2 Plumb the flush_swapbuffer functionality through to dri3"
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Acked-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Avoid freeing buffers holding new back content
(with GLX_SWAP_COPY_OML and GLX_SWAP_EXCHANGE_OML)
Prevously that would have resulted in back buffer content becoming
incorrect after a swap, although I haven't managed to trigger such a
situation yet.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Resize only in loader_dri3_get_buffers(),
where the dri driver has a chance to immediately update the viewport.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
When a drawable is resized, and we fill the resized buffers, with data
from the old buffers, use a local blit if there is a local buffer (back or
fake front), and we have local blitting capability.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
If we're seeing a drawable size change, in particular after processing a
configure notify event, make sure we invalidate so that the state tracker
picks up the new geometry.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
This tries to mimic dri2 behaviour where events are typically processed
while waiting for X replies. Since, during steady-state dri3 rendering, we
seldom wait for xcb replies, and haven't enabled any automatic event
processing, instead check for events after a fence wait.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
The copySubBuffer functionality always attempted a server side blit from
back to fake front if a fake front was present, and we weren't displaying
on a remote GPU.
Now that we always have local blit capability on modern drivers, first
attempt a local blit, and only if that fails, try the server blit.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Axel Davy <axel.davy@normalesup.org>
With GLX_SWAP_COPY_OML and GLX_SWAP_EXCHANGE_OML it may happen in situations
when glXSwapBuffers() is immediately followed by for example another
glXSwapBuffers() or glXCopyBuffers() or back buffer age querying, that we
haven't yet allocated and initialized a new back buffer because there was
no GL rendering in between.
Make sure that we have a back buffer in those situations.
v2: Eliminate the drawable have_back_format member.
v3: Make sure we re-initialize the back even if it exists.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Add support for the exchange swap method. Since we're now forcing a fake front
buffer and we exchange the back and fake front on swaps, we don't need to add
much code.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Eliminate the back-to-fake-front copy by exchanging the previous back buffer
and the fake front buffer. This is a gain except when we need to preserve
the back buffer content but in that case we still typically gain by replacing
a server-side blit by a client side non-flushing blit.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
It's not used anywhere and now that we're about to exchange back- and
fake fronts it doesn't serve a purpose.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Support the GLX_SWAP_COPY_OML method. When this method is requested, we use
the same swapbuffer code path as EGL_BUFFER_PRESERVED.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
EGL uses the force_copy parameter to loader_dri3_swap_buffers_msc() to indicate
that it wants to preserve back buffer contents across a buffer swap.
While the loader then turns off server-side page-flipping there's nothing to
guarantee that a new backbuffer isn't chosen when EGL starts to render again,
and that buffer's content is of course undefined.
So rework the functionality:
If the client supports local blits, allow server-side page flipping and when
a new back is grabbed, if needed, blit the old back's content to the new back.
If the client doesn't support local blits, disallow server-side page-flipping
to avoid a client deadlock and then, when grabbing a new back buffer, sleep
until the old back is idle, which may take a substantial time depending on
swap interval.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
The code was relying on us always having a current context for client local
image blit operations. Otherwise the blit would be skipped. However,
glxSwapBuffers, for example, doesn't require a current context and that was a
common problem in the dri1 era. It seems the problem has resurfaced with dri3.
If we don't have a current context when we want to blit, try creating a private
dri context and maintain a context cache of a single context.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
It's not very usable since in the rare, but definitely existing case that
we don't have a current context, it will return NULL.
Presumably it will always be safe to use the dri screen the drawable was
created with for operations on that drawable.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Having two callbacks to manage a single int seems like an overkill.
Use a cached copy and update that when needed.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
---
Might want to look if the dimensions dance in .query_surface ...
speaking of which close to nobody implements that ...
This implements a wait for glXWaitGL, glXCopySubBuffer, dri flush_front and
creation of fake front until all pending SwapBuffers have been committed to
hardware. Among other things this fixes piglit glx-copy-sub-buffers on dri3.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: <mesa-stable@lists.freedesktop.org>
As of last commit, no invalid swap interval can be stored, so there's
no need to sanitize the values when reading them anymore.
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
If the application hasn't done any drawing since the last call, we
would reuse the same back buffer which was used for the previous swap,
which may not have completed yet. This could result in various issues
such as tearing or application hangs.
In the normal case, the behaviour is unchanged.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97957
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101683
Cc: mesa-stable@lists.freedesktop.org
[Michel Dänzer: Make Thomas' fix from bugzilla actually work as
intended, write commit log]
This is a DRI3 version of a change made for DRI2
(4d6d4f939e, "egl/dri2: implement query surface hook"),
that fixed failures in dEQP-EGL.functional.resize.surface_size.grow
and dEQP-EGL.functional.resize.surface_size.shrink.
Cc: Tapani Pälli <tapani.palli@intel.com>
Cc: Mark Janes <mark.a.janes@intel.com>
Cc: Chad Versace <chadversary@chromium.org>
Signed-off-by: Brendan King <Brendan.King@imgtec.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Cc: "17.0" <mesa-stable@lists.freedesktop.org>
This tries to mirrors the codepath taken by DRI2 in IntelSetTexBuffer2()
and fixes many applications when using DRI3:
- Totem with libva on hw-accelerated decoding
- obs-studio, using Window Capture (Xcomposite) as a Source
- gstreamer with VAAPI
v2:
- introduce get_dri_screen() in the dri3 loader's vtable (krh)
Tested-by: Timo Aaltonen <tjaalton@ubuntu.com>
Tested-by: Ionut Biru <biru.ionut@gmail.com>
Cc: mesa-stable@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71759
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Martin Peres <martin.peres@linux.intel.com>
This can make a significant difference for performance with some extreme
test cases such as vblank_mode=0 glxgears.
Fixes: 1e3218bc5b ("loader/dri3: Overhaul dri3_update_num_back")
Cc: "12.0 11.2" <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97549
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Always use 3 buffers when flipping. With only 2 buffers, we have to wait
for a flip to complete (which takes non-0 time even with asynchronous
flips) before we can start working on the next frame. We were previously
only using 2 buffers for flipping if the X server supports asynchronous
flips, even when we're not using asynchronous flips. This could result
in bad performance (the referenced bug report is an extreme case, where
the inter-frame stalls were preventing the GPU from reaching its maximum
clocks).
I couldn't measure any performance boost using 4 buffers with flipping.
Performance actually seemed to go down slightly, but that might have
been just noise.
Without flipping, a single back buffer is enough for swap interval 0,
but we need to use 2 back buffers when the swap interval is non-0,
otherwise we have to wait for the swap interval to pass before we can
start working on the next frame. This condition was previously reversed.
Cc: "12.0 11.2" <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97260
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Without this, the X server may accumulate stale Present event contexts
if a client ends up creating and destroying DRI drawables for the same
window.
v2: Based on Chris Wilson's review:
* Use xcb_present_select_input_checked so that protocol errors
generated by old X servers can be handled gracefully
* Use xcb_discard_reply() instead of free(xcb_request_check())
Used to support EGL_KHR_image_pixmap.
Signed-off-by: Boyan Ding <boyan.j.ding@gmail.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.co.uk>
v2: From Martin Peres
- Try to fit in the 80-col limit as much as possible
v3: From Martin Peres
- introduce loader_dri3_helper.la to avoid dragging the xcb dep everywhere (Kristian & Emil)
- get rid of the width, height, dri_screen and is_different_gpu vfuncs (Kristian)
- replace the create/destroy functions with init/fini for dri3 drawables
- prefix static functions with dri3_ and exported ones with loader_dri3 (Emil)
- keep the function definition consistent (Emil)
Signed-off-by: Boyan Ding <boyan.j.ding@gmail.com>
Signed-off-by: Martin Peres <martin.peres@linux.intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.co.uk>
Louis-Francis Ratté-Boulianne
Daniel Stone
Thomas Hellstrom
Ilia Mirkin
Michel Dänzer
Mario Kleiner
Emil Velikov
Eric Engestrom
Brendan King
Boyan Ding
Emil Velikov
Martin Peres
Jan Ziak
Axel Davy