Allocates VRAM in display GPU in case of prime. Then the dma_buf is imported
into prime GPU.
v2: add comments to make code more readable (Pierre-Eric)
removed if check limiting p2p only for matching driver name
v3: keep old path for non mesa driver (Michel Dänzer)
v4: destroy linear_buffer_display_gpu after import (Michel Dänzer)
fall back if linear_buffer_display_gpu alloc fail (Michel Dänzer)
Signed-off-by: Yogesh Mohanmarimuthu <yogesh.mohanmarimuthu@amd.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10595>
The created DRI screen can be used to allocate VRAM memory from
display GPU in case of prime.
v2: add comments to make code readable (Pierre-Eric)
remove driver name match check
v3: keep old path for non-mesa driver (Michel Dänzer)
v4: fallback if driver not found for display GPU (Michel Dänzer)
fallback if create screen fail for display gpu (Michel Dänzer)
Signed-off-by: Yogesh Mohanmarimuthu <yogesh.mohanmarimuthu@amd.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10595>
The wayland EGL platform sets the modifier count to 0 in some cases
to signal that modifiers should not be used, even if a list of modifiers
is present. The loader_dri_create_image helper didn't handle this case
properly and called the modifierful driver interface with a 0 modifier
count, leading to the obvious outcome of the driver being unable to
allocate an image.
Fixes: cb9ae4273d ("dri: add loader_dri_create_image helper")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10903>
Call into the new modifiers with usage createImage variant when available
to provide the DRI implementation with more context about the allocation.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8106>
Get rid of the code duplication and makes it easier to hook in a
new createImageWithModifiers2, but obscures the code flow a bit.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8106>
The DRI image extension already has two different ways to allocate an
image (with and without a modifier) and will soon grow a third one.
Add a helper, which handles calling the appropriate implementation to
get rid of code duplication in the winsys.
This convert the two obvious call sites (GBM dri and EGL wayland)
that profit from the code dedup.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8106>
../src/loader/loader_dri3_helper.c: In function ‘dri3_free_buffers’:
../src/loader/loader_dri3_helper.c:2022:46: warning: ‘n_id’ may be used uninitialized in this function [-Wmaybe-uninitialized]
2022 | for (buf_id = first_id; buf_id < first_id + n_id; buf_id++) {
Can't happen, mark it unreachable.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8724>
With swap interval 0, i.e. sync-to-vblank disabled.
This can be necessary for unthrottled drawing with Xwayland:
1) One buffer can be scanned out
2) One buffer can be pending in the kernel for a page flip
3) One buffer can be pending in the Wayland compositor
Therefore, with 3 buffers, the frame-rate could be capped much lower
than the throughput the GPU is capable of, in the worst case at the
Wayland compositor refresh rate.
(The native Wayland EGL backend always uses up to 4 buffers)
Leave the maximum number of buffers at 3 for swap interval != 0, it's
sufficient in that case to always be able to queue one frame ahead of
time.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1455https://gitlab.gnome.org/GNOME/mutter/-/issues/1462
Cc: mesa-stable
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7033>
We'd previously take the copy path. If we were actually flipping (in
which case skipped frames are more likely to occur), we'd ping-pong
between a smaller and larger number of back buffers, and frame-rate
could vary / take a dip due to the buffer management overhead.
While I'm not sure this is actually possible to hit at this point, it
definitely will be with the next change.
Cc: mesa-stable
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7033>
Previously, we would always allocate 3 buffers for page flipping. But 2
buffers can suffice for clients which always wait for buffer swaps to
complete before starting a new frame.
Therefore, keep track of the maximum number of buffers separately from
the current number, and only bump the latter if both current buffers are
busy.
Cc: mesa-stable
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7033>
We can generate the XML if anybody actually queries it, but this reduces
the amount of work in driver setup and means that we'll be able to support
driconf option queries on Android without libexpat.
This updates the driconf interface struct version for i965, i915, and
radeon to use the new getXml entrypoint to call the on-demand xml
generation. Note that our loaders (egl, glx) implement the v2 function
interface and don't use .xml when that's set, and the X server doesn't use
this interface at all.
XML generation tested on iris and i965 using adriconf
Acked-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6916>
Passes all of `dEQP-EGL.functional.swap_buffers_with_damage.*`:
Passed: 36/54 (66.7%)
Failed: 0/54 (0.0%)
Not supported: 18/54 (33.3%)
Warnings: 0/54 (0.0%)
Waived: 0/54 (0.0%)
The "not supported" ones are the `preserve_buffer_*` tests, which is not
supported on X11/DRI3.
Cc: 20.2 <mesa-stable>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3030
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6132>
This adds applicationName + version through like engineName.
Rationale: A game (World War Z) includes the store name in the
executable name, so has multiple executable names.
CC: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6120>
If the underlying X11 window gets destroyed, the event we're waiting
for may never be delivered, in which case xcb_wait_for_special_event
would hang indefinitely.
Solution:
1. Use xcb_poll_for_special_event to check if an event has arrived yet.
2. If not, Wait up to ~1s for XCB's file descriptor to become readable;
if it does, go back to step 1.
3. If the file descriptor didn't become readable, make a round-trip to
the X server to check that the window still exists. Go back to step
1 if it does, otherwise bail.
Also add an early bail-out when it's known that the window was
destroyed.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/116
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5368>
Before, if one thread ended up waiting in dri3_wait_for_event_locked
and another one in loader_dri3_wait_for_msc at the same time, one thread
could end up processing an event the other thread was waiting for, which
could result in the latter thread waiting longer than necessary
(possibly indefinitely).
Noticed by inspection.
v2:
* Drop xcb_flush call from loader_dri3_wait_for_msc in favour of the one
in dri3_wait_for_event_locked (Kenneth Graunke)
Fixes: 7b0e8264dd "loader/dri3: Try to make sure we only process our
own NotifyMSC events"
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5368>
This uses a meson builtin to handle -fvisibility=hidden. This is nice
because we don't need to track which languages are used, if C++ is
suddenly added meson just does the right thing.
Acked-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4740>
Currently, if the PCI machinery fails, we return a NULL driver name.
In the past this has resulted in various workarounds.
To avoid those, fallback to loader_get_kernel_driver_name(). It's not
perfect, yet perfectly reasonable.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4084>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4084>
Move the message to the function which fetches the name.
While here use the same DEBUG/WARNING approach like in the PCI case. The
current method spam a tad much, plus isn't consistent.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4084>
Reoder the function a bit to make the code-flow more obvious and short.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4084>
Currently that's the hard-coded maximum in the kernel, even though the
libdrm API allows for more. Latter is done with extendability in mind.
Allocate 64 pointers^Wdevices on stack for now. Making for shorter and
ever-so-slightly faster code.
v2: Use single MAX_DRM_DEVICES #define (Eric)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com> (v1)
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4084>
This is definitely not the first time I've debugged why I'm getting swrast
on a device only to find out I'm not a member of the render node's group.
This does mean that you'll get a warning print even without EGL_LOG_LEVEL
set. This may be an issue if we expect people outside of the DRI node's
group to actually be using swrast instead of getting their permissions
fixed. Right now surfaceless throws a "libEGL warning: No hardware driver
found, falling back to software rendering" in that case anyway, so this is
just more informative.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3703>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3703>
This updates our product name strings to match the ones reported
by the Windows driver, which is typically the marketing name.
We retain a platform abbreviation and GT level in parenthesis so that
we're able to distinguish similar parts more easily, helping us better
understand at a glance which GPU a bug reporter has.
Acked-by: Matt Turner <mattst88@gmail.com>
Acked-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3371>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3371>
Using a drm syscall layer faking a kernel driver :
==581460== Conditional jump or move depends on uninitialised value(s)
==581460== by 0x48A4C2B: close (drm-hooks.cpp:185)
==581460== by 0x5A815F1: dri3_alloc_render_buffer (loader_dri3_helper.c:1469)
==581460== by 0x5A82050: dri3_get_buffer (loader_dri3_helper.c:1827)
==581460== by 0x5A82662: loader_dri3_get_buffers (loader_dri3_helper.c:2028)
==581460== by 0x6C78109: intel_update_image_buffers (brw_context.c:1870)
==581460== by 0x6C77805: intel_update_renderbuffers (brw_context.c:1499)
==581460== by 0x6C7789D: intel_prepare_render (brw_context.c:1520)
==581460== by 0x6C773D4: intelMakeCurrent (brw_context.c:1341)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 069fdd5f9f ("egl/x11: Support DRI3 v1.1")
Reviewed-by: Eric Anholt <eric@anholt.net>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3152>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3152>
Enabling this option makes Intel Gen8-11 hardware load the 'iris'
driver by default instead of the older 'i965' driver.
Regardless of how this option is set, users can still override which
driver the loader selects via two methods. The first is to create a
~/.drirc or /etc/drirc file with the following snippet:
<driconf>
<device driver="loader" kernel_driver="i915">
<option name="dri_driver" value="i965" />
</device>
</driconf>
The other option is to set an environment variable:
export MESA_LOADER_DRIVER_OVERRIDE=i965
For now, "prefer_iris" defaults to i965 (the historical choice).
A separate future patch will change the default driver to iris.
Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/1893
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
The existing "fallback" code didn't actually do anything, so this
removes it, and instead we just always fallback to `iris` for future
PCI IDs.
Suggested-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The list of AMD/ATI devices supported by radeon/r200/r300/r600 is
complete, so anything else must use radeonsi.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Meson automatically tracks any file included by a file it already tracks,
and `pci_id_driver_map.h` & `loader.h` are included by `loader.c`, while
`loader_dri3_helper.h` is included by `loader_dri3_helper.c`.
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
We were supplying __DRI2_THROTTLE_SWAPBUFFER, rather than the obvious
choice of __DRI2_THROTTLE_COPYSUBBUFFER. This meant that we hit the
swap-based frame throttling. glXCopySubBuffer doesn't seem like it's
intended to be a frame boundary, so we'd like to avoid this throttling.
Tested-by: Michel Dänzer <mdaenzer@redhat.com> # DRI3 only
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
0 is __DRI2_THROTTLE_SWAPBUFFER, which doesn't really make sense here.
Avoids dri_flush() throttling twice for the same glFlush call with front
buffer rendering, as described in
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2057 .
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Per the valgrind output below, we were returning the pointer to freed
memory if none of the later conditional pointer assignments were
executed. This caused dEQP CI jobs to crash on certain runners,
presumably due to a double-free down the line.
Also, we were skipping to the out: label before the vendor_id & chip_id
variables used by it were initialized, resulting in broken
LIBGL_DEBUG=verbose output such as
libGL: pci id for fd 4: 51108f00:51108f00, driver radeonsi
Fixes: 5a545e355b "loader: always map the "amdgpu" kernel driver name to radeonsi (v2)"
==403== Invalid read of size 1
==403== at 0x4AFD576: surfaceless_probe_device (platform_surfaceless.c:316)
==403== by 0x4AFD915: dri2_initialize_surfaceless (platform_surfaceless.c:391)
==403== by 0x4AF5EEA: dri2_initialize (egl_dri2.c:984)
==403== by 0x4AF5EEA: dri2_initialize (egl_dri2.c:958)
==403== by 0x4AF1EEC: _eglMatchAndInitialize (egldriver.c:75)
==403== by 0x4AF1F3B: _eglMatchDriver (egldriver.c:96)
==403== by 0x4AE9367: eglInitialize (eglapi.c:617)
==403== by 0x1D99C9: tcu::surfaceless::EglRenderContext::EglRenderContext(glu::RenderConfig const&, tcu::CommandLine const&) [clone .constprop.57] (in /deqp/modules/gles2/deqp-gles2)
==403== by 0x1DABB0: tcu::surfaceless::ContextFactory::createContext(glu::RenderConfig const&, tcu::CommandLine const&, glu::RenderContext const*) const (in /deqp/modules/gles2/deqp-gles2)
==403== by 0x53EBD1: glu::createRenderContext(tcu::Platform&, tcu::CommandLine const&, glu::RenderConfig const&, glu::RenderContext const*) (in /deqp/modules/gles2/deqp-gles2)
==403== by 0x53EFE9: glu::createDefaultRenderContext(tcu::Platform&, tcu::CommandLine const&, glu::ApiType) (in /deqp/modules/gles2/deqp-gles2)
==403== by 0x1DE07A: deqp::gles2::Context::Context(tcu::TestContext&) (in /deqp/modules/gles2/deqp-gles2)
==403== by 0x1DB5EF: deqp::gles2::TestPackage::init() (in /deqp/modules/gles2/deqp-gles2)
==403== Address 0x56bd340 is 0 bytes inside a block of size 4 free'd
==403== at 0x48369AB: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==403== by 0x4B01767: loader_get_driver_for_fd (loader.c:464)
==403== by 0x4AFD553: surfaceless_probe_device (platform_surfaceless.c:308)
==403== by 0x4AFD915: dri2_initialize_surfaceless (platform_surfaceless.c:391)
==403== by 0x4AF5EEA: dri2_initialize (egl_dri2.c:984)
==403== by 0x4AF5EEA: dri2_initialize (egl_dri2.c:958)
==403== by 0x4AF1EEC: _eglMatchAndInitialize (egldriver.c:75)
==403== by 0x4AF1F3B: _eglMatchDriver (egldriver.c:96)
==403== by 0x4AE9367: eglInitialize (eglapi.c:617)
==403== by 0x1D99C9: tcu::surfaceless::EglRenderContext::EglRenderContext(glu::RenderConfig const&, tcu::CommandLine const&) [clone .constprop.57] (in /deqp/modules/gles2/deqp-gles2)
==403== by 0x1DABB0: tcu::surfaceless::ContextFactory::createContext(glu::RenderConfig const&, tcu::CommandLine const&, glu::RenderContext const*) const (in /deqp/modules/gles2/deqp-gles2)
==403== by 0x53EBD1: glu::createRenderContext(tcu::Platform&, tcu::CommandLine const&, glu::RenderConfig const&, glu::RenderContext const*) (in /deqp/modules/gles2/deqp-gles2)
==403== by 0x53EFE9: glu::createDefaultRenderContext(tcu::Platform&, tcu::CommandLine const&, glu::ApiType) (in /deqp/modules/gles2/deqp-gles2)
==403== Block was alloc'd at
==403== at 0x483577F: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==403== by 0x4EE5E09: strndup (strndup.c:43)
==403== by 0x4B010B1: loader_get_kernel_driver_name (loader.c:101)
==403== by 0x4B016AF: loader_get_driver_for_fd (loader.c:462)
==403== by 0x4AFD553: surfaceless_probe_device (platform_surfaceless.c:308)
==403== by 0x4AFD915: dri2_initialize_surfaceless (platform_surfaceless.c:391)
==403== by 0x4AF5EEA: dri2_initialize (egl_dri2.c:984)
==403== by 0x4AF5EEA: dri2_initialize (egl_dri2.c:958)
==403== by 0x4AF1EEC: _eglMatchAndInitialize (egldriver.c:75)
==403== by 0x4AF1F3B: _eglMatchDriver (egldriver.c:96)
==403== by 0x4AE9367: eglInitialize (eglapi.c:617)
==403== by 0x1D99C9: tcu::surfaceless::EglRenderContext::EglRenderContext(glu::RenderConfig const&, tcu::CommandLine const&) [clone .constprop.57] (in /deqp/modules/gles2/deqp-gles2)
==403== by 0x1DABB0: tcu::surfaceless::ContextFactory::createContext(glu::RenderConfig const&, tcu::CommandLine const&, glu::RenderContext const*) const (in /deqp/modules/gles2/deqp-gles2)
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Yogesh Mohanmarimuthu
Lucas Stach
Adam Jackson
Tapani Pälli
Jose Fonseca
Pierre-Eric Pelloux-Prayer
Michel Dänzer
Eric Anholt
Eric Engestrom
Bas Nieuwenhuizen
Dylan Baker
Emil Velikov
Kenneth Graunke
Samuel Thibault
Lionel Landwerlin
Eric Engestrom
Erik Faye-Lund