ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<alyssa> nouveau/codegen seems to handle indirects but honestly I can't tell what it's doing at a glance and that's concerning
<gfxstrand> That's most of nouveau/codegen, TBF.
<alyssa> yeah...
<alyssa> does nvidia have GPRF indirects?
<alyssa> and do you plan to use them in NAK?
<alyssa> if not we can make codegen stop using them to improve NAK-by-comparison ;-P
<alyssa> likewise can't tell what r600/sfn is doing at a glance..
<alyssa> suddenly I'm feeling really good about the midgard compiler
<gfxstrand> lmao
<alyssa> should be straightforward enough to wire in load/store_array to NTT, I understand that backend :p
<alyssa> But, definitely not a doing project
<alyssa> *today
idr has quit [Quit: Leaving]
Kayden has quit [Quit: go home]
<jenatali> gfxstrand: When you get a chance I sent a WSI patch your way earlier this week
<gfxstrand> jenatali: Ok. link?
<jenatali> One sec
<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
co1umbarius has quit [Ping timeout: 480 seconds]
Guest10204 is now known as nchery
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
<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`.
<emersion> kchibisov: ah, not yet merged: https://github.com/KhronosGroup/EGL-Registry/pull/156
godvino has quit [Quit: WeeChat 3.6]
<kchibisov> emersion: thanks.
OftenTimeConsuming has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has joined #dri-devel
thellstrom has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
Haaninjo has joined #dri-devel
jewins has joined #dri-devel
heat has quit [Remote host closed the connection]
yuq825 has left #dri-devel [#dri-devel]
heat has joined #dri-devel
<dj-death> arg
<dj-death> fourth time CI timeout
<dj-death> is it normal for radv-stoney-vkcts to last 1hour ?
<zmike> you're lucky it doesn't take 2
<hakzsam> I don't think it's normal
kzd has joined #dri-devel
srslypascal has quit [Quit: Leaving]
<dj-death> my other question is also why do we build mesa 19 times per pipeline on debian ;)
Duke`` has joined #dri-devel
Zopolis4_ has quit []
ahajda_ has quit []
dsrt^ has quit [Remote host closed the connection]
fxkamd has quit []
godvino has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
lemonzest has joined #dri-devel
rasterman has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
heat has quit [Remote host closed the connection]
bluebugs has quit [Quit: Leaving]
<DavidHeidelberg[m]> dj-death: we like diversity of build
<DavidHeidelberg[m]> Some builds are distributed to the test machines, some tests are build test in different configs
heat has joined #dri-devel
stuarts has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
jaganteki has joined #dri-devel
godvino has quit [Quit: WeeChat 3.6]
gouchi has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
ceoayyyyyyyyyyyy^ has joined #dri-devel
ngcortes has joined #dri-devel
jfalempe has quit [Quit: Leaving]
ngcortes has quit [Ping timeout: 480 seconds]
JohnnyonF has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
Cyrinux9 has quit []
Cyrinux9 has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
ADS_Sr has quit [Ping timeout: 480 seconds]
pa has joined #dri-devel
pa- has quit [Ping timeout: 480 seconds]
bgs has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
djbw_ has joined #dri-devel
ngcortes has joined #dri-devel
Daaanct12 has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Ping timeout: 480 seconds]
heat has quit [Read error: No route to host]
heat has joined #dri-devel
ngcortes_ has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
ngcortes has quit [Ping timeout: 480 seconds]
<alyssa> gfxstrand: To be clear, do you want to torch nir_instr_rewrite_src_ssa or not?
JohnnyonFlame has joined #dri-devel
<gfxstrand> alyssa: IDK
<gfxstrand> alyssa: I'd like to see a parent != NULL check in `nir_src_rewrite_ssa()` either way
<alyssa> Yeah, added that
<alyssa> gfxstrand: mostly want to know if I should drop the patches or not
<alyssa> ideally we can land this MR sooner than later because it's going to be rebase hell and I'm going on NIR holiday soon
<gfxstrand> Yeah
<alyssa> (and if dropping the extra churn means it can go in sooner, happy to, I'm not attached to it I was mostly having fun with Coccinelle)
JohnnyonF has quit [Ping timeout: 480 seconds]
<gfxstrand> There's one unaddressed bug in the first patch still, FYI.
<alyssa> yeah i know
<gfxstrand> (I'd have RBd it otherwise)
<gfxstrand> I think let's break that out into a separate MR for now and try to land the rest.
<gfxstrand> I want to think about it
<alyssa> Sounds good
<alyssa> gfxstrand: Also, where are we at with the nir_foreach_use discussions with anholt?
ngcortes_ has quit [Ping timeout: 480 seconds]
<gfxstrand> alyssa: Given how many other instances there are, I think what you've got is good for now.
<gfxstrand> That one sounds like a pretty big audit.
<gfxstrand> Maybe worthwhile but pretty big
<alyssa> Yeah
<alyssa> gfxstrand: Can I not improve source mods please? ;-p
<alyssa> I've got a ~~plan~~ sketched out hopes & dreams to delete that pass
<gfxstrand> yeah, that's okay
gouchi has quit [Remote host closed the connection]
<alyssa> Said hopes & dreams is to make the actual NIR fully SSA (with load/store_reg intrinsics) and no source mods (fneg/fabs/fsat instructions)
<alyssa> and have helpers that produce nir_alu_src/nir_alu_dest from an SSA def
<alyssa> internally chasing SSA to reconstruct what the alu src/dest would have been back when those data structures were part of NIR
<alyssa> so converting backends is straightforwardish, just call into those helpers when translating NIR
<alyssa> since they return the data structure that would otherwise be read directly, this doesn't require plumbing anything through more deeply
<alyssa> (very much a surface level translation for the older backends)
<gfxstrand> I like this possible future. I hope we can get there.
<alyssa> Me too
<alyssa> so that's the backend half
<alyssa> the frontend and NIR core part is a different story
<alyssa> we're using nir_register for a lot of weird shit, apparently
<alyssa> IDK what happens with lower_phis_to_regs, for example
<alyssa> unless it just also turns into intrinsics and that's fine
<alyssa> ngl it would also be nice to torch swizzles but that's an even bigger thing
<alyssa> but I do wonder if opt_algebraic in particular would be sped up by not worrying about swizzles
<alyssa> ok, addressed all the review feedback (some of it punted on)
<alyssa> asahi still seems ok, let's see what CI thinks
<alyssa> anyone want bets on whose drivers I broke? :D
<alyssa> crap, pushed the version with the asahi uapi in there... meh, shouldn't affect CI results
<gfxstrand> Anything we do during optimization can use intrinsics or whatever
<gfxstrand> There's no need for actual register sources for that stuff
<alyssa> right, but I want to rid the IR of register sources entirely
<alyssa> i.e. drop the is_ssa bool from nir_src and make it just an ssa def and a use chain
<gfxstrand> Yes
<gfxstrand> alyssa: Did you mean to push an asahi patch on top?
<gfxstrand> alyssa: Also, why are most of those patches not linking to your gitlab profile?
<alyssa> 1. no
<alyssa> 22:13 < alyssa> crap, pushed the version with the asahi uapi in there... meh, shouldn't affect CI results
<alyssa> 2. I unlinked my gitlab profile from my @collabora.com email
<alyssa> 22:12 < alyssa> anyone want bets on whose drivers I broke? :D
<alyssa> DXIL this time
<alyssa> take 2
<gfxstrand> alyssa: 2) Why? Mine's still linked with Intel. (-:
<alyssa> 🙃
MajorBiscuit has quit [Ping timeout: 480 seconds]
<HdkR> 23.1 branch is next Wednesday right?
<HdkR> No delays or anything currently? :)
<HdkR> Looks like there is nothing tagged as a release blocker yet in the milestone at least
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
rszwicht has quit [Ping timeout: 480 seconds]
ceoayyyyyyyyyyyy^ has quit [Remote host closed the connection]
heat has quit [Read error: No route to host]
heat_ has joined #dri-devel
anujp has joined #dri-devel