ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
yogesh_mohan has joined #dri-devel
ella-0 has joined #dri-devel
kchibisov has joined #dri-devel
sumoon has joined #dri-devel
rosefromthedead has joined #dri-devel
kennylevinsen has joined #dri-devel
mainiomano has joined #dri-devel
molinari has joined #dri-devel
ifreund has joined #dri-devel
kuruczgy has joined #dri-devel
Guest2224 has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
sima has quit [Ping timeout: 480 seconds]
<KungFuJesus>
this is with the current verison of rbdoom-3-bfg, btw, I was hoping that I could eek out a playable framerate on the pi5 despite the posted 8fps benchmarks early on
<KungFuJesus>
but since nvhri support had been added, it seems to want a ton of vulkan extensions that it may or may not be making use of currently
<KungFuJesus>
one of which is the compressedBC textures, others are tessellation shaders and that dualsourceblend feature
<KungFuJesus>
not requesting that makes the fps HUD not show up but it gets in menu, haven't managed to get in game though
<KungFuJesus>
also a bunch of ray tracing stuff it seems to want, but again, maybe I can patch that out. I think part of the problem is the dev really wants to try to introduce whiz bang render features into the game, which is cool, but probably not suited for a meager v3d gpu
mbrost has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
iive has quit [Quit: They came for me...]
mbrost has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
<DemiMarie>
Company: how big of a gap do you think there is between what LLVMpipe can do right now, and what a modern multi-core CPU with its wide SIMD units is actually capable of?
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
jsa has quit []
<DemiMarie>
Intuitively, I expect that one of two will hold:
<DemiMarie>
1. You are limited by CPU memory bandwidth, in which case the amount of power consumed will be high enough that even with a GPU users will complain about battery life on mobile.
<DemiMarie>
2. You are limited by SIMD throughput, which is the case where a GPU would really help.
<DemiMarie>
Is this a reasonable assumption?
<DemiMarie>
This assumes that GTK wants to be nice with other applications and the user’s battery, which I presume is a decent assumption.
<DemiMarie>
Company: do you know of anybody in the thin client case who might be willing to sponsor some devs?
<DemiMarie>
(without either me or my company being involved)
<Company>
DemiMarie: llvmpipe will use all the cores you have if you have the right shaders
<Company>
like, I have a 8 core / 16 thread AMD and they're all pegged
<Company>
as for the limit, yes, you kinda have that correct - the bottleneck is (depending on use case and hardware involved) either memory bandwidth between cpu/gpu (which is an effect on discrete GPUs more than on llvmpipe of course), it's SIMD instructions or it's memory bandwidth if the shaders are simple
<Company>
GPUs in the last 10 years got a lot faster in instructions, so if you write a shader that a modern desktop GPU can easily handle, a 10 year old Intel integrated GPU will bottleneck on it
<Company>
another issue is that there's the code on the CPU that generates the instructions for the GPU
<Company>
GPUs have gotten a lot faster relative to CPUs, so on old hardware generating the instructions is pretty much never the bottleneck for GTK
<Company>
and on modern discrete GPUs, generating the instructions is almost always the bottleneck
<Company>
that's why my rpi4 gets 30fps with like 30% CPU usage and a pegged GPU and my desktop gets 2500fps with 100% CPU and like 30-50% GPU
<DemiMarie>
Company: 2500fps is a trivial case IMO.
<Company>
what do you mean?
<DemiMarie>
It means your system is running an easy enough workload that it can go that fast
<Company>
it's the same workload
<Company>
my Radeon 6500 is just more than 100x faster than the rpi gpu
<DemiMarie>
“trivial” might not be the right word; what I meant is that your workload is very easy for your system to run, so you will bottleneck on things that would not be bottlenecks at realistic frame rates.
<DemiMarie>
or at least may bottleneck
<Company>
the point is that a different less powerful system will bottleneck on the same workload
<Company>
because gpus easily differ by a factor of 100x between systems
<Company>
while cpus are usually less than 10x
<DemiMarie>
So what I am wondering is how much llvmpipe and lavapipe are leaving on the floor, compared to how well they could be doing
<Company>
I don't know - I think there's quite a bit you can gain if you wanted to - but why would you optimize it for a 64 cpu system if such a system always has a gpu that runs circles around it
<DemiMarie>
As people here probably already know by now, I would much rather GPUs be designed for preemptive multitasking and process isolation, just like CPUs are. Sadly, they are not.
<DemiMarie>
Company: It only has a GPU if it is a client system.
<Company>
it's not that anyone runs llvmpipe on the Oak Ridge supercomputer
<DemiMarie>
Those systems the thin clients connect to probably have no GPUs
<Company>
yeah, but those thin clients also don't have much server CPU
<DemiMarie>
Because GPUs and cloud environments do not go well together at all.
<Company>
the thin client is a thin client because it's cheap, not because it wants to use a datacenter to render a display
<DemiMarie>
What do you mean by “there’s quite a bit you can gain if you wanted to”? Are you referring to scaling to large numbers of CPUs, or using a given number of CPUs more efficiently?
<DemiMarie>
Company: so the VDI world is actually a bit more complex than that.
<Company>
I mean making llvmpipe and GTK generate code that's better suited for CPU execution
<DemiMarie>
Are we talking a factor of 1.5, a factor of 10, or somewhere in between?
<Company>
depends on what you mean - llvmpipe (where I have no idea), GTK's old renderer, GTK's new renderer, GTK's drawing in general, or a combination
<DemiMarie>
Something that is not going to be abandoned
<DemiMarie>
So the new renderer and drawing in general
<Company>
the new renderer is about 5x slower on llvmpipe than the old one atm
<DemiMarie>
how much of that could be recovered?
<Company>
everything probably
<DemiMarie>
how much work would be involved?
<Company>
no idea, I didn't try yet
<DemiMarie>
if you could try that would be great
<Company>
like, it needs an optimization stage that makes it not do AA when everything is integers
<alyssa>
Company: OOI, why Vulkan if you're never CPU bottlenecked when running at 144fps?
<DemiMarie>
Company: that would help GPU perf too, right?
<Company>
alyssa: because Vulkan is better with the weird things that GTK does, like dmabuf import/export and Wayland integration
<alyssa>
ah, sure, yeah
<DemiMarie>
Company: there are many old GPUs that will _never_ get support for Vulkan, so using Vulkan means those fall back to lavapipe
<Company>
alyssa: and because I learned Vulkan before GL and I like Vulkan more
<DemiMarie>
and notably Asahi doesn’t have Vulkan support yet IIUC
<alyssa>
no argument there
<Company>
alyssa: there's also the question about using compute for various things, though with GL extensions you can do that with GL, too - but it's almost always easier for me to write the code in Vulkan first and then add the GL codepaths later
<alyssa>
ESO-only VK seems legitimately nice to work with tbf
<Company>
ESO?
<alyssa>
EXT_shader_object
<alyssa>
no pipelines, no render passes
<Company>
I haven't looked at that at all yet
<Company>
I started this renderer's basics in 2017 when that wasn't a thing and then went from there
<Company>
fwiw, Vulkan is noticeably faster than GL with the new renderer - like the 2500 fps are Vulkan, new GL gets around 1600 (or 1800? don't remember)
<alyssa>
Very curious
<alyssa>
on AMD?
<Company>
I suspect it's some driver overhead because we're CPU bottlenecked
<alyssa>
(radeonsi vs radv?)
<Company>
but it could also be that Im doing things wrong
<Company>
yeah, 6500XT
<alyssa>
Fascinating
<Company>
but it's faster on my Intel Tigerlake, too
<alyssa>
yeah it's just that AMD is the reference hardware ;P
<Company>
950 vs 650 or something
<Company>
my Tigerlake is the laptop where CPU and GPU are both near 100% for this dumb benchmark I use
<Company>
one thing that both AMD and Intel get "wrong" sometimes is that for some shaders, GL wins
anujp has quit [Ping timeout: 480 seconds]
<Company>
I suspect SPIRV uses different optimizations than GLSL and I end up with worse gpu instructions
<Company>
what makes me think that is that I turned off optimizations in glslc and things got noticably faster
<Company>
but I didn't look any further into it when that happened
<Company>
DemiMarie: the thing with Vulkan is that we can make it do complicated things fast for the best GPUs out there - and that can be a lot of fun
<Company>
DemiMarie: and example would be vector rendering openstreetmap and get smooth 120fps zoom in/out
<Company>
can still fall back to texture tiles for slower hardware
<Company>
there's lots of stupid ideas, like zoom-out/zoom-in in text documents instead of scrolling
<Company>
but if you zoom out a 500MB document, that's a lot of text
<Company>
it's just that nobody ever tries that, because toolkit renderers are crap
<Company>
EXT_shader_object is only supported by lavapipe so far - so nothing I need to look at for a while
<alyssa>
radv just landed support
<alyssa>
there are open MRs for nvk and turnip
<Company>
I was about to say, if nvk can't even do it I'll lose faith
<Company>
I guess it's not a big benefit if you need fallback code with renderpasses for everything else anyway
<alyssa>
Company: nvk can do anything if you have Faith
heat has quit [Ping timeout: 480 seconds]
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
alatiera has quit [Quit: Connection closed for inactivity]
benjaminl has quit [Remote host closed the connection]
<DemiMarie>
Company: I would expect zooming a huge document to re-render the text as needed.
glennk has quit [Ping timeout: 480 seconds]
<Company>
yeah
<Company>
and now imagine you zoom out to a text size of like 3px
<Company>
that's like 360 rows of text you need to render
kts has joined #dri-devel
lemonzest has quit [Quit: WeeChat 4.2.1]
junaid has joined #dri-devel
asdf has joined #dri-devel
asdf has quit []
hax0kartik[m] has joined #dri-devel
<Company>
DemiMarie: btw, 2 low-hanging fruit examples of things where software rendering could improve a lot:
<Company>
1. damage region support isn't implemented, ie eglSwapBuffersWIthDamage() doesn't work (on Wayland, no idea about X11)
<Company>
which means the compositor will blit the full buffer even if there's only a spinner rotating in a corner
<Company>
2. there's no dmabuf implementation for software rendering
<Company>
which means everyone has to implement their own codepath for shm which means all the optimizations for dmabufs don't apply
<Company>
and there's no reason why such a thing shouldn't exist
lemonzest has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
fab has joined #dri-devel
sima has joined #dri-devel
simondnnsn has joined #dri-devel
bolson has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
glennk has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
rooq96 has quit []
rooq96 has joined #dri-devel
molinari has quit [Ping timeout: 480 seconds]
sarthakbhatt has quit []
sarthakbhatt has joined #dri-devel
Company has quit [Quit: Leaving]
tomba_ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
Ermine has quit [Remote host closed the connection]
Ermine has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
apinheiro has joined #dri-devel
riteo has joined #dri-devel
<riteo>
hiii!
pcercuei has joined #dri-devel
<riteo>
Over at Godot we do a bunch of weird things to try and default to a chunky, dedicated device. During the GLX days we forked a bunch of times, initialized some contexts and detected the vendor for some priority calculation. Now, with EGL, it looks like we can use EGL_EXT_explicit_device, but I have a bunch of questions I can't find an answer for.
glennk has quit [Ping timeout: 480 seconds]
<riteo>
First of all, can we trust the device list order to be consistent? The spec does not say anything there so that might be a no, but as mesa does not support the device ID extension, I can't see really a good way to let us select a card based on our (or the user's) preference.
<riteo>
Second, why are SW renderers (or at least, LLVMPipe) excluded from the explicit device logic? Is it because it's not backed by a physical device?
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
<riteo>
(to be clear, by "explicit device logic" I mean the fact that it ignores them when creating a platform display with an EGL_DEVICE_EXT attribute)
heat has joined #dri-devel
<riteo>
uh right, one last clarification: the GLX approach relied on forking _and_ setting DRI_PRIME, which BTW I think also excludes LLVMpipe
<apinheiro>
we don't have a clear idea of when we would work on it though
<apinheiro>
about tessellation shaders
<apinheiro>
although it was also requested by other ports
kts has quit []
<apinheiro>
it is clearly out of our TODO list
<apinheiro>
technically the hw would be able to support it, but it would rquire a really big amount of work to get it done
<apinheiro>
about compressedBC
<apinheiro>
v3dv supports BC1, BC2 and BC3
<apinheiro>
but we can't enable that feature unless we support all (BC1 - BC7)
<apinheiro>
having said so, last time I tested the game you mentioned, RBDOOM3-BFG, before the big revamp
<apinheiro>
it used a BC texture that we supported
<apinheiro>
so it worked fine if you skipped that check
<apinheiro>
I had a early plan to write a patch so it checked for formats supported instead of that feature, but didn't have time
<apinheiro>
btw, at that time, before such big revampt, we were able to get ~8fps, or 11fps using a gfxreconstruct trace on the rp4
<apinheiro>
it is surprising that now after the big refactoring on the game, rpi5 gets 8
<apinheiro>
although I guess that as part of that they added more effects and so on
<apinheiro>
btw, before, when I talk about the "big revamp" I mean the big revamp on RBDOOM3-CFG
<apinheiro>
ah yeah, you already mentioned it: when they moved to use nvhri
kts has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
glennk has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
junaid has quit [Quit: leaving]
junaid has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<daniels>
riteo: device order is absolutely not stable
<daniels>
and yeah, swrast just isn’t a device as such
<alyssa>
apinheiro: OOI what's hard about tess if you have hw?
Haaninjo has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
kzd has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
simon-perretta-img has quit [Ping timeout: 480 seconds]
<riteo>
daniels: thanks for the clarification!
<riteo>
I suppose that we can't implement a suitable improvement to the DRI_PRIME solution without the device ID, all right
<daniels>
riteo: sorry it’s maybe not what you wanted to hear
<riteo>
nah, it's perfectly fine
<riteo>
it was an actual thanks
<riteo>
this stuff is not really well documented
<riteo>
anyways, we already have the DRI_PRIME hack, which is awful but will do fine for now I think
<riteo>
so it's not really an issue
kts has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
simon-perretta-img has joined #dri-devel
<daniels>
why do you need DRI_PRIME when you have explicit devices?
simon-perretta-img has quit [Ping timeout: 480 seconds]
<riteo>
daniels: because we fork
<riteo>
I don't have much experience with this stuff, but it looks like opening a lot of context (for glGetString) is a bit problematic as drivers might crash and there's some memory increase due to static allocations
<riteo>
or at least this is what I got told
<riteo>
BTW this definitely applied in the past, as the whole DRI_PRIME thing uses forking and pipes exactly for this reason, as per the comments
<riteo>
and the comments say this: `// Fork so the driver initialization can crash without taking down the engine.`
<HdkR>
Nice
<riteo>
HdkR: what's nice
<daniels>
i mean, drivers absolutely should not be crashing
<HdkR>
Using fork to avoid driver crashing :)
<daniels>
else GL would be kind of unusable
simon-perretta-img has quit [Ping timeout: 480 seconds]
<riteo>
I think that the idea is to not crash for a device that we're not actually using
<riteo>
maybe a bad iGPU
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
<riteo>
HdkR: oh cool! TBC it's not my approach, you have to thank hpvb for that
<HdkR>
Ideal world is to poke at this with fork+execve to ensure sanity in thread state but I love the courage to use raw fork
<riteo>
HdkR: this stuff is done extremely early so there should be very little in the way, if I'm understanding properly what you mean
kts has joined #dri-devel
<HdkR>
Yea, the earlier the better there :)
<riteo>
daniels: BTW I think that this might also be related to the funky nvidia drivers
<riteo>
again, I know extremely little so don't be afraid to correct me
<riteo>
I'm trying to learn as I go
<riteo>
so, are you proposing to just go enumerate each device, start a context and evaluate what device to choose all in one go?
<riteo>
BTW I can also ask hpvb to come here if that might be useful, as they definitely know their stuff better
kts has quit []
<riteo>
I let them know about this discussion, so that they can join if they want
Leopold has joined #dri-devel
<riteo>
I'd still be interested to know more personally, though
<KungFuJesus>
apinheiro: are you saying you can get in game on an rpi5 with it?
<KungFuJesus>
or did you misinterpret what I said to mean I got in game? I didn't get past the menus
<KungFuJesus>
even with the latest version of mesa, it just brings down the window manager
<KungFuJesus>
it could be the reliance on the rt features but my bet is the tesellation shaders
danylo has quit [Ping timeout: 480 seconds]
<KungFuJesus>
on the distro distributed mesa, I got a kernel stack dumped to dmesg, though I didn't save it
<KungFuJesus>
but yeah, perhaps the best direction I can take is forking from the last commit pre nvhri and trying to go from there
kts has joined #dri-devel
simon-perretta-img has joined #dri-devel
simondnnsn has quit [Remote host closed the connection]
simondnnsn has joined #dri-devel
danylo has joined #dri-devel
<mairacanal>
KungFuJesus, any chance you could provide us the dmesg log?
<KungFuJesus>
possibly, I can hit it over SSH but the the display stack kind of requires a hard reboot. Let me try using the distro's mesa again (rpi os). I also don't recall offhand if it requires the default 16k page kernel or not, that may have been a bigger role
<cheako>
Where should I ask about the steamdeck getting hdmi@60hz on a tv? I have lots of details but keeping this message short.
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
<KungFuJesus>
mairacanal: trying to reproduce now, I'll send a pastebin if I manage to
<KungFuJesus>
yeah it seems like it's related to the default 16k page kernel
<KungFuJesus>
so, with a standard page size kernel (probably 4k) the display manager just crashes and restarts
<KungFuJesus>
but with a 16k one, I get this, requires a hard reboot to get the display device working again
<apinheiro>
> <KungFuJesus> apinheiro: are you saying you can get in game on an rpi5 with it?
<apinheiro>
KungFuJesus, most of my replies were about the features missing
pcercuei has quit [Ping timeout: 480 seconds]
<apinheiro>
and then I mentioned that before that game ported their engine to nvhri, I got it working on the rpi4
<apinheiro>
I didn't test the game in some years
<apinheiro>
for example, before the port to nvhri, the game didn't require tessellation shaders
<KungFuJesus>
ah gotcha, so at some point they injected some nvhri features that prevented the nvhri version from working, but at one point it did
<mairacanal>
KungFuJesus, did you compiled this kernel by yourself?
gouchi has joined #dri-devel
<KungFuJesus>
nope, stock rpi os kernel
<mairacanal>
and also, could you give me the steps to reproduce this issue? it can be in the #videocore room to avoid spamming here
uhaabergen has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<KungFuJesus>
sure
Company has joined #dri-devel
<KungFuJesus>
hmm, can't join that channel without ssl for some reason
<uhaabergen>
I am requesting the clearance of banlist and silent list, just to avoid bad traffic towards me in every day life again and again, and from all the channels, gpu related mintlinux debian and llvm, and favor against is that i do not enter the channels, with more than 50 lines a month of non insulting content , is that agreement fine to you?
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
<uhaabergen>
And the point behind that decision is: There is nothing that irritates my eyes anymore in current state of science or compute science, these things that move or irritate me are in the era of wars but those are not the channels to discuss those. So i lack proper reasons and motivation to troll or insult anyhow or even spend my free time here, cause i haven't got much either.
<uhaabergen>
From time to time i get those underground people coming to me extorting some code or bitcoin solutions and it's fair to say i do just not respect such extertion in response to also excess humiliations and such, cause i only had some ideas, i doubt i am superior to you also btw.
<uhaabergen>
the thing is i chose to deal with respectful and nice behaving people which you wanted not to offer here officially, so this gone i am not making agreements with underground extorting persons at all with a long time strategy already placed there, and it has not gone through any changes or change of plans. But i am not sure if i have all the solutions or am i ill, i tend to think i do have them yes, but it's just common sense if you want
<uhaabergen>
something to work, you gotta behave or pay for the job, at least either one of those, with a terror kind behavior i do not carry out negotiations at all anyways.
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<Ermine>
Who is op here?
<zmike>
sadly still not enough people to be truly effective
junaid has quit [Remote host closed the connection]
<uhaabergen>
IF you want to know about me, i am clearly not someone you think i am, god father or underground boss, i was a player, now i am a bit smaller player, cause i have not got the leg strengths for years in a row, but all my games with fair salary are taped and are official, i do not deal in underground world , it's your field or someones elses, i do not do that.
<uhaabergen>
which is to say, i was never active in the gangster boss and bosses of mob bosses world, even during my lifetimes big 90s conflict, i was then only a table tennis athlete similarly but not yet injured only then .
pcercuei has joined #dri-devel
<uhaabergen>
and estonian nation has nothing to do with me either, i have many friends here, but estonians are not russians either, they are mixed with all other nations today yes, but language is different and bases come from central europe as many times said, europes big migrations, those that originally fought the land here, were some clans of huns likely
uhaabergen was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
davispuh has joined #dri-devel
rasterman has joined #dri-devel
tertl8 has quit [Quit: Connection closed for inactivity]
bolson has joined #dri-devel
kzd has joined #dri-devel
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
gclrdeftu^ has quit [Remote host closed the connection]
<riteo>
what aer you talking about
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
<DemiMarie>
Company: would it be okay if software-rendered dmabufs are pinned system memory and provide an unmap notification? The reason is that I want to be able to export the underlying memory using Xen grant tables.
<Company>
DemiMarie: that's outside of my expertise
<Company>
I'm looking at it from a client perspective
junaid has joined #dri-devel
junaid has quit []
junaid has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
Leopold has quit [Remote host closed the connection]
Leopold has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
cdsefds^ has joined #dri-devel
tomba_ has quit [Ping timeout: 480 seconds]
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
fab has quit [Quit: fab]
cdsefds^ has quit [Remote host closed the connection]
ced117_ has quit [Ping timeout: 480 seconds]
ced117 has joined #dri-devel
junaid has quit [Remote host closed the connection]
gouchi has quit [Remote host closed the connection]
<daniels>
riteo: crashing on enumeration or initialisation is obviously unacceptable, even if it is a driver without suitable hardware present. if you do see that happening please file it and escalate as hard as you can
<daniels>
I don’t believe Mesa ever does it, and if proprietary drivers do then that is certainly fixable - forking to work around it is a joke tbh
<daniels>
(if you need help escalating within NV, just ask here)
sima has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
<riteo>
daniels: I see, thanks a lot for explaining this further; this is precious info and your contact is extremely valuable too :D
<riteo>
I'll let hpvb know, as they're the author of the original forking thing