<MrCooper>
K900: what specifically is the issue with apps linked against old libgbm running on a system with a newer driver?
<K900>
Mesa generally expects the GBM backend to match the drivers
<K900>
And when that's not the case, things explode
<MrCooper>
there's a versioned ABI
<K900>
Between GBM and the backend, yes
<K900>
Between the Mesa drivers and the DRI backend specifically, no
<MrCooper>
why wouldn't the Mesa GBM backend match the rest of Mesa?
<K900>
Because until recently the GBM backend was hard-compiled into libgbm
u-amarsh04 has quit []
<K900>
Which is exactly the thing I'm trying to untangle here
<MrCooper>
I'm afraid I'm having trouble seeing the real-world scenario
kts has quit [Ping timeout: 480 seconds]
<K900>
The easiest non-NixOS-shaped scenario is you want to run an app with a local build of Mesa
<K900>
And you can just configure your glvnd/vulkan-loader to pick up your local Mesa, but not GBM
<MrCooper>
that picks up libgbm from the local build?
<K900>
It won't normally
<K900>
Unless you LD_PRELOAD it or something
<K900>
Or mess with LD_LIBRARY_PATH
<K900>
* "LD_LIBRARY_PATH"
<MrCooper>
sounds like a bug somewhere
<K900>
How would it pick up the local libgbm?
<MrCooper>
doesn't it work with "meson devenv"?
<K900>
Now it does because it's been partially untangled
<MrCooper>
same way as the other Mesa binaries
<K900>
Before that it didn't
<MrCooper>
not sure why it wouldn't, if it picked up libgbm from the local build
<K900>
It didn't
<K900>
It just happened to mostly work without that
<K900>
Usually
amarsh04 has joined #dri-devel
<MrCooper>
not picking up libgbm from the local build is a bug as far as I'm concerned
fab has joined #dri-devel
<K900>
The real use case I care more about is NixOS, which builds applications with (gross simplification) hardcoded, read-only, content-addressed paths, so an application is not linked against /usr/lib/libgbm.so, but /nix/store/<long hash>/libgbm.so, and those paths never change
<K900>
So running such an application on a system with newer drivers generally leads to explosions
<K900>
(the drivers are intentionally not hardcoded, because that causes issues for people with newer hardware, etc)
kts has joined #dri-devel
DemiMarie is now known as Guest12805
Guest12662 is now known as DemiMarie
<etehtsea>
Hi! Is some noticeable lag might happen between sending a patch to the mailing list and it's appearance in the archive? I can swear I checked multiple times before sending a RESEND copy and there were none but now I see all three of my emails (incl resend)
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #dri-devel
<tzimmermann>
thanks airlied
vliaskov has joined #dri-devel
sima has joined #dri-devel
warpme has joined #dri-devel
azerov has quit [Quit: Gateway shutdown]
azerov has joined #dri-devel
MrCooper_ has joined #dri-devel
MrCooper has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
bbhtt has quit [Quit: Bye!]
jsa1 has quit [Ping timeout: 480 seconds]
phasta has joined #dri-devel
lynxeye has joined #dri-devel
jsa1 has joined #dri-devel
itoral has quit [Remote host closed the connection]
bbhtt has joined #dri-devel
kxkamil2 has quit []
MrCooper_ is now known as MrCooper
knurd_ has quit [Quit: CU]
knurd_ has joined #dri-devel
<MrCooper>
K900: it doesn't allow running against newer versions of shared libraries?
<K900>
Not without rebuilding the application against them
<MrCooper>
that defeats one of the main purposes of shared libraries
<K900>
Yet it also provides a lot of interesting benefits
guru_ has joined #dri-devel
oneforall2 has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
samuelig has joined #dri-devel
pcercuei has joined #dri-devel
ybogdano has quit [Remote host closed the connection]
ybogdano has joined #dri-devel
MrCooper_ has joined #dri-devel
kxkamil has joined #dri-devel
MrCooper has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #dri-devel
kttns0ut[m] has joined #dri-devel
<MoeIcenowy>
K900: then why not consider libgbm.so as part of the driver?
<K900>
Because applications link to it directly?
warpme has quit []
<MoeIcenowy>
well in this case I think gbm should be built as a loader and backends
<MoeIcenowy>
the libgbm source code in Mesa is organized in such way
<MoeIcenowy>
but I am not sure whether it's possible to build them to 2 .so's instead of 1
MrCooper_ is now known as MrCooper
<K900>
Yes that's exactly what's happening
<K900>
Or rather that's exactly what my first change was about
glennk has quit [Remote host closed the connection]
<K900>
This change is about making the loader standalone, so it can exist outside of Mesa
<MrCooper>
libgbm should be in its own package, which can be pinned to the version the app was built against, and the backend can be shipped in a separate package which doesn't need to be the same version
<K900>
Or at least paving the way for that
<K900>
MrCooper: This is exactly what I'm working towards
<MrCooper>
it's not really necessary for that though
<MrCooper>
it's just a downstream packaging exercise
<MoeIcenowy>
well I think the backend needs to be locked to other parts of the driver
<MoeIcenowy>
and in fact at least we should allow backends to be built w/o loader
<K900>
MrCooper: Yes but no
<MoeIcenowy>
to allow some temporary replacement of mesa
<MrCooper>
definitely yes
<MrCooper>
otherwise it's a NixOS issue
<K900>
The problem is that Mesa itself also links libgbm
<K900>
And right now it links _its own_ libgbm
<K900>
Always
<K900>
So if you have a driver installed system-wide that's built against a different libgbm, you open yourself up to all kinds of funny symbol conflict nonsense
<K900>
By moving the loader out of Mesa, we can just build Mesa against whatever loader the user has on their system
<MrCooper>
then you still can't mix apps & Mesa built against different versions of the loader though, can you?
<K900>
Yes, but that's generally the case for any system library
<MrCooper>
can't Mesa be fixed not to link libEGL_mesa.so.0.0.0 to libgbm, e.g. use dlopen instead?
<K900>
(see: the webkitgtk/soup debacle, etc)
<K900>
MrCooper: Possibly?
<K900>
But I don't think that's practical to do for everything
<K900>
Like, I'd rather just treat libgbm like libglvnd
<K900>
As something that comes from the base system
kts has quit [Ping timeout: 480 seconds]
linkmauve has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
vliaskov has quit [Read error: No route to host]
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
vliaskov has joined #dri-devel
<MoeIcenowy>
MrCooper: the problem isn't that it uses interface in libgbm
<MoeIcenowy>
the problem is that the gbm dri backend calling into gallium directly
<MoeIcenowy>
and gallium has no stable interface
feaneron has joined #dri-devel
amarsh04 has quit []
amarsh04 has joined #dri-devel
glennk has joined #dri-devel
Caterpillar has quit [Quit: Konversation terminated!]
Caterpillar has joined #dri-devel
MrCooper_ has joined #dri-devel
MrCooper has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #dri-devel
itoral has quit [Remote host closed the connection]
feaneron has quit [Remote host closed the connection]
guludo has joined #dri-devel
ella-0 has quit [Remote host closed the connection]
rosefromthedead has quit [Remote host closed the connection]
mainiomano has quit [Remote host closed the connection]
nucfreq has quit [Remote host closed the connection]
atiltedtree has quit [Remote host closed the connection]
cmarcelo has quit [Remote host closed the connection]
kuruczgy has quit [Remote host closed the connection]
hummer12007 has quit [Remote host closed the connection]
rpigott has quit [Remote host closed the connection]
pitust has quit [Remote host closed the connection]
alethkit has quit [Remote host closed the connection]
kennylevinsen has quit [Remote host closed the connection]
ifreund has quit [Remote host closed the connection]
lph has quit [Remote host closed the connection]
pitust has joined #dri-devel
MrCooper_ is now known as MrCooper
<MrCooper>
MoeIcenowy: that's not relevant, those things are shipped together
kennylevinsen has joined #dri-devel
cmarcelo has joined #dri-devel
nerdopolis has joined #dri-devel
yshui has quit [Ping timeout: 480 seconds]
kuruczgy has joined #dri-devel
yshui has joined #dri-devel
atiltedtree has joined #dri-devel
ella-0 has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
yrlf has quit [Ping timeout: 480 seconds]
ifreund has joined #dri-devel
yrlf has joined #dri-devel
rpigott has joined #dri-devel
mainiomano has joined #dri-devel
jsa1 has joined #dri-devel
nucfreq has joined #dri-devel
hummer12007 has joined #dri-devel
alethkit has joined #dri-devel
rosefromthedead has joined #dri-devel
lph has joined #dri-devel
apinheiro has quit [Quit: Leaving]
MrCooper_ has joined #dri-devel
MrCooper has quit [Ping timeout: 480 seconds]
jsa1 has quit [Ping timeout: 480 seconds]
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #dri-devel
llyyr has quit [Quit: Quit]
llyyr has joined #dri-devel
Nefsen402_ has joined #dri-devel
emersion_ has joined #dri-devel
vliaskov_ has joined #dri-devel
Sid127- has joined #dri-devel
MrCooper__ has joined #dri-devel
KAL9000 has joined #dri-devel
loki_val has joined #dri-devel
kzd has joined #dri-devel
pH5_ has joined #dri-devel
emersion has quit [Read error: Connection reset by peer]
crabbedhaloablut has quit [Remote host closed the connection]
leandrohrb has joined #dri-devel
shoragan has quit [Remote host closed the connection]
dbrouwer has quit [Quit: Ping timeout (120 seconds)]
leandrohrb has quit [Quit: Ping timeout (120 seconds)]
tintou has quit [Quit: Ping timeout (120 seconds)]
sre has quit [Quit: Ping timeout (120 seconds)]
ndufresne has quit [Quit: Ping timeout (120 seconds)]
ao2_collabora has quit [Quit: Ping timeout (120 seconds)]