<jenatali>
The last missing piece to get DOOM Eternal working
<gfxstrand>
jenatali: Oh, well that's gnarly
<jenatali>
Yep
<jenatali>
The app leaks surfaces and recreates them when you alt+tab
<jenatali>
I'm open to other suggestions if this approach is a nak but we'll need something along these lines
yuq825 has joined #dri-devel
cdoay^ has joined #dri-devel
<robclark>
alyssa: yeah, we have indirect const and gpr which can (usually) be folded directly into alu instructions.. tho maybe we could treat indirects as special kinda of ssa src instruction, idk
columbarius has joined #dri-devel
<robclark>
I guess in theory in the nir->ir3 pass they could just be mov's w/ indirect src and then let the ir3 cp pass gobble them up.. but I guess there is enough shader db to know if anything regressed
<alyssa>
robclark: I don't have a coherent plan yet
<alyssa>
but, ir3 is not the backend I'm worried about, because I actually understand ir3 :-p
<alyssa>
it's the mix of C++ and vec4 that gets me ;)
ngcortes has quit [Read error: Connection reset by peer]
heat has quit [Read error: No route to host]
heat has joined #dri-devel
cdoay^ has quit [Remote host closed the connection]
Zopolis4_ has quit []
Company has quit [Quit: Leaving]
karolherbst_ has joined #dri-devel
karolherbst has quit [Ping timeout: 480 seconds]
<mareko>
trying to figure out how move uniform blocks from one NIR shader to another...
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
Haaninjo has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
loki_val has joined #dri-devel
crabbedhaloablut has quit [Read error: Connection reset by peer]
jewins has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
jewins has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
cheako has quit [Quit: Connection closed for inactivity]
YuGiOhJCJ has joined #dri-devel
danvet has joined #dri-devel
bmodem has joined #dri-devel
dsrt^ has joined #dri-devel
jewins has quit [Read error: Connection reset by peer]
fab has joined #dri-devel
srslypascal is now known as Guest10246
srslypascal has joined #dri-devel
Guest10246 has quit [Ping timeout: 480 seconds]
ahajda has joined #dri-devel
rcf has quit [Ping timeout: 480 seconds]
Kayden has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
jdavies has joined #dri-devel
jdavies is now known as Guest10248
rszwicht has joined #dri-devel
ahajda_ has joined #dri-devel
fab has joined #dri-devel
fab has quit []
Guest10248 has quit [Ping timeout: 480 seconds]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
ahajda has quit [Ping timeout: 480 seconds]
rcf has joined #dri-devel
jkrzyszt has joined #dri-devel
ahajda_ has quit [Read error: Connection reset by peer]
ahajda_ has joined #dri-devel
loki_val has quit []
crabbedhaloablut has joined #dri-devel
bgs has joined #dri-devel
fab has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
<lina>
I think I give up on drm_sched... I just ran into another UAF...
<lina>
Christian is right, this design assumes the scheduler outlives everything else.
<lina>
Unfortunately it even has random asynchronous cleanup code
<lina>
So really I don't see how I can use this in a one-scheduler-per-queue model without just keeping references to every submitted job fence and waiting on everything before freeing the scheduler.
<lina>
And this is impossible to safely abstractin Rust
rasterman has joined #dri-devel
<lina>
Actually fences aren't enough, since those get signaled before the job gets freed, and that's too early.
djbw_ has quit [Read error: Connection reset by peer]
kxkamil has quit []
JohnnyonFlame has quit [Read error: Connection reset by peer]
junaid has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
fab has quit [Quit: fab]
MajorBiscuit has joined #dri-devel
<kchibisov>
Am I correct that mesa update is required to silence new `warnings` from mesa in wayland log? Should you call `eglTerminate` to not ever see them in your project or something less involved like dropping context will work just fine?
<kchibisov>
New warnings as in "from 1.22" bump about proxies being alive.
godvino has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<emersion>
kchibisov: these have been fixed but yeah maybe not released
<kchibisov>
emersion: do I need eglTerminate() for that?
<emersion>
not sure
<kchibisov>
I hope not.
Company has joined #dri-devel
<kchibisov>
Hm, from what I understand the issue is purely to the drop order of the mesa internal queue, so as long as mesa sanely drops stuff attached to its own queue I won't see an issue. It's not like I have to explicitly `eglTerminate` or force mesa to dropping the wayland queue when I've closed the main queue in my application, right?
<emersion>
i think you get warnings when a non-default queue is destroyed
<emersion>
maybe the mesa queue is not destroyed if you don't eglTerminate
<emersion>
why do you want not to call eglTerminate out of curiosity?
<kchibisov>
You can't do that as a library inside your destructor.
<emersion>
because it might bring down other EGL contexts?
<kchibisov>
EGLDisplay is sort of reference to the global singleton, the Display in the spec is not refcounted, and given that you have behavior like "pass the same args to eglCreateDisplay"(can spell it wrong) you have no safe control over it.
<kchibisov>
pass same args, get the same display behavior.
<emersion>
kchibisov: there is an ext to refcount the EGLDisplay
<emersion>
and also another one to guarantee that a fresh EGLDisplay is returned, iirc
<kchibisov>
But you'll have 3 different path in your library handling all of them.
<emersion>
for wlroots we turn it on and then prey
<emersion>
iirc
<kchibisov>
Yeah, given that wlroots is mesa only you're fine.
<kchibisov>
yet, glutin(lib I'm maintaining) works on all possible platforms.
<emersion>
i think it's not that bad to use the ext
<emersion>
if (ext) eglTerminate();
<emersion>
basically
<kchibisov>
I mean, I'll likely add it.
<emersion>
and continue leaking the stuff if the ext is missing
<kchibisov>
Given that you've enlightened, that there's an extension.
<emersion>
a bit annoyng that there are two specs for the same purpose that said
<kchibisov>
emersion: I mean, it's not like we're leaking, you can call the function yourself.
<emersion>
well
<kchibisov>
it's just "manual resource management".
<emersion>
if a lib allocates an EGLDisplay, i'd expect the lib to clean it up properly
<emersion>
just like the rest of the resources
<emersion>
but yeah, it's not that of a big deal
<kchibisov>
Yeah, that's true, it's just EGLDisplay is a reference.
<kchibisov>
Unless you're using extensions.
<kchibisov>
From a semantic speaking with default EGL, library isn't owning the EGLDisplay.
Zopolis4_ has joined #dri-devel
<kchibisov>
Thanks for mentioning the extension, our original research wrt calling/not calling was around that extensions was created, so it sort of missed.
heat has joined #dri-devel
junaid has quit [Remote host closed the connection]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<kchibisov>
If you happen to know how the other extension is named "About getting a new display for each eglGetPlatformDisplayEXT" I'd like to know it as well.
<kchibisov>
The refcounting one I've found, given that it obviously named in the `EGL-Registry`.