xserver's loader will look for drivers this way, but there's no reason
we need to keep hurting ourselves like that.
Co-authored-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28378>
Move it into src/gallium/include/ to make it absolutely clear this is a Mesa detail.
While we're at it, clean up its include sites, including some places
where we can just include kopper_interface.h instead since it includes
mesa_interface.h as its first act.
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28378>
We're about to split the latter off as a compatibility detail for older
versions of Xorg, and the former includes the latter at this point, so
this should be just to prove no functional change.
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28378>
Since commit 7d9ea77b45 ("glx: add automatic zink fallback loading between hw
and sw drivers"), zink could be tried as a fallback. It'd better silence
if the zink loading is implicit and on fail as what commit 4cc975c6e9 ("glx: silence
more implicit-load zink errors") has done. But there seems to be one
left bebind, which is spit when building swrast but no zink with -Dglx=dri.
v2: plumb the flag through from egl/glx to the loader (zmike)
Signed-off-by: Luc Ma <luc@sietium.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28970>
Add helper function to check if a device is render-capable.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24825>
Since commit "pipe-loader: add
pipe_loader_get_compatible_render_capable_device_fd()", we have a
function to query a render-only driver that is available and is
compatible with the KMS-only device.
So start to use it, instead of selecting whatever render-only driver is
available to use.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24825>
In a later commit in this series, we'll need to open the first supported
render-only platform device that we can find.
In order to avoid calling loader_open_render_node_platform_device()
multiple times (what is quite expensive), change this function to take a
driver list (instead of a single driver name) as parameter.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24825>
This function ignore devices that are not on the platform bus. So rename
it to better reflect that.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24825>
Android-14/clang-17 throws an error with it:
ld.lld: error: version script assignment of 'global' to symbol
'__driDriverExtensions' failed: symbol not defined
Fixes: d43e6a9a49 ("dri: Remove the megadriver compat stub")
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25587>
DRI_PRIME=1 isn't useful on machines with more than 2 GPUs.
This commit adds support to DRI_PRIME=N syntax meaning: select
the Nth GPU (not counting the default GPU).
So on a 3 GPUs system where drmGetDevices2 returns the following:
/dev/dri/renderD130 [default]
/dev/dri/renderD129
/dev/dri/renderD128
DRI_PRIME=1 would select D129 (as is already the case without this
commit), DRI_PRIME=2 would select D128.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24750>
All DRI loaders in Mesa (EGL, GLX, gbm) now require this ext and that the
driver come from a matching build. This will let us use Mesa-internal
types and enums across the loader-driver bounary inside of Mesa.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Eric Engestrom <eric@igalia.com>
LOL-YESed-by: Kristian Høgsberg <krh@bitplanet.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20069>
It's better than EGL's copy of it by having optional ext support in the
match structs, and GLX wishes it had either of the two.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20069>
Add function loader_get_render_node() to help us to get a render node
from dev_t. If the device does not expose a render node, this new
function returns NULL.
As this function uses drmGetDeviceFromDevId(), we bump libdrm minimal
version to 2.4.109.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11248>
Cuts 1/3 of the runtime of the VA-API unit tests (which do a separate
pipe-loader init per test) on radeonsi on my system by not faffing around
in sysfs so much.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13324>
Add support for driconf overrides on a per-device level, for cases
where we don't want to override behavior for all devices supported
by a particular driver.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12135>
I factored out the chunk of loader code that dlopen()s
libraries from the rest of the DRI driver loader function
in this commit:
commit bc343154f8
Author: James Jones <jajones@nvidia.com>
Date: Thu Apr 22 23:17:08 2021 -0700
loader: Factor out driver library loading code
However, I failed to adjust the DRI loader function that
now uses the new helper function to handle the case where
the requested DRI library is not found.
This change restores the prior behavior, and also ensures
loader_open_driver() consistently returns NULL in the
out_driver_handle parameter on failure.
Fixes: bc343154f8 ("loader: Factor out driver library loading code")
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11807>
Separate the path-building and dlopen() portion of
loader_open_driver() from the DRI extension
loading logic. The former will be shared by the
GBM backend loading logic in a subsequent change.
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902>
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>
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>
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>
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>
