ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
mbrost_ has quit [Ping timeout: 481 seconds]
rasterman has quit [Quit: Gettin' stinky!]
anujp has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
<Company>
people just need to learn that there's 3 different names for each gpu: kernel driver, GL driver, Vulkan driver
<Company>
and those names are creatively chosen, not because they make sense
<Company>
but I can confirm from Gnome that people who aren't aware of this get very confused by those names
<airlied>
in some cases they made sense when they were chosen, but the meanings have shifted
<alyssa>
for us, kernel=gl=asahi, vk=honeykrisp which.. could be worse
<Company>
also, Gnome lost its creativity because we named everything gnome-thing
<feaneron>
you can't say that with a straight face
<Company>
which worked for a few years but now that we want to replace older apps with newer ones, we don't have names available anympre
* feaneron
named his app Boatswain, and all types start with Bs
<feaneron>
BsWindow, BsStreamDeck, it's all bs
<Company>
i'm still salty that it's called gnome-text-editor because typing that in a terminal takes way too long
<Company>
and autocomplete doesn't work either, because everything starts with "gnome-"
<zf>
KDE had the right idea :-)
<alyssa>
Company: rip gedit
<alyssa>
wait is gedit not gnome-text-edtior
mbrost has joined #dri-devel
mattst88_ has quit []
<feaneron>
it is not
mattst88 has joined #dri-devel
<mattst88>
nope, separate thing
<mattst88>
gnome-text-editor is the new thing
<alyssa>
joy
<Company>
maintainer issues caused a fork
<Company>
so gedit still exists
<Company>
bunch of projects had some reckoning when the gtk4 transition happened, both because gtk4 nudged very hard towards design changes, from menu + toolbar towards "touch" design
<Company>
and because backends that weren't reasonably clean and operating under an X model suddenly had to deal with a toolkit that didn't bent over backwards to make that work on Wayland
<Company>
so you can no longer do updates via XCopyArea()
<pac85>
I thought gnome-text-editor was done from scratch, it looks very different than gedit (at least how I remember it)
<Company>
not sure - but 90% of it is GtkSourceView and that remained a thing
<Company>
it's either gedit and deleting all the plugin stuff or redone from scratch around the GtkSourceView port to GTK4
<Company>
it's a case of "what do I do now that there's a lockdown?"
<alyssa>
i mean go back far enough and krita is a gimp fork right? ;P
The_Company has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
<DemiMarie>
alyssa: why is the userspace code not named Asahi too?
Company has joined #dri-devel
<DemiMarie>
Company: Yup, GTK4 very very much pushes one towards a certain design style, which makes porting some applications almost impossible. I have no idea how I would port Horizon EDA.
anholt has quit [Ping timeout: 480 seconds]
The_Company has quit [Ping timeout: 480 seconds]
NiGaR has quit [Remote host closed the connection]
anholt has joined #dri-devel
NiGaR has joined #dri-devel
epoch101 has joined #dri-devel
a1batross has joined #dri-devel
oneforall2 has joined #dri-devel
anholt has quit [Ping timeout: 480 seconds]
alane has quit []
alane has joined #dri-devel
NiGaR has quit [Remote host closed the connection]
NiGaR has joined #dri-devel
NiGaR has quit [Remote host closed the connection]
NiGaR has joined #dri-devel
<Company>
DemiMarie: there's 2 answers to that. One of them is to find some modern UI designers to take on that topic, and change the parts that don't fit well anymore
<DemiMarie>
Company: fit well with *what*?
<Company>
DemiMarie: and the other option is to do an alternative/companion to libadwaita that focuses on that older style of application design
<DemiMarie>
Is the existing UI objectively bad in some way, even for applications that do not need touch support?
<Company>
none of that design is about touch support, that's just how people call it
<DemiMarie>
Is there scientific evidence that the newer design is objectively (as opposed to subjectively) superior?
<Company>
I have no idea
<Company>
though I'd be interested how anyone would quantify "better" for design
<DemiMarie>
“How long does X take?” studies would be the most obvious one I can think of, but there are people (not me) who actually do work on this stuff.
<Company>
but people like developing apps this way, so that's what's happening
<DemiMarie>
Is GTK no longer intended to be used without libadwaita or another platform library?
<Company>
I always compare it to the web for the answer
<Company>
can you make a webpage without some framework? Sure. Should you? Probably not.
<Company>
GTK is trying to push the widgets that imply some sort of UI design out of the platform
<Company>
and focus on the core building blocks
<Company>
but that leaves you without the base widgets that make up the UI - sidebars, headerbars, toolbars, statusbars, etc (why are those all bars?)
<Company>
and you also have no design language, ie no consistent spacing, no good color/contrast choices, all the themeing stuff is missing
<Company>
and that's basically what a framework/platform lib gives you
<Company>
if someone made a library with a toolbar widget, a menu and some MDI docking widget, so that you could implement Gimp's and Inkscape's UI with it, then you could port those and the whole Cinnamon/Mate apps to it and you could probably find a bunch more
<Company>
gedit!
<Company>
but you need to find someone who wants to create that library, and there's been a distinct lack of interest for years
libv has quit [Ping timeout: 480 seconds]
<DemiMarie>
At least some are just leaving GTK instead.
<Company>
that's also an option - depends on how much UI you have and how well other stuff fits
NiGaR has quit [Remote host closed the connection]
NiGaR has joined #dri-devel
NiGaR has quit [Remote host closed the connection]
<Company>
all I know is that the Gnome community is not gonna make it happen
mbrost_ has joined #dri-devel
NiGaR has joined #dri-devel
NiGaR has quit [Remote host closed the connection]
NiGaR has joined #dri-devel
NiGaR has quit [Remote host closed the connection]
NiGaR has joined #dri-devel
The_Company has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
anujp has quit [Ping timeout: 480 seconds]
libv has joined #dri-devel
feaneron has quit [Ping timeout: 480 seconds]
Company has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
<Lynne>
is there some database of the throughput of GPUs in terms of 32/16/8-bit (non-matrix) integer ops?
amarsh04 has quit []
NiGaR has quit [Remote host closed the connection]
NiGaR has joined #dri-devel
NiGaR has quit [Remote host closed the connection]
NiGaR has joined #dri-devel
NiGaR has quit [Remote host closed the connection]
NiGaR has joined #dri-devel
NiGaR has quit [Remote host closed the connection]
NiGaR has joined #dri-devel
NiGaR has quit [Remote host closed the connection]
NiGaR has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
amarsh04 has joined #dri-devel
amarsh04 has quit []
u-amarsh04 has joined #dri-devel
glennk has joined #dri-devel
epoch101 has quit []
epoch101 has joined #dri-devel
u-amarsh04 has quit []
amarsh04 has joined #dri-devel
amarsh04 has quit []
amarsh04 has joined #dri-devel
The_Company has quit []
Company has joined #dri-devel
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
anholt has joined #dri-devel
mbrost has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
Dalphon has quit [Ping timeout: 480 seconds]
epoch101 has quit []
fab has joined #dri-devel
fab is now known as Guest246
aradhya7 has joined #dri-devel
verylowendsteve has joined #dri-devel
verylowendsteve has quit [Remote host closed the connection]
kzd has quit [Ping timeout: 480 seconds]
Dalphon has joined #dri-devel
justalowendguy has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bolson has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
JLP_ has joined #dri-devel
<justalowendguy>
Did you miss me?
JLP has quit [Ping timeout: 480 seconds]
Fijxu has quit [Quit: XD!!]
<justalowendguy>
I replaced battery finally on one of the macbooks.
<justalowendguy>
it had overscrewed screws, but with brand new battery it works rediculously well. And can finally work now, did set up some more equipment to my office.
Fijxu has joined #dri-devel
kts has joined #dri-devel
blaztinn_ has quit [Remote host closed the connection]
<justalowendguy>
But i do the combinations tasks on phone a lot too, It really seems my theory is functional.
Dalphon has quit [Ping timeout: 480 seconds]
blaztinn has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
justalowendguy has quit [Ping timeout: 480 seconds]
Fijxu has quit [Ping timeout: 480 seconds]
Fijxu has joined #dri-devel
jsa1 has joined #dri-devel
dolphin has joined #dri-devel
kts has joined #dri-devel
justalowendguy has joined #dri-devel
Guest246 has quit [Ping timeout: 480 seconds]
sima has joined #dri-devel
Fijxu has quit [Quit: XD!!]
Fijxu has joined #dri-devel
JLP_ has left #dri-devel [#dri-devel]
JLP has joined #dri-devel
Fijxu has quit [Ping timeout: 480 seconds]
Fijxu has joined #dri-devel
fab has joined #dri-devel
fab is now known as Guest256
Fijxu has quit [Quit: XD!!]
Fijxu has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
warpme has joined #dri-devel
digetx has quit [Quit: No Ping reply in 180 seconds.]
bmodem has joined #dri-devel
digetx has joined #dri-devel
aradhya7 has quit [Quit: Connection closed for inactivity]
Guest256 has quit []
Fijxu has quit [Ping timeout: 480 seconds]
digetx has quit [Ping timeout: 480 seconds]
digetx has joined #dri-devel
Perseverance has joined #dri-devel
Perseverance has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
Fijxu has joined #dri-devel
tzimmermann has joined #dri-devel
xroumegue has quit [Ping timeout: 480 seconds]
phasta has joined #dri-devel
<MrCooper>
RAOF: my recommendation is to just signal the release point when the atomic commit completion event arrives, not materialize any fence before
<MrCooper>
zamundaaa[m]: even a client which prefers signalled release points might reasonably say "the release point has a fence, I can re-use this buffer, don't need to allocate another one"
Perseverance has joined #dri-devel
bnieuwenhuizen has quit [Quit: Bye]
bnieuwenhuizen has joined #dri-devel
Fijxu has quit [Ping timeout: 480 seconds]
Fijxu has joined #dri-devel
lynxeye has joined #dri-devel
<emersion>
sounds like a broken client
<MrCooper>
why? That's how I'd implement it for dynamic number of buffers
rgallaispou has joined #dri-devel
<MrCooper>
if there being a fence doesn't imply the buffer can be re-used, what does?
Fijxu has quit [Quit: XD!!]
LeviYun has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
warpme has quit []
Fijxu has joined #dri-devel
justalowendguy has quit [Remote host closed the connection]
sensationfrom has joined #dri-devel
sensationfrom has quit [Remote host closed the connection]
JLP has quit [Ping timeout: 480 seconds]
JLP has joined #dri-devel
franchiseeofhell has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
<emersion>
MrCooper: it's easy to wait for the timeline point to be signalled
<emersion>
as opposed to materialized
<MrCooper>
right, then there's no point materializing the release point from OUT_FENCE_PTR though?
<MrCooper>
materializing the relase point with a compositor GPU work fence and the client re-using that buffer does make sense though
<emersion>
MrCooper: hm, what's the difference between GPU work fence and KMS fence work? why does it make sense to use one but not the other?
<emersion>
i suppose because one will happen "sooner" than the other?
<MrCooper>
GPU fence is guaranteed to signal ASAP, OUT_FENCE_PTR might miss a display refresh cycle
<MrCooper>
and can't signal before the next cycle in the first place
<emersion>
right
* lynxeye
seems to be equally confused as emersion and RAOF
<emersion>
i agree
<emersion>
now i'm kinda wondering why OUT_FENCE_PTR exists in the first place
<lynxeye>
What's the point of the out fence if you can use it to wait for the GPU (scanout) to be done with the buffer?
<MrCooper>
emersion: as a trap? ;)
<emersion>
:D
<emersion>
it would be useful for writeback, maybe
<MrCooper>
it could be used instead of completion events in some cases
<MrCooper>
e.g. when turning off a CRTC?
LeviYun has joined #dri-devel
<lynxeye>
Wasn't the point of the fence that you could use it to pass back to whoever is waiting for the buffer to be free again instead of waiting for the atomic commit completion event and signaling that back to waiters?
<franchiseeofhell>
I only contriubuted this hack in words salad format. I,e you do not show this code online indeed, and YES i understand , it's perfectly fine, however i do not have a proper convoy or asylym given where i can safely work with that code, though i personally think, that Jews , Americans and Russians already have that code in the world of military and i gave them nothing, they have it
<franchiseeofhell>
mixed with self-timing. The code itself is very easy. I think China has it too, but other europe ones i do not know , they have all sorts of things there. I need that code to defend my life and save it. So give me some security jamming signal the least or asylym to work it out, it's very simple couple months work. And one more request i have, could someone look at the dma engines and
<franchiseeofhell>
clean them up better than atm? I see that karolherbst knows howto code well, and there is no such problem, i can see that 2011 intel laptop works also seriously good, any troubles i no longer do not have. If you say i might leak something , i seriously try not to, but i suspect i am under a huge number of taps. I need reliable signal and area to work at, every one knows where i stay,
<franchiseeofhell>
then i suppose just arrange it. Please can some look and bring in sane dma engines API bits also, cheers.
<MrCooper>
lynxeye: if it was, it was ill-conceived
jkrzyszt_ has joined #dri-devel
mripard has quit [Quit: WeeChat 4.4.2]
<sima>
MrCooper, emersion lynxeye so for some tiling gpus it actually makes sense to start rendering while the flip is scheduled but hasn't happened yet
franchiseeofhell has quit [Remote host closed the connection]
<sima>
when you're extremely limited on memory you can kinda get 3 buffers but only allocate 2 by max pipelining everything
<sima>
and with tilers you can do the tiling preprocessing while the buffer isn't needed yet
<sima>
android apparently does that for some platforms, which is why that out fence exists
<sima>
there's also an entire can of worms on the kernel side around that out fence breaking the kernel-internal rules to avoid dma_fence deadlocks
<lynxeye>
MrCooper: agreed. I mean the point of in and out fence FDs was to allow explicit fencing. But the out fence is useless for that, as scanout is potentially still using the FB after the out fence has signaled if no flip away from this FB is scheduled
<sima>
and I haven't found out a good way to fix it yet
<sima>
so, it's a bit a mess
<sima>
lynxeye, that sounds like compositor bug to me
warpme has joined #dri-devel
<lynxeye>
sima: Huh? Unless your tile buffer covers the whole FB (which I guess is pretty unlikely) you can't start rendering even on a tiler until the buffer isn't scheduled for scanout anymore.
<sima>
lynxeye, yeah hence the fence, because that allows you to queue up the entire batch to the gpu already and the gpu to start with vertex shader and putting the vertices into the right buckets
Fijxu has quit [Ping timeout: 480 seconds]
<sima>
hwcomposer v1 went even further and made that out fence a full future fence iirc
<sima>
and just assuming that both surface flinger and the app would get around to scheduling the flip
<lynxeye>
sima: Okay, so OUT_FENCE_PTR is really just a footgun for everyone not reading the docs carefully in the general (non-android) case.
<sima>
yeah I think unless your use-case is "extremely memory limited machine where you realistically can only ever allocate 2 buffers and are willing to trade latency for throughput by pipeling everything as deeply as possible" you do not want it
<sima>
maybe we should add that to the property docs
<sima>
if someone volunteers to type this patch I could upfront r-b it?
deliveryguysad has joined #dri-devel
<lynxeye>
sima: I guess I can add some words of caution there. I still don't see how signaling that fence without a follow-up flip queued does improve pipelining. I do see how making this fence wait for queued flips before signaling would add lots of state tracking to the kernel, as the fence is on a atomic commit level, not the much simpler FB level.
Fijxu has joined #dri-devel
<sima>
lynxeye, hm maybe we're talking past each another still
<sima>
so you have two buffers, A currently being scanned out, B finished rendering, flip queued up
<sima>
now in the old days you'd need to stall the opengl stack until A becomes available
<sima>
with the out-fence userspace/app can start to queue up rendering and push it to the kernel
<sima>
and the gpu even start with vertex processing
<deliveryguysad>
That you know better than me, who is at my side and who is not, is not true, your secret intelligence parts, do not know my case better than me, i hacked all the monsters, even though they thought i was stupid. I now i have changeable ip addresses based vpn's so that llvm irc retaliate fart guy is correct technically , you can not distinguish vpn dynamic ip address as offshore
<deliveryguysad>
signalling or scam. It is not possible 160bit HMAC 128-bit aes, it does not matter what vpn it is vray mesh, openvpn, or wireguard, if you renew the ip lease dynamically for public ip, instagram nor facebook nor any site understands that i use vpn. So he is there and in many other subject spot on, but not on me.
<sima>
even while the flip is still queued up
<deliveryguysad>
it's sha1 two rounds of emersion client you can not handle either, dynamic session.
<sima>
and if you miss the next vblank then sure there's going to be a stall, but the assumption is that you simply do not have memory for buffer 3, so there's no way to avoid it
<sima>
also with a more modern app/driver stack like vk you could do this yourself mostly
<sima>
but this was designed back when command parsing and relocations in the kernel was all the rave, and gl drivers where a lot dumber
<sima>
so queuing up in userspace means you still had to do that kernel work when the buffer was finally available
<lynxeye>
sima: Yea, I guess it makes sense for the case where you expect rendering and flips being busy. It's just that it doesn't make a lot of sense to signal that fence when there is no B flip queued up, which is what causes the footgun trap.
<sima>
lynxeye, yeah that's just compositor being broken
deliveryguysad has quit [Remote host closed the connection]
<sima>
but that's the same for gpu compositing, if you just hand back a random out-fence for a buffer that has no relationship with when the buffer isn't in use anymore, then yeah that's a bug
mlankhorst has quit [Ping timeout: 480 seconds]
<sima>
like gpu compositing might also need to later on recomposite, and if you've already signalled the out_fence for the only current buffer you have from the app, you're broken
<sima>
exact same thing applies to kms, except with kms direct plane scanout the recompositing is guaranteed
<lynxeye>
sima: It means the compositor can't implement a fenced release of the buffer by using the KSM out fence. With GPU rendering you can do that: if you know the client has a new buffer lined up for the next time you render, you can use the GPU render fence to pass back to the client for fenced release. If you do the same with the KMS out fence you might miss the vblank for scheduling the next flip and the fence signals too early, so
<lynxeye>
ompositor/client can't use that for fenced release.
<sima>
oh I forgot: on some android they actually used the manual scanout buffer to hold the frame, so they could signal the buffer much earlier
<sima>
but that's again future fence semantcis
<sima>
lynxeye, you only get the out_fence when you've submitted the flip to the kernel
<sima>
at which point if you miss the vblank your entire screen eats the miss and there's nothing you can do
<sima>
if you try to hand the fence back earlier it's a future fence, with all the perils that entails
Fijxu has quit [Ping timeout: 480 seconds]
<MrCooper>
lynxeye: the fence doesn't signal before the atomic commit completes
<sima>
and if you drop a frame because it's not ready but still hand out the out_fence for that flip back to the app, you're just broken
<lynxeye>
sima: You get the out fence when you submit the flip _to_ this buffer and it will signal when the buffer has been scanned out once. What you want for fenced release is a fence that singals when a next flip _away_ from that buffer is scheduled and scanout is done.
Fijxu has joined #dri-devel
<sima>
lynxeye, yeah that's just busted
<MrCooper>
which is indeed what RAOF's plan was presumably, it's still problematic for the reasons I describe
<MrCooper>
*described
<sima>
and unless you're ok with trading latency for more throughput with deeper pipelining, you shouldn't even do that 2nd approach, like MrCooper explained
<sima>
but the first one you've described is just plain broken
<sima>
and it would also be broken on the gpu compositor path, if your compositor ever needs that frame again for a recomposition
<sima>
unless you go with the X11 school of "surely background color is an acceptable fallback to a damage event"
oftckindones has joined #dri-devel
mlankhorst has joined #dri-devel
<lynxeye>
sima: Again, it works for the render composition path if you know the client has lined up a new buffer for the next composition cycle, as the next render composition will use the new buffer for sure. So you can pass the render fence to the client for fenced release (which is what weston does today). With the KMS fence that's not possible, even if you have a flip to another buffer scheduled it might still miss the vblank and you e
<lynxeye>
with scanout reusing the buffer after the out fence has signaled.
<sima>
lynxeye, how?
<sima>
like buffer A is currently being scanned out, B is queued up with a kms flip
<sima>
you tell the app that it can render into A as soon as the out_fence for B has signalled
<sima>
the kernel misses a vblank
<MrCooper>
lynxeye: again, the fence doesn't signal before the commit completes
<sima>
the out_fence is delayed appropriately, it will not signal on the next vblank, but the next vblank after the flip actually happened
<MrCooper>
so what you describe can't happen
<sima>
so how does the app manage to render into A while it's still being scanned out?
lfryzek has quit []
Fijxu has quit [Ping timeout: 480 seconds]
<sima>
the docs should be really clear on this, if they're not we need to fix them
<MrCooper>
lynxeye: the commit missing a refresh cycle is a problem in itself
<sima>
but that's not a "latency/throughput tradeoff" but a "it's just broken" thing
Fijxu has joined #dri-devel
<oftckindones>
now, you perhaps wanted to signal me, that i was abusive to david heidelberg, which i know i was firing words at you all, i have absolute memory, do not bother, maybe that i would get some in the ass, do not bother, maybe that its time to change my identity, yeah i know , do not worry, i know everything about my case, however i do not know why you changed the name to female ones, like
<oftckindones>
sima, emma, and whatever the gfxstrand is , cause that is your internal life, i hope that i did not cause the like for the earlier reasons or for some other reason.
<lynxeye>
sima: Now I'm confused again. Why would the app want to wait until the out fence for B signals if it want's to render into A? That's a full scanout cycle of latency. Surely it would want to start rendering into A as soon as the display engine has flipped away from A?
<sima>
lynxeye, that's what will happen
<sima>
where do you see an additional vblank happening?
<sima>
the out_fence for B signals the moment the hw stops scanning out A and starts scanning out B
<sima>
it does _not_ signal when the hw has finishes scanning out B for the first time
<lynxeye>
argh, seems I read the docs wrong _again_
<sima>
it's an out_fence for the flip itself, not for buffer B
<sima>
same applies to gpu compositing
<sima>
you don't need to wait with the out_fence for buffer A until you've finished rendering with B
<sima>
all you need is wait until you've committed to rendering with B and don't need A anymore
<sima>
so the out_fence for A would be whatever the end-of-batch fence for the last render job that used A is
<sima>
not the end-of-batch fence of the first render job that uses B
<sima>
otherwise you have a notch too much latency in your signalling
<sima>
exact same story with kms
Fijxu has quit [Quit: XD!!]
Fijxu has joined #dri-devel
lfryzek has joined #dri-devel
<lynxeye>
right, so it's totally fine to plug the out fence from commit with buffer B into the fenced release for buffer A.
lfryzek has quit []
oftckindones has quit [Remote host closed the connection]
jsa1 has quit [Remote host closed the connection]
<MrCooper>
it works correctly, so it's "fine" if you don't care about the issues I described
rasterman has joined #dri-devel
lfryzek has joined #dri-devel
<lynxeye>
MrCooper: But isn't this a policy decision you would want the client to make? If it doesn't want to allocate more buffers for any reason, it can pick a buffer with a unsignaled release fence for the next rendering, potentially waiting for a missed vblank or whatever. If the client cares about avoiding that, it should pick a buffer with the fence already signaled or potentially allocate a new one. How is this different from a GPU
<lynxeye>
r fence received from the compositor?
<MrCooper>
how can the client know if it's a KMS fence or a GPU fence?
<MrCooper>
(warning, rhetorical question :)
<MrCooper>
if it can't, it can't make that choice
Fijxu has quit [Ping timeout: 480 seconds]
<lynxeye>
MrCooper: Why does the client care? If the buffer release fence is unsignaled it may stay in that state for quite a while, regardless if it's a KMS or GPU render fence. If you want to avoid blocking at any cost, you must use a buffer with a signaled fence.
<MrCooper>
as explained before above: GPU fences are guaranteed to signal ASAP, KMS ones aren't
<MrCooper>
look, feel free not to trust me on this, you can't say I didn't warn you though :)
tobiasjakobi has joined #dri-devel
<lynxeye>
MrCooper: I still don't get the difference. The flip for the KMS fence is queued, so it's ASAP as-in whatever the next reachable vblank is. The job signaling the compositor GPU render fence might be delayed in the same way by another job hogging the GPU queue.
<lynxeye>
If the client want to avoid blocking on buffer availability it must choose a buffer where the release fence is already signaled.
<MrCooper>
to put it differently, it's very unlikely that any future GPU work by the client could start before a GPU fence from the compositor signals anyway, this isn't true for a KMS fence though
<MrCooper>
a job which blocks the compositor GPU work also blocks future client GPU work
<lynxeye>
MrCooper: Agreed, if you talk about a single GPU with one execution queue. In a hybrid setup you might run the composition on a different GPU than the client.
<MrCooper>
true
<MrCooper>
(having a déjà vu right now :)
tobiasjakobi has quit []
<MrCooper>
that just makes GPU fences more problematic though, not KMS ones less so
<lynxeye>
right
<lynxeye>
I guess what I'm saying is that the client should always expect the fences to be problematic ;)
<MrCooper>
indeed, so clients should probably only re-use a buffer with unsignalled release point if they can't allocate another one
<lynxeye>
yep, randomly picking a buffer just because you received a fenced release for it is a recipe for hurt, maybe just more pronounced right now if the release fence happens to be a KMS one.
<sima>
MrCooper, there's also multi ctx scheduling in pretty much all hw
<sima>
or most at least
sarnex has quit [Ping timeout: 480 seconds]
<sima>
plus if someone hangs on a ringbuffer gpu you look at a multi-second timeout
<sima>
so not sure why the gpu fence is less problematic than the kms one
<sima>
my take is this is down to how much memory you can waste, and where you are on the latency/perf tradeoff
<sima>
which is really tricky
<MrCooper>
right (amdgpu being a notable exception, it's getting there though :), still unlikely that future client work can preempt already-flushed compositor work though
<sima>
yeah you generally don't win against the compositor
<sima>
but the latency/throughput still applies
<sima>
like maybe app wants to queue up the next frame as soon as possible, because it's cpu intensive to do that
<sima>
or it wants lowest latency and does everything super late close to next vblank
<sima>
or whatever the app feels like
dviola has quit [Ping timeout: 480 seconds]
<sima>
so I'm with lynxeye that I'm not seeing why returning a buffer with an unsignalled out_fence is harmful
<sima>
no matter which one
<sima>
if you don't care about memory, just allocate more winsys if you'd block otherwise
<sima>
if you don't, pick the right choice according to your latency/throughput goals
<sima>
ofc if the app is dumb and just blindly starts rendering the moment it gets a frame back
<sima>
you get to keep all the pieces
<MrCooper>
point is that assuming the client uses the same GPU as the compositor, it can use a buffer with unsignalled release GPU fence without penalty, whereas this isn't true with a KMS fence
<MrCooper>
*my point
<sima>
unless the goal was intentionally to not ever waste memory and prioritize throughput
<sima>
MrCooper, but does that case exist?
<sima>
like with a reasonable compositor you don't start the next frame before the previous one finished
<sima>
so if the compositor then picks a new buffer for that rendering, the old buffer is already not in use
<sima>
because the out-fence for the buffer is when it was last used for rendering, _not_ the out-fence for the first rendering of the next buffer
<MrCooper>
not sure what you're asking, it's like the majority of GL and possibly Vulkan apps
<sima>
I'm asking whether the compositor in the gpu path actually ever hands back a buffer with a non-signalled outfence
<sima>
unless it's kinda busted
<MrCooper>
mutter does
<sima>
or the compositor already decided to toss latency overboard, at which point the app trying is pointless
<sima>
how does that happen?
Fijxu has joined #dri-devel
<MrCooper>
it may set the GPU fence of its last compositing work on the release point as soon as the client has attached another buffer, which may be before that work has finished
<lynxeye>
same for weston iirc
<sima>
but that's the "we tossed latency already" case
<sima>
if the compositor doesn't toss latency, it waits with picking which buffer when it composites the next frame
<sima>
at which point the previous has finished
<MrCooper>
not sure what you mean by "toss latency"
<sima>
unless your app renders so fast that the new app frame finishes faster than the gpu compositing of the dekstop
<MrCooper>
if anything this helps latency, doesn't hurt it
<sima>
if the compositor already commits to using B while A is still being used it might miss a frame because B isn't done yet
jkrzyszt has joined #dri-devel
<MrCooper>
not what I'm saying
<sima>
so I'm assuming we have a compositor which does a late decision about which frame, shortly before the point of no return for the next vblank
<MrCooper>
commits to using B while GPU work using A is still in flight
<sima>
then quickly queues up gpu work and issues the kms flip
<MrCooper>
gamescope maybe
<sima>
MrCooper, at that point, is B finished rendering or fence still pending?
<MrCooper>
finished (in mutter and most other compositors)
<MrCooper>
actually mutter also does something like what you describe (though the mechanics work a bit differently)
jkrzyszt_ has quit [Ping timeout: 480 seconds]
<sima>
so if B is finished, but A isn't yet, the app is rendering much faster than your compositor
<sima>
you're not going to have any problem at all
<MrCooper>
unless you care about benchmark numbers ;)
<sima>
but if the compositor commits to B before it's finished, it's not prioritizing latency
<daniels>
fwiw OUT_FENCE_PTR was indeed written to support the case where people wanted to queue up deeper pipelines of work without necessarily caring about immediate latency or hitches
<sima>
MrCooper, the app allocates more frames to keep the benchmark people happy and the compositor hopefully does mbox semantics for flips?
<daniels>
if you are gunning for the absolute minimal possible latency and getting some kind of new content on every refresh no matter what, then that is not the hammer for you
<sima>
unless you're super constrained and want to limit to just 2 buffers, at which point you'll block until the previous one is available no matter what
<sima>
and would much prefer you can block on a dma_fence since that block point is later
<MrCooper>
sima: the point is that if the client re-uses a buffer with an unsignaled KMS fence, its frame rate will be capped to the display refresh rate
<sima>
MrCooper, isnt' that the point?
<sima>
if you want free-wheeling mbox winsys flips, you need to make sure those happen
<MrCooper>
not if the client wants to go as fast as possible, which it can with unsignalled GPU fences
<sima>
and sure usually the kms flip fence takes a bit longer than the gpu flip fence, but it would still not be mbox
<sima>
MrCooper, who says your compositor is not super dense and queued up that gpu fence behind a kms flip out_fence?
<sima>
if you want free-wheel, you need to do that
<MrCooper>
k, this is getting too hypothetical
<daniels>
sima: it's not just about being super-constrained, but by the time you've allocated a buffer with all the disruption that ensues (mmu etc), you're probably too late anyway
<sima>
I'm still not sure what's the use-case beyond benchmark numbers
<sima>
like if you have something like gamescope you still want to free-wheel and absolutely ignore every buffer with unsignalled out-fence
<sima>
daniels, yeah but aside from startup that shouldn't happen during runtime
<daniels>
yeah. if you want to build something like kmscube, then use OUT_FENCE_PTR and it'll be useful to you. if you want to build something like gamescope, build gamescope instead and don't use OUT_FENCE_PTR because it's not useful to you.
<daniels>
I don't think there's anything controversial there
<lynxeye>
I guess that takeaway is simple: if you don't want to block unexpectedly, don't use random buffers with unsignaled release fences, in which case you don't care if it's a render or kms fence and also don't care about compositor policy regarding latency vs. throughput.
<MrCooper>
I never claimed anything else; if you're fine with your compositor potentially producing orders of magnitude lower benchmark numbers than others, go for it! ;)
* daniels
shrugs
<sima>
daniels, there at least was more than just kmscube that wanted out_fence for deeper queues
<sima>
but it's really only "I can allocate 2 buffers but not 3 because simply not enough memory"
Fijxu has quit [Ping timeout: 480 seconds]
feaneron has joined #dri-devel
rossy_ has quit [Remote host closed the connection]
rossy has joined #dri-devel
<daniels>
or, you do have 3 or 4 buffers, but for whatever reason (ease of design, deep hardware pipelines, slow hardware, whatever), you queue work up long in advance
warpme has quit [Read error: Connection reset by peer]
warpme has joined #dri-devel
warpme has quit [Read error: Connection reset by peer]
<sima>
bit dinner time already, but let me try at least
* robclark
neither
<sima>
hm held_lock->references is an uint, at least here
<sima>
so overflowing that with lots of gem bo seems unlikely
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
<robclark>
tbf this is sparse/vm_bind type thing, so same bo could appear many times (but I think drm_exec should just be skipping the dups)
<robclark>
still, I don't think it would be 2^^32
<sima>
robclark, we should skip the already locked ww_mutex for the EDEADLCK case, those should never get to lockdep
<robclark>
right
iive has joined #dri-devel
<sima>
well for the initial trylock case, but the lock_acquired is only for the success case
<sima>
robclark, feels like quicksand and I'm scared
<sima>
can you repro this reasonably well?
tzimmermann has quit [Ping timeout: 480 seconds]
<robclark>
so far just saw it once when running dEQP-VK.sparse_resources.buffer.\*
<sima>
hm
<robclark>
I can see if it is repeatable, but so far sample size of 1
rbm has quit [Remote host closed the connection]
<sima>
I guess first try to repro reliably or faster because I have no idea what's up here
<sima>
and then maybe we can try to trac ww_mutex_lock for dma-buf and see what's up
<robclark>
k.. just wanted to see if anyone else was familiar with that before I spent more time on it vs debugging $my_bugz
<sima>
nah this sounds like lockdep internals gone very wrong potentially
<sima>
but it's current->held_locks and if you somehow manage to corrupt that I'd expect the entire kernel to crash&burn much earlier
<robclark>
well, I _am_ playing with objs, locks, and mapping .. so can't rule out corrupting things, but yeah, I'd expect more of a fireball if things went wrong there
vliaskov has quit [Read error: Connection reset by peer]
<sima>
robclark, before you waste time trying to repro
<sima>
ww_mutex_lock on the same lock in a loop, until you've gotten -EDEADLCK UNIT_MAX times?
<sima>
because I'm not entirely sure that's handled correctly, and it's about the only guess I have about what could go wrong
<sima>
because I'd guess you do not actually have UINT_MAX distinct ww_mutex in your machine
<robclark>
hmm, we could be re-using the same obj (and lock) many times..
<sima>
yeah
<DemiMarie>
MrCooper: why would a program ever want to render more than once per frame? That is just wasting the user’s GPU and electricity.
<sima>
and then maybe walk those a few times
<sima>
and then maybe an accounting bug in lockdep so that you exhaust much quicker than 2^32 attempts
<sima>
a stretch at best, but the only one I've come up with
<robclark>
seems plausible
soreau has joined #dri-devel
<sima>
robclark, and allocate the lock from a gem_bo or so, because lockdep handles allocated locks differently from static ones
<sima>
just to make sure you're not chasing the wrong phantom here
<robclark>
yeah, will hack that up in ~5 or so.. just looking at a differnt bug first
<sima>
I'll get myself stuffed with raclette meanwhile, it's ready now
<robclark>
enjoy
dos1 has joined #dri-devel
<mattst88>
mmmm, raclette
jsa1 has quit [Ping timeout: 480 seconds]
Perseverance_ has joined #dri-devel
<karolherbst>
alyssa: I didn't even check how it's represented in the spirv, but I expect that's implemented with some new nir intrinsic we'd tell drivers to implement? Don't really know if this feature is all emulated in runtimes or if there are actually hw supporting it natively
<alyssa>
karolherbst: ye, the spirv is a pretty straightforward translation of the cl
<alyssa>
clang hoists the block function into its own function, lays out a structure for the capture, and passes it in as a u8* generic pointer
<karolherbst>
right...
<alyssa>
but the heavyweight enqueue is going to be in driver runtimes
<karolherbst>
I was more wondering to what enqueue_kernel translates to
<alyssa>
similar problem space to DGC in vulkan
<karolherbst>
like what spirv instruction is used there
<alyssa>
it's just an EnqueueKernel spirv instruction
<alyssa>
or something
<alyssa>
with a function pointer thing
<karolherbst>
ohh "OpEnqueueKernel"
<karolherbst>
yeah, now I also find it in the specs 🙃
<karolherbst>
I'd have ideas on how to implement it on nvidia, just 0 ideas on how to do it in gallium, but maybe that's just gonna be a driver thing in it's entirety
<karolherbst>
+ whatever lowering we do in nir
Perseverance has quit [Ping timeout: 480 seconds]
<karolherbst>
there is also the problem of fencing or rather.. events it's called here
<karolherbst>
but that's just "OpGroupWaitEvents" I guess
<DemiMarie>
Where is the right place to request a Mesa-specific extension? WebGL and WebGPU implementations generating SPIR-V are having to resort to ugly hacks because Vulkan requires that all shaders terminate.
<airlied>
why would that be mesa specific?
kts has quit [Quit: Leaving]
<karolherbst>
at least there is no relation between API and kernel events 🙃 that would be cursed
<robclark>
sima: no luck with the repeated locking in a loop, so I guess it is more complicated to repro than that
<robclark>
it seems to be dEQP-VK.sparse_resources.buffer.ssbo.sparse_binding_aliased.buffer_size_2_24 which triggers it
<robclark>
hmm, well maybe that was just coincidence
dviola has quit [Read error: Connection reset by peer]
urja has quit [Ping timeout: 480 seconds]
diego has joined #dri-devel
<pixelcluster>
DemiMarie: can you clarify? what hacks are you talking about? "shaders that don't terminate" doesn't sound like something that will really work ever to me but I might be missing something
<sima>
robclark, hm running low on ideas then
lynxeye has quit [Quit: Leaving.]
diego has quit [Read error: Connection reset by peer]
diego has joined #dri-devel
<karolherbst>
DemiMarie: shaders not terminating would need an entirely new entry point to be launched and probably have to be compute only
<karolherbst>
if you want to do compute, don't use graphics
<pixelcluster>
well, what valid webgpu/webgl app would ever want non-terminating shaders in the first place?
diego has quit [Read error: Connection reset by peer]
<karolherbst>
vulkan probably will need an extension for long running compute jobs anyway to implement CL on top of it tho
<pixelcluster>
oh yeah, for actual compute tasks I totally see the use case for persistent thread-style stuff
<karolherbst>
pixelcluster: at some point non-terminating or shaders running for 5 minutes doesn't really make much of a difference :D
<pixelcluster>
just not... webgl :P
diego has joined #dri-devel
<karolherbst>
so yeah.. I can totally see the use case for compute
<karolherbst>
but it might require a special entry point to launch such tasks
<karolherbst>
"just make shaders run long" won't fly
<pixelcluster>
yeah, I'm also kind of unsure about the lower levels of the stack
<karolherbst>
though with vulkan it could be an extension struct passed on the enqueue for compute have special timeout properties
diego has quit [Read error: Connection reset by peer]
<karolherbst>
*having
diego has joined #dri-devel
tobiasjakobi has joined #dri-devel
<karolherbst>
like "vk_ext_explicit_compute_timeout" or something
tobiasjakobi has quit []
<DemiMarie>
pixelcluster: If a non-terminating shader was guaranteed to either cause `VK_ERROR_DEVICE_LOST` or just hang, that would be fine. The problem is that compilers are allowed to assume that shaders terminate, and a malicious shader can use this to defeat compiler-inserted bounds checks.
diego has quit [Read error: Connection reset by peer]
<karolherbst>
and then disallow using the fences for anything not compute
<karolherbst>
DemiMarie: well you can't prove they'll never terminate
diego has joined #dri-devel
<pixelcluster>
DemiMarie: well, such bounds checks failing should never constitute a security risk
<pixelcluster>
should they?
<DemiMarie>
pixelcluster: yes, they do
<karolherbst>
normal drivers will nuke the context anyway
<karolherbst>
so where is the issue?
<karolherbst>
or rather.. drivers should by default set up sane timeouts for GPU jobs
<pixelcluster>
how is OOB access by shaders a security concern?
<pixelcluster>
as in, this sounds like an issue that should rather be fixed
<karolherbst>
DOS is also a security issue
<pixelcluster>
oh yeah
<DemiMarie>
pixelcluster: The shaders are provided by websites, which are untrusted and might be malicious.
<pixelcluster>
but you get those even if you don't have the bounds check problem
<karolherbst>
DemiMarie well it's up to the browser to ensure there are no data leaks across tabs
diego has quit []
<karolherbst>
if a browser uses the same VK "context" across tabs it's a bug in the browser
<karolherbst>
because it opted into sharing state across tabs by doing so
<pixelcluster>
DemiMarie: sure, ok, let me ask another way: how can OOB accesses result in worse behavior than having your context killed (which is what non-termination will do anyway, so it must be fine)?
<DemiMarie>
karolherbst: Is VK OOB guaranteed to not corrupt CPU memory, and do real browser implementations actually do this?
<DemiMarie>
pixelcluster: they can allow a website to access or tamper with data that it should not be able to access, and therefore perform a security exploit.
krei-se has quit [Read error: Connection reset by peer]
<karolherbst>
so it's like one application doing OOB can't mess with other applications
<karolherbst>
same thing
<DemiMarie>
karolherbst: Web browsers must not allow arbitrary native code execution, sandboxed or otherwise.
<karolherbst>
if your GPU doesn't have an MMU to do virtual memory, then maybe don't use the GPU
<pixelcluster>
well
<pixelcluster>
if the GPU doesn't have a MMU then how is it going to implement Vulkan
<karolherbst>
DemiMarie: well they do
<karolherbst>
and anyway, that's not the issue
<karolherbst>
an OOB access can't corrupt the state of other applications or GPU contexts
<DemiMarie>
karolherbst: there are of course vulnerabilities, but they are vulnerabilities, and that means that they must be fixed
<karolherbst>
if it can in your browser, it's a browser bug
<DemiMarie>
the issue is that an OOB access can corrupt the state of the application performing the access
<karolherbst>
yeah, life is rough sometimes
<karolherbst>
that's why browsers should sandbox their tabs
krei-se has joined #dri-devel
<DemiMarie>
That is good enough for almost everything, but browsers need to guarantee that there are no OOB accesses at all.
<karolherbst>
they don't
<DemiMarie>
karolherbst: that's why you should uses Chromium
<DemiMarie>
karolherbst: they try, and when they fail, they try again :)
<karolherbst>
an OOB access is pretty harmless if you ignore driver bugs
<karolherbst>
what's the threat model here anyway? you visit a website and.. it hangs your tab?
<pixelcluster>
actually
<karolherbst>
web browsers have all the tools necessary to isolate things properly
<pixelcluster>
which guarantees about OOB access are we even talking about
alyssa has left #dri-devel [#dri-devel]
<karolherbst>
I don't even know, but I'm hope bda isn't part of webgpu 🙃
<karolherbst>
*I
dviola has quit [Read error: Connection reset by peer]
<pixelcluster>
I don't think any API (Vulkan especially not) guarantees anything about what happens in OOB accesses
<DemiMarie>
karolherbst: If one isn’t running the UMD in-process, then yes, an OOB GPU access is harmless. That’s why native contexts work.
<pixelcluster>
it's UB in exactly the same way non-terminating shaders are
<karolherbst>
DemiMarie: OOB GPU accesses do nothing to other applications
<DemiMarie>
The problem is that browsers do not use kernel ioctls directly, but rather userspace APIs.
diego has joined #dri-devel
<karolherbst>
the security boundary is your GPU context
<karolherbst>
you can have many of them in vulkan
<karolherbst>
use one per tab
<karolherbst>
done
<karolherbst>
if browser share it between tabs it's their problem and their bug
<pixelcluster>
erh
<pixelcluster>
I think in practice you want to use a process per tab
<karolherbst>
sure
<pixelcluster>
but yes
diego has quit [Read error: Connection reset by peer]
<karolherbst>
and a real vulkan instance per tab and all that
<zamundaaa[m]>
pixelcluster: VK_EXT_robustness2 does make guarantees about OOB accesses
<karolherbst>
vulkan has a bit of documentation on security boundaries across objects
<pixelcluster>
oh right lol robustness exists
<karolherbst>
if those aren't enough, then one can always add an ext tightening it up more
diego has joined #dri-devel
diego has left #dri-devel [#dri-devel]
<pixelcluster>
well in any case, terminating shaders really aren't the (only) problem, what you are asking for is a subset of SPIR-V that has no UB at all
<karolherbst>
right.. but then you have vulkan features like bda with throw aware your oob checks, so we can't only hope that bda isn't exposed in webgpu :D
<pixelcluster>
I don't think it is, for obvious reasons :D
<karolherbst>
it's the wrong solution for this problem anyway
<karolherbst>
it would be fun though (tm)
<pixelcluster>
yes, UB is a thing and we won't get rid of it
<DemiMarie>
pixelcluster: nah, the problem with infinite loops specifically is that it is very hard to get rid of them without incredibly disgusting workarounds, like explicit iteration counters.
<karolherbst>
UB isn't a security problem in applications, and it's not one in GPU programming either as long as you don't pick holes in your security boundaries
<karolherbst>
well
<karolherbst>
it's a problem in applications like sshd 🙃
<karolherbst>
but that's not what we are talking about here anyway
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<DemiMarie>
My preferred solution to all of this would be to compile Mesa to WebAssembly and give it access to the kernel ioctls via a virtGPU native context interface. If the WebAssembly module gets popped, who cares, it's in the browser process which already runs arbitrary WebAssembly. The hardware protections ensure that the compiled shader code can't do harm.
<DemiMarie>
Unfortunately, browser vendors don't take this approach, probably because they have to support platforms with proprietary drivers.
<karolherbst>
it's also another platform specific path
<pixelcluster>
at this point what's the difference between a webassembly module and a properly isolated renderer process?
<karolherbst>
the API used
<karolherbst>
though I fully understand browsers not wanting to isolate to such an extreme extend, because having 500 open tabs can kinda cause funky problems 🙃
<karolherbst>
though not sure if GPU contexts are that limited on modern GPUs
<karolherbst>
prolly not at all
<pixelcluster>
you could also restrict the fancy isolation to the fancy apis
urja has joined #dri-devel
<pixelcluster>
if you have 500 tabs each running webgpu shaders you have bigger problems
<DemiMarie>
Maybe exposing GPU access to random websites without user consent was not a great idea 😆
<DemiMarie>
If WebGL and WebGPU required a permission it would prevent most of the abuse.
<linkmauve>
karolherbst, I currently have exactly 15321 open tabs. :p
<linkmauve>
And Firefox still works!
<Sachiel>
WebGL and WebGPU requiring permissions would just be an extra click from users away from the abuse
<karolherbst>
though did it create 15321 GPU contexts for it's per page rendering
<karolherbst>
I'm sure browsers are a bit smarter than that
<linkmauve>
I doubt so. ^^
<psykose>
a popup asking "Wanna get hacked? Y/N" wouldn't meaningfully change what browsers have to do to sandbox webgpu use at all
<psykose>
reminds me of cookies and privacy policies
<karolherbst>
reminds me of excel
<psykose>
hah
<karolherbst>
and people click accept anyway
dviola has joined #dri-devel
<DemiMarie>
linkmauve: how many of those tabs are actual websites?
<karolherbst>
yeah apparently if you ask users "this thing wants to do X if you press deny it might not work" isn't really telling users to say deny 🙃
heat has joined #dri-devel
<linkmauve>
DemiMarie, all of them!
<linkmauve>
Of course not currently loaded.
<DemiMarie>
linkmauve: Wow!
<sima>
DemiMarie, so with mesa vk if you createa a vkdevice per security context nothing should ever escape that gpu box, not even to your cpu side process
<DemiMarie>
sima: Nice, thanks! That should be enough for browsers then.
<sima>
unless you just put your cpu side datastructures into cpu mmapped gpu memory ofc
<sima>
but don't do that
<sima>
at least that's I'd say what we're aiming for form the kernel side
<DemiMarie>
sima: does Mesa do that?
<sima>
for gl the situation is a mess, but with arb_robustness you should have enough isolation to also not blow up too badly
<sima>
DemiMarie, it would be really, really stupid
<sima>
I've seen one really old intel libva that abused gpu bo for cpu datastructures and that's by far not the worst thing that codebase did
<DemiMarie>
sima: gotcha, just checking
* DemiMarie
wonders what the worst thing actually was
dviola has quit [Read error: Connection reset by peer]
<sima>
I'm not going to uncover those nightmares
diego has joined #dri-devel
<DemiMarie>
Fair :)
<sima>
but I've watched developers who really don't shy away from reworking terrible code to fix it fold in less than a day sifting through it
<DemiMarie>
yeah at that point I would just do a from-scratch rewrite
<sima>
anyway for gl's arb_robustness I'm less sure how solid it is everywhere, so if you're paranoid maybe just limit to vk
<sima>
also don't enable the hsw vk implementation in anv, but I think that might have gotten nuked meanwhile
diego has left #dri-devel [#dri-devel]
epoch101_ has quit []
<sima>
DemiMarie, oh and ofc the usual "this is all aspirational, I'm not speaking for any vendor team including intels" disclaimer, but I think as a dri-devel stance it should be pretty solid
<DemiMarie>
sima: that's good enough for me :)
<DemiMarie>
(in particular, it is good enough for Qubes OS to enable native contexts at some point, which rely on this guarantee, at least as an opt-in option)
<sima>
it's after all still a horribly complex kludge of stuff written in C in both kernel and fw, plus hw is disappointingly also not bug free as we learned the hard way last few years :-/
<DemiMarie>
Is the FW generally of good quality code-wise?
* DemiMarie
wonders if it is time to write drivers and FW in Rust
<sima>
DemiMarie, yeah, even more so going forward if someone comes with a mesa vk driver and the kernel side doesn't just use standard vm_bind with full blown gpu mmu and hw context it's really questionable we'll consider it for merging I think
<sima>
just too busted design imo
<sima>
DemiMarie, I've never seen any fw code in my life for any gpu
<DemiMarie>
sima: Ah, I was thinking that sine you work for Intel you would have at least talked to the people who did write it.
<sima>
for rust in the kernel, we'll hopefully get there, but it's going to be a while
<DemiMarie>
good news is that one can mix Rust and C, even in the same driver
epoch101 has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
Guest293 has quit []
dviola has joined #dri-devel
yogesh_m1 has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
<benjaminl>
how does the bot decide which labels to put on mesa MRs?
gouchi has joined #dri-devel
<karolherbst>
based on touched files
<benjaminl>
hmm, so I have an MR with a commit that touches src/vulkan/runtime, but it didn't get the vulkan label