ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
dllud has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
f11f11 has quit [Remote host closed the connection]
f11f11 has joined #dri-devel
fcarrijo has joined #dri-devel
camus has joined #dri-devel
fcarrijo has quit []
agx has quit [Read error: Connection reset by peer]
agx has joined #dri-devel
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
JohnnyonFlame has quit []
dllud_ has joined #dri-devel
dllud has quit [Remote host closed the connection]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
camus has quit [Ping timeout: 480 seconds]
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
boistordu_ex has joined #dri-devel
boistordu has quit [Ping timeout: 480 seconds]
soreau has quit [Read error: Connection reset by peer]
soreau has joined #dri-devel
pendingchaos_ has joined #dri-devel
pendingchaos has quit [Ping timeout: 480 seconds]
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
linearcannon has quit [Read error: No route to host]
linearcannon has joined #dri-devel
The_Company has quit []
camus has joined #dri-devel
camus has quit []
mclasen has quit [Ping timeout: 480 seconds]
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
gpuman_ has joined #dri-devel
gpuman has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Danct12 has quit [Quit: Quitting]
Danct12 has joined #dri-devel
gouchi has joined #dri-devel
kts has joined #dri-devel
gpuman has joined #dri-devel
gpuman_ has quit [Ping timeout: 480 seconds]
gpuman_ has joined #dri-devel
gpuman has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
gpuman has joined #dri-devel
gpuman_ has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
camus has joined #dri-devel
gpuman has quit [Remote host closed the connection]
gpuman has joined #dri-devel
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
gpuman_ has joined #dri-devel
gpuman has quit [Ping timeout: 480 seconds]
flacks has quit [Quit: Quitter]
gawin has joined #dri-devel
flacks has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
camus has joined #dri-devel
tarceri has quit [Read error: Connection reset by peer]
tarceri has joined #dri-devel
gpuman_ has quit [Ping timeout: 480 seconds]
gpuman has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
gpuman_ has joined #dri-devel
gpuman has quit [Ping timeout: 480 seconds]
pcercuei_ has joined #dri-devel
pcercuei has quit [Ping timeout: 480 seconds]
<doras>
So I made the necessary changes and I have an external DRI GBM backend which seemingly works. I'm not sure how to fully test it, however.
pekkari has joined #dri-devel
tobiasjakobi has joined #dri-devel
camus has joined #dri-devel
<emersion>
doras: what's the motivation for this?
guru_ has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
<doras>
emersion: trying to figure out the best way forward for loadable GBM in Flatpak runtimes. Now that libgbm gained support for loading external backends from other vendors, it suddenly looks very similar to the other driver loaders out there (libvulkan, libOpenCL, libOpenGL from glvnd, libva, etc.) In Flatpak we traditionally put loaders in the "main" runtime (which is ABI-frozen) and put backends as runtime extensions (which get updated to every
<doras>
stable released).
<emersion>
sigh, flatpak
<emersion>
this will add the complexity of making the backend have to deal with a frontend version mismatch
<emersion>
which is not handled right now
oneforall2 has quit [Ping timeout: 480 seconds]
<doras>
Right now we need to add support loading nvidia's backend in some way, and there are two approaches: one is to do the usual thing with loaders that I described above, and the other is do something which we don't usually (ever?) do and it's to keep libgbm as part of Mesa runtime extension and then require it to be present when the nvidia extension is also used.
tarceri has quit [Read error: Connection reset by peer]
tarceri has joined #dri-devel
<emersion>
the other way is to not try to vendor parts of mesa…
<doras>
emersion: I noticed the matter of frontend mismatch, and I'm not yet sure what's the most sensible approach here. We could consider libgbm's backend ABI as part of the frozen runtime ABI (which it will be), and then the Mesa runtime extension could be updated for as long as it doesn't depend on an ABI version bump. This will mean we could end up being unable to update Mesa at some point of the runtime release lifetime. nvidia will probably
<doras>
support every ABI version going forward, unlike Mesa.
tarceri has quit [Read error: Connection reset by peer]
tarceri has joined #dri-devel
<doras>
emersion: the "vendoring" was already done by allowing external GBM backends, providing ABI guarantees, etc.
<doras>
This is the fallout :)
<emersion>
not really
<emersion>
by "vendoring" i mean "bundling"
<emersion>
good thing flatpak uses namespaces, otherwise we'd see applications bundle kernels as well
mclasen has joined #dri-devel
pendingchaos_ is now known as pendingchaos
kts has joined #dri-devel
camus has quit []
tobiasjakobi has quit [Remote host closed the connection]
gpuman has joined #dri-devel
gpuman_ has quit [Ping timeout: 480 seconds]
tarceri has quit [Read error: No route to host]
tarceri has joined #dri-devel
aravind has joined #dri-devel
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
Lucretia has quit []
Lucretia has joined #dri-devel
Lucretia has quit [Remote host closed the connection]
Lucretia has joined #dri-devel
pekkari has quit [Quit: Konversation terminated!]
mclasen has quit []
mclasen has joined #dri-devel
guru_ has quit []
oneforall2 has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
<MrCooper>
doras: could the nvidia runtime extension shipping libgbm.so.1 as well be a solution?
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
ppascher has joined #dri-devel
gawin has joined #dri-devel
<doras>
MrCooper: not necessarily. It may even complicate things a little in switchable graphics scenarios where you want both backends DRI and nvidia backends available.
<doras>
both the DRI and nvidia backends available*
<doras>
I'm trying to think about the relevant ABIs here. We have the libgbm ABI which is made available to applications. This hasn't changed.
<doras>
Then we have the GBM backend ABI which is the set of functions expected to be implemented by each backend. This is a new thing.
<doras>
Lastly, we have the core GBM ABI which is injected to each loaded backend as a set of functions made available to it.
<doras>
The third one is also a new thing.
fxkamd has joined #dri-devel
<doras>
I'm going to ignore the libgbm ABI since it's outside the scope of this change. This leaves us with backend and core ABIs.
<doras>
So Mesa now loads external GBM backends outside its control, which means that these backends can expect any ABI from the GBM core, and Mesa must be able to provide it. Please anyone correct me if my understanding is wrong.
<bnieuwenhuizen>
being able to do so doesn't mean that ABI is stable
rsripada_ has joined #dri-devel
unerlige1 has joined #dri-devel
stuartsummers2 has joined #dri-devel
mdnavare_ has joined #dri-devel
Ryback_[WORK] has joined #dri-devel
dolphin` has joined #dri-devel
dolphin is now known as Guest4533
dolphin` is now known as dolphin
<doras>
What do you mean, bnieuwenhuizen ?
<bnieuwenhuizen>
that there is a way to use it in a different component doesn't mean anyone promises forward or backward compatibility
stuartsummers has quit [Ping timeout: 480 seconds]
rsripada has quit [Ping timeout: 480 seconds]
Guest4533 has quit [Ping timeout: 480 seconds]
Ryback_ has quit [Ping timeout: 480 seconds]
mdnavare has quit [Ping timeout: 480 seconds]
<bnieuwenhuizen>
okay
gawin has quit [Quit: Konversation terminated!]
<doras>
The other option is to intentionally misbehave in some way in such a case (crash or otherwise), but I don't see the reason for strict ABI versioning to be introduced if this was the intention.
gouchi has quit [Remote host closed the connection]
gouchi has joined #dri-devel
<doras>
So I'll assume for a moment that the intention was for the GBM core to provide backward ABI compatibility.
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
<bnieuwenhuizen>
doras: the other option is to have version specific compilation like you e.g. see with Linux kernel drivers that are not shipped with the kernel
<bnieuwenhuizen>
though given the header that sounds like not the thing that is needed here
<doras>
Yes, the header makes it sound like a runtime thing.
<doras>
"It is the loader's responsibility to respect this version when directly accessing a device instance or any child objects instantiated by a device instance"
gouchi has quit [Remote host closed the connection]
sdutt has joined #dri-devel
<doras>
Anyway, this leaves us with the backend ABI. This one means external backends should be able to provide backwards compatibility to any libgbm which expects the older ABI. The DRI backend being built into libgbm means that it doesn't have to provide backwards compatibility in this case.
<doras>
So making the DRI backend external means we need to provide backwards compatibility for this backend as well. The question is how difficult that would be.
<emersion>
that would be complicated for no benefit
sdutt has quit [Read error: Connection reset by peer]
gouchi has joined #dri-devel
gouchi has quit [Quit: Quitte]
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
X-Scale has joined #dri-devel
X-Scale` has quit [Ping timeout: 480 seconds]
Erandir has quit [Read error: Connection reset by peer]
Erandir has joined #dri-devel
fxkamd has quit []
gawin has joined #dri-devel
zackr has quit [Remote host closed the connection]
alyssa has joined #dri-devel
<alyssa>
Hmm... is parsing dmesg output in a Gallium driver a hack? :-p
<alyssa>
radeonsi does it so it's fine right?! :-p
<imirkin>
definitely not a tight coupling...
<imirkin>
and as kernel messages change, you end up breaking userspace. fun!
<alyssa>
=D
<imirkin>
a drm driver can emit events
<imirkin>
(e.g. hpd, vblank, etc)
<alyssa>
nod
<alyssa>
it looks adding an ioctl for this is the norm
<imirkin>
but those events could also be "hang detected" etc
<alyssa>
nod
<imirkin>
i think karolherbst has been prototyping something like that for nouveau
<alyssa>
the scariest thing about this code is that oit's passing 100% of the tests
<alyssa>
(It's never going to be merged but wanted to see how far I could get bullshitting it. Apparently, all the way.)
<gawin>
gl 2.0 requiring derivatives is huge pain, someone knows some papers about doing huge approximations of them?
<alyssa>
You can't
<robclark>
alyssa: also, I don't think you can rely on dmesg being accessible to users
<alyssa>
GL's derivatives are screen space (i.e. exchanging data with neighbouring pixels)
<alyssa>
robclark: Yet another reason not to merge this excellent code ;-P
<karolherbst>
alyssa: I think the normal approach is to either add an ioctl on the "context" or provide a sysfs/debugfs file containing the last stuff
<karolherbst>
imirkin: yeah.. although I just parse the pushbuffers we dump through libdrm
<karolherbst>
yeah.. and also syslog level and what not
<imirkin>
gawin: i think derivatives are optional in ES 2.0
<karolherbst>
can one even emulate derivatives?
<alyssa>
karolherbst: no
<imirkin>
karolherbst: i mean ... llvmpipe can do it, so anyone can? :)
<karolherbst>
imirkin: yeah... that's roughly my thinking here :D
<alyssa>
llvmpipe controls its dispatch
<karolherbst>
alyssa: well....
<imirkin>
alyssa: when there's a will there's a way
<robclark>
I guess the question is about context-lost? For drm/msm we have a param that can be queried via GET_PARAM/SUBMITQUEUE_QUERY ioctl
<imirkin>
however that way is going to *suck* bigtime
<alyssa>
robclark: Yeah. Looks simple to extend the panfrost kernel do this
<alyssa>
though doing kernel dev for this board is.. annoying
<karolherbst>
imirkin: question is rather if all GL 2.0 apps rely on that or if it's just to get kwin to work :p
<karolherbst>
you could also just... not pass the tests...
<imirkin>
karolherbst: i sorta assume kwin would support ES 2.0 too? no?
<imirkin>
that's why i mentioned ES2
<karolherbst>
no idea actually
<karolherbst>
but I know you can choose between 2.1 and 3.0 or 2.0 and 3.1
<imirkin>
both require NPOT textures though. but the ES2 variant of NPOT textures is emulatable with POT
<gawin>
I'm hitting derivatives with kwin and gl 2.0 compositor :(
<karolherbst>
figures
<karolherbst>
what kind of hw do you have there anyway? :D
<imirkin>
gawin: try just saying the derivative is 0, and move on? who knows, could work.
tarceri has quit [Read error: Connection reset by peer]
tarceri has joined #dri-devel
<gawin>
karolherbst: all r300 and r400 cards, I wonder how amd allowed to gl2.0 happen in this shape
<imirkin>
it was very common for drivers of the day to have tons of emulation for missing hw features
<imirkin>
and games knew what was "really" supported and what was not
<imirkin>
so as not to fall off the performance path
<imirkin>
modern software doesn't give a shit about any of that
<imirkin>
if it's in the spec, they assume they can use it
<imirkin>
and that it will work well
<alyssa>
haha geometry/tess on mali
<karolherbst>
gawin: emulating this stuff? or maybe there is a way
<imirkin>
alyssa: well, those are major features. i'm talking about "only mix this depth format with this color format, because other combos won't work well" level stuff
<imirkin>
(or in nouveau's case, instead of emulating, we just skip the draw...)
<karolherbst>
I'd check what AMD did back then in their dirver, if that's even possible :D
<imirkin>
PROBLEM SOLVED =]
<gawin>
am I right that nvidia also had this type of limitations, but on cards from d3d8 era? like 4 indirections
<imirkin>
gawin: i know next to nothing about the nv2x shaders. you can read about them in NV_texture_shader
<imirkin>
you can assume that ext is pretty 1:1 with the hardware
<imirkin>
according to the ext:
<imirkin>
The roughly equivalent functionality to DirectX 8's pixel
<imirkin>
shaders in OpenGL is the combination of NV_texture_shader with
<imirkin>
NV_register_combiners.
<imirkin>
huh, that's where the HILO terminology comes from. i never actually read this ext in any detail :)
<airlied>
"The R300 and R400 asics also lack support for derivative operations. This
<airlied>
means that dFdx, dFdy, and fwidth will cause the shader to run in software"
<karolherbst>
airlied: oh wow
<imirkin>
gawin: fwiw you can look at the nv30 driver for how to fall back on draw for some stuff. it's not quite what you want since it's for handling the vertex part, not the fragment part.
<imirkin>
(perhaps r300 already has those fallbacks too? dunno)
<karolherbst>
guess llvmpipe can be used for that then :P I mean.. we do have some sw fallback paths in gallium, don't we?
<imirkin>
karolherbst: never for rast
<karolherbst>
ahh
<imirkin>
the draw path is used in st/mesa for select/feedback
<airlied>
falling back rast is just why bother, give them a black screen instead of a slideshow :-P
<karolherbst>
I guess that stuff could be added :p
<karolherbst>
airlied: well.. it's for supporting kwin I guess...
<gawin>
now it's just dropping empty/dummy shader if there's ddx/ddy
<imirkin>
and in e.g. nv30 for a handful of situations that the hw vertex shader can't handle
<karolherbst>
gawin: does it work good enough with kwin?
<karolherbst>
I guess it doens't
<airlied>
if you want kwin, fix kwin
<karolherbst>
I am actually curious why kwin even needs that
<airlied>
making a sw rast path isn't going to make kwin suddenly useable
<imirkin>
gawin: that's a bit much imho. i'd just make the derivatives 0 and see what happens
<alyssa>
airlied: llvmpipe is quick speedy on my m1 ;_p
<karolherbst>
probably for the wobbly extension or whatever
<imirkin>
alyssa: generally r300 boards are paired with r300-era CPUs
<karolherbst>
alyssa: faster then i965 I guess :p
<karolherbst>
*than
pushqrdx has joined #dri-devel
<alyssa>
imirkin: alas :-p
<alyssa>
karolherbst: idk, definitely faster than panfrost :V
<karolherbst>
guess you need the m1 max to outperform iris
<karolherbst>
with llvmpipe
<gawin>
karolherbst: except that sometimes boxes are black and it's sometimes slow, it's usable
<karolherbst>
mhh
<karolherbst>
that boxes are black sounds like a bug inside kwin though
<imirkin>
or r300 using a dummy shader when dfdx is detected :)
<karolherbst>
well.. I used kwin for a long time, I saw those issues with various drivers :D
<karolherbst>
there is always something wrong
<karolherbst>
either black boxes where the window buttons are or...
<karolherbst>
other random stuff
<karolherbst>
gawin: check with kwin_ft :D
<gawin>
imirkin: I'm using it with athlon 5350 :P slow, but 100% passive
craftyguy has quit [Ping timeout: 480 seconds]
<imirkin>
gawin: those were already 64-bit right?
<gawin>
even has avx
<imirkin>
wow
<milek7>
it doesn't have sensible integrated gpu?
<imirkin>
allegedly should have a Radeon HD 8400 in it, which is quite a bit nicer than r300 :)
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
<gawin>
it does, but it's my best platform in terms of compatibility. for example my ivy bridge board (which I usually use for xp stuff) doesn't detect r400 and r500 at all. with r300 it's crashing
alyssa has quit [Quit: leaving]
gouchi has joined #dri-devel
<imirkin>
gawin: you may have to disable onboard in order to get a separate one working (or otherwise mess with bios options)
craftyguy has joined #dri-devel
flibitijibibo has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.2]
gawin has quit [Ping timeout: 480 seconds]
flibitijibibo has joined #dri-devel
sravn has quit [Quit: WeeChat 3.0.1]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
<HdkR>
karolherbst: glxgears with llvmpipe is only 1549.569 FPS on M1Max :P
gouchi has quit [Remote host closed the connection]
Anorelsan has joined #dri-devel
nsneck has quit [Remote host closed the connection]
<bnieuwenhuizen>
HdkR: does that include making use of the large GPU with a compute shader? :)
<HdkR>
Nope, I'm too lazy to write one of those :P
<HdkR>
Virgl got it to 5600fps though
gawin has joined #dri-devel
pushqrdx has quit [Remote host closed the connection]
Anorelsan has quit [Quit: Leaving]
<airlied>
jekstrand: seeing a logging crash in dEQP-VK.api.device_init.create_device_unsupported_features on lavapipe
<airlied>
looks like it's vk_errorf(instance, VK_ERROR_FEATURE_NOT_PRESENT) that blows up
<karolherbst>
HdkR: "only" :D
<HdkR>
:D
<karolherbst>
although iris does reach 10k here
<karolherbst>
but glxgears is a crappy benchmark :p
<airlied>
it's not a crappy benchmark, it's just not a benchmark :-P
<karolherbst>
true
<imirkin>
ot
<imirkin>
it's a benchmark, just not of garphics perf