In that case, we have to wait for the fence to synchronize with the
corresponding drawing we triggered in the X server.
Fixes incorrect display with the i965 driver and some applications, e.g.
solvespace.
Bugzilla: https://bugs.freedesktop.org/108097
Fixes: aefac10fec "loader/dri3: Only wait for back buffer fences in
dri3_get_buffer"
Tested-by: Sergii Romantsov <sergii.romantsov@globallogic.com>
We only need to wait for the fence before drawing to a buffer, not
before reading from it.
This might avoid hangs when re-allocating the fake front buffer, similar
to the previous change. But I haven't seen any evidence that this was
actually happening in practice.
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
We don't need to wait before drawing to the fake front buffer, as front
buffer rendering by definition is allowed to produce artifacts.
Fixes hangs in some cases when re-using the fake front buffer, due to it
still being busy (i.e. in use for presentation).
Cc: mesa-stable@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/106404
Bugzilla: https://bugs.freedesktop.org/107757
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
This helper is almost a 1:1 copy of tegra_open_render_node().
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
drirc implementation of MESA_LOADER_DRIVER_OVERRIDE which can be
used to override dri driver to load.
Usage:
override dri driver for device with spec kernel driver name:
<device kernel_driver="kernel_driver_name">
<option name="dri_driver" value="new_dri_driver" />
</device>
or
<device driver="loader" kernel_driver="kernel_driver_name">
<option name="dri_driver" value="new_dri_driver" />
</device>
v2:
add kernel_driver device attribute to specify kernel
driver name instead of reuse driver attribute
v3:
seperate loader_get_kernel_driver_name into another patch
seperate add kernel_driver attribute into another patch
Suggested-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>
Acked-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
[v4 Emil: add HAVE_LIBDRM guard around __driConfigOptionsLoader and
loader_get_dri_config_driver]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
This attribute can be used by loader to apply different
option to device use specific kernel driver.
Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>
Acked-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This function can be shared by the following kernel_driver
drirc patch.
Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>
Acked-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Detect if the display (X-Server) gpu and Prime renderoffload gpu prefer
different channel ordering for color depth 30 formats ([X/A]BGR2101010
vs. [X/A]RGB2101010) and perform format conversion during the blitImage()
detiling op from tiled backbuffer -> linear buffer.
For this we need to find the visual (= red channel mask) for the
X-Drawable used to display on the server gpu. We use the same proven
logic for finding that visual as in commit "egl/x11: Handle both depth
30 formats for eglCreateImage()".
This is mostly to allow "NVidia Optimus" at depth 30, as Intel/AMD
gpu's prefer xRGB2101010 ordering, whereas NVidia gpu's prefer
xBGR2101010 ordering, so we can offload to nouveau without getting
funky colors.
Tested on Intel single gpu, NVidia single gpu, Intel + NVidia prime
offload with DRI3/Present.
Note: An unintended but pleasant surprise of this patch is that it also
seems to make the modesetting-ddx of server 1.20.0 work at depth 30
on nouveau, at least with unredirected "classic" X rendering, and
with redirected desktop compositing under XRender accel, and with OpenGL
compositing under GLX. Only X11 compositing via OpenGL + EGL still gives
funky colors. modesetting-ddx + glamor are not yet ready to deal with
nouveau's ABGR2101010 format, and treat it as ARGB2101010, also exposing
X-visuals with ARGB2101010 style channel masks. Seems somehow this triggers
the logic in this patch on modesetting-ddx + depth 30 + DRI3 buffer sharing
and does the "wrong" channel swizzling that then cancels out the "wrong"
swizzling of glamor and we end up with the proper pixel formatting in
the scanout buffer :). This so far tested on a NVA5 Tesla card under KDE5
Plasma as shipping with Ubuntu 16.04.4 LTS.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
get_supported_modifiers() and pixmap_from_buffers() requests both
expect a window as drawable, passing a pixmap will fail as the Xserver
will fail to match the given drawable to a window.
That leads to dri3_alloc_render_buffer() to return NULL and breaks
rendering when using GLX_DOUBLEBUFFER on pixmaps.
Query the root window of the pixmap on first init, and use the root
window instead of the pixmap drawable for get_supported_modifiers()
and pixmap_from_buffers().
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107117
Fixes: 069fdd5 ("egl/x11: Support DRI3 v1.1")
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Prevents corrupting the upper 32 bits of draw->recv_sbc when
draw->send_sbc resets to 0 (which currently happens when the window is
unbound from a context and bound to one again), which in turn caused
loader_dri3_swap_buffers_msc to calculate target_msc with corrupted
upper 32 bits. This resulted in hangs with the Xorg modesetting driver
as of xserver 1.20 (older versions and other drivers ignored the upper
32 bits of the target MSC, which is why this wasn't noticed earlier).
Cc: mesa-stable@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/106351
Tested-by: Mike Lothian <mike@fireburn.co.uk>
And only free no longer needed back buffers there as well.
We want to stick to the same back buffer throughout a frame, otherwise
we can run into various issues.
Bugzilla: https://bugs.freedesktop.org/105906
Bugzilla: https://bugs.freedesktop.org/106399
Fixes: 3160cb86aa "egl/x11: Re-allocate buffers if format is suboptimal"
Reported-by: Sergii Romantsov <sergii.romantsov@globallogic.com>
Tested-by: Eero Tamminen <eero.t.tamminen@intel.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Add format definition and required plumbing to create images.
Note that there is no match to drm_fourcc definition, just like
with existing _DRI_IMAGE_FOURCC_SARGB8888.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The previous commit to make DRI3 modifier support optional, breaks with
an updated server and old client.
Make sure we never set multibuffers_available unless we also support it
locally. Make sure we don't call stubs of new-DRI3 functions (or empty
branches) which will never succeed.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Fixes: 7aeef2d4ef ("dri3: allow building against older xcb (v3)")
I'm not sure everyone wants to be updating their dri3 in a forced
march setting, this allows a nicer approach, esp when you want
to build on distro that aren't brand new.
I'm sure there are plenty of ways this patch could be cleaner,
and I've also not built it against an updated dri3.
For meson I've just left it alone, since if you are using meson
you probably don't mind xcb updates, and if you are using meson
you can fix this better than me.
v3: just don't put a version in for dri3/present without
modifiers, should allow building with 1.11 as well
(feel free to supply meson followups)
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
We're already including it in the meson build. This fixes build issues
on systems which have a drm_fourcc.h that doesn't have modifiers.
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
If PresentCompleteNotify event says the pixmap was presented
with mode PresentCompleteModeSuboptimalCopy, it means the pixmap
could possibly have been flipped instead if allocated with a
different format/modifier.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
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>
ARM SoCs usually have their DRM/KMS devices on the platform bus, so add
support for this bus in order to allow use of the DRI_PRIME environment
variable with those devices.
While at it, also support the host1x bus, which is effectively the same
but uses an additional layer in the bus hierarchy.
Note that it isn't enough to support the bus that has the rendering GPU
because the loader code will also try to construct an ID path tag for a
scanout-only device if it is the default that is being opened.
The ID path tag for a device can be obtained by running udevadm info on
the device node, as shown in this example on NVIDIA Tegra:
$ udevadm info /dev/dri/card0 | grep ID_PATH_TAG
E: ID_PATH_TAG=platform-50000000_host1x
The corresponding OF_FULLNAME property, from which the ID_PATH_TAG is
constructed, can be found in the sysfs "uevent" attribute for the card0
device's parent:
$ grep OF_FULLNAME /sys/devices/platform/50000000.host1x/drm/uevent
OF_FULLNAME=/host1x@50000000
Similarily, /dev/dri/card1 corresponds to the GPU:
$ udevadm info /dev/dri/card1 | grep ID_PATH_TAG
E: ID_PATH_TAG=platform-57000000_gpu
and:
$ grep OF_FULLNAME /sys/devices/platform/57000000.gpu/uevent
OF_FULLNAME=/gpu@57000000
Changes in v2:
- avoid confusing pre-increment in strdup()
- add examples of tags to commit message
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Thierry Reding <treding@nvidia.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>
My build was producing:
../src/loader/loader.c:121:67: warning: ‘%1u’ directive output may be truncated writing between 1 and 3 bytes into a region of size 2 [-Wformat-truncation=]
and we can avoid this careful calculation by just using asprintf (as we do
elsewhere in the file).
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.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>
This adds the meson.build, meson_options.txt, and a few scripts that are
used exclusively by the meson build.
v2: - Remove accidentally included changes needed to test make dist with
LLVM > 3.9
Signed-off-by: Dylan Baker <dylan.c.baker@intel.com>
Acked-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Emil Velikov <emil.velikov@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>
This was covering for underinkage elsewhere. With that fixed these can
be removed.
v2: - sort dependencies
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Reviewed-by: Jon Turney <jon.turney@dronecode.org.uk> (v1)
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (v1)
Reviewed-by: Emil Velikov <emil.velikov@collabora.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>
While at it, drop the duplicate return.
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Emil Velikov <emli.velikov@collabora.com>
Reduce code duplication and automatically benefit from OS-specific
fixes to libdrm (e.g. in FreeBSD ports).
API was introduced with 2.4.74 and we already require 2.4.75 globally.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103283
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Rather than group dependencies in complex groups, use a flatter
structure with split dependencies to avoid checking for the same
dependencies twice.
v2: - Fix building vulkan drivers without gallium or dri drivers
v3: - Drop TODO comment that is done
- Fix typo in commit message
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This gets GLX and the loader building. The resulting GLX and i965 have
been tested on piglit and seem to work fine. This patch leaves a lot of
todo's in it's wake, GLX is quite complicated, and the build options
involved are many, and the goal at the moment is to get dri and gallium
drivers building.
v2: - fix typo "vaule" -> "value"
- put the not on the correct element of the conditional
- Put correct description of dri3 option in this patch not the next
one (Eric A)
- fix non glvnd version (Eric A)
- build glx tests
- move loader include variables to this patch (Eric A)
v3: - set the version correctly for GL_LIB_NAME in libglx
v4: - set pkgconfig private fields
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
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>
