00:04 fdobridge: <g​fxstrand> How's this:
00:04 fdobridge: <g​fxstrand> > NVK bugs can be filed in the [Mesa issue tracker]. However, right now there
00:04 fdobridge: <g​fxstrand> > are enough missing features and known issues that a lot of apps won't work
00:04 fdobridge: <g​fxstrand> > and we already know that. Please don't file "XYZ game doesn't play" issues
00:04 fdobridge: <g​fxstrand> > just yet. If there is a specific feature you know is missing or if you are
00:04 fdobridge: <g​fxstrand> > sure you've found an actual driver bug, then an issue is appropriate. We
00:04 fdobridge: <g​fxstrand> > have way more excited users than developers working on the driver so we
00:04 fdobridge: <g​fxstrand> > don't want to flood the issue tracker.
00:04 fdobridge: <g​fxstrand> >
00:04 fdobridge: <g​fxstrand> > If you do think you've found a legitimate bug, please provide as much
00:04 fdobridge: <g​fxstrand> > information as possible in the report. Mesa git SHA, kernel version, and
00:04 fdobridge: <g​fxstrand> > GPU information are all a must. If you didn't build Mesa yourself, please
00:04 fdobridge: <g​fxstrand> > tell us where you got your build. If you have any hack patches or had to
00:04 fdobridge: <g​fxstrand> > force-enable anything to get the app to work, provide that information as
00:04 fdobridge: <g​fxstrand> > well.
00:04 fdobridge: <g​fxstrand> >
00:04 fdobridge: <g​fxstrand> > Also, be patient. This is a very new driver. We aim to eventually get to
00:04 fdobridge: <g​fxstrand> > the point where most apps work but it will take time. We also need to
00:04 fdobridge: <g​fxstrand> > prioritize our work and do things in the order that makes sense so don't be
00:04 fdobridge: <g​fxstrand> > surprised if your favorite feature doesn't get implemented as quickly as
00:04 fdobridge: <g​fxstrand> > some other.
00:06 fdobridge: <a​irlied> sounds good
00:06 fdobridge: <k​arolherbst🐧🦀> yep
00:07 fdobridge: <k​arolherbst🐧🦀> ack by me
00:30 fdobridge: <g​fxstrand> I think we're about ready. I just need to do a couple things once it the kernel patches hit drm-misc-next and then we're ready to hand off to Marge. 🎉
00:30 fdobridge: <g​fxstrand> I'm going to go figure out some supper and try to relax for the rest of my evening.
00:31 fdobridge: <g​fxstrand> @karolherbst , you should probably go to bed. 😛
00:31 fdobridge: <g​fxstrand> Tomorrow's gonna be a big day. 🤩
00:31 fdobridge: <k​arolherbst🐧🦀> mhhhh
00:43 airlied: depends if dakr shows up :)
00:43 airlied: I don't think I have drm-misc-next commit abilities
01:06 fdobridge: <p​rop_energy_ball> I'm hype
01:06 fdobridge: <p​rop_energy_ball> I have a spare NV card I normally use for Windows passthru
01:06 fdobridge: <p​rop_energy_ball> Might give some stuff a go when I see it on drm-next :)
01:57 fdobridge: <g​fxstrand> I thought you had commit rights for everything. 😂
01:59 fdobridge: <a​irlied> Seemed easier to maintain clear lines of responsibility I stayed out of the way 🙂
02:01 fdobridge: <k​arolherbst🐧🦀> worst case I can push thoes changes
02:08 fdobridge: <g​fxstrand> It also wouldn't kill us to delay until Monday. 😅 It'd give Kara more time to edit my blog post.
05:25 sravn: gfxstrand: An faq entry describing the current status for zink support would be nice
06:03 airlied: I think we'd want to merge 240, then we have at least suboptimal gl4.5
06:41 fdobridge: <g​fxstrand> Has anyone tried running any CTS or piglit on Zink or are we all going off the list in the issue?
06:42 fdobridge: <a​irlied> I tried a piglit run, but I didn't survive
06:42 fdobridge: <a​irlied> I mostly tried glxinfo to see it said GL 4.5 🙂
06:43 fdobridge: <a​irlied> and I ran heaven for a few seconds
08:25 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> You should try gamescope (you need to advertise Vulkan 1.2) but it also requires host-visible VRAM from what I could tell
10:15 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> https://gitlab.freedesktop.org/nouveau/mesa/-/issues/77 :nope_gears:
10:30 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I wonder if we could get Forza Horizon 5 working in 2 years :triangle_nvk:🏎️
11:09 fdobridge: <e​sdrastarsis> Or RE4 Remake
12:11 fdobridge: <g​fxstrand> If Zink doesn't actually work, I'm inclined not to include it in the FAQ and leave it in the "random apps may not work" category.
12:28 fdobridge: <g​fxstrand> Most of that stuff falls under the "we need a new compiler" category. A lot of features will more or less fall into place once I get back to finishing up NAK.
12:28 fdobridge: <g​fxstrand>
12:28 fdobridge: <g​fxstrand> There's also sparse residency which shouldn't be too hard now that we have the new UAPI. We just need to add a few NAK helpers and wire it up. I do think we may want to come up with better internal interfaces for that stuff, though. Right now, we're leaking internal `nvk_image` details into the back-end queue code.
12:28 fdobridge: <g​fxstrand>
12:28 fdobridge: <g​fxstrand> And then there's ray-tracing... I'm not even going to think about that for quite a while. 😅
12:40 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I wonder if Bas could help build the new slowest ray-tracing implementation
12:47 fdobridge: <m​ohamexiety> I wonder how Ray tracing will work, actually
12:48 fdobridge: <m​ohamexiety> For AMD it's regular compute shaders. On NV there's dedicated units and so on and NV is actually really tight lipped about these 😮
12:48 fdobridge: <m​ohamexiety> I wonder how ray tracing will work, actually (edited)
12:52 fdobridge: <g​fxstrand> I'm sure we can crack it wide open. I have a half decent idea what shape I expect it to take already, based on my combined Intel/Nvidia experience. Precious few details, though.
12:58 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Software vs hardware raytracing 🐸
12:59 fdobridge: <g​fxstrand> I mean... It's all software at some level. Even the hardware ray-tracing has a lot of software work involved.
12:59 fdobridge: <k​arolherbst🐧🦀> I think raytracing uses its own class
13:00 fdobridge: <k​arolherbst🐧🦀> and we have no docs on those 🙂
13:00 fdobridge: <k​arolherbst🐧🦀> could ask Nvidia and see if we can wiggle it
13:00 fdobridge: <g​fxstrand> Unless NVIDIA just baked it all into the hardware like they've done with other stuff.
13:00 fdobridge: <k​arolherbst🐧🦀> now that we have a vulkan driver it's fairly reasonable to ask for it
13:00 fdobridge: <k​arolherbst🐧🦀> ohhh, I'm sure it's like the other stuff
13:01 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Or you can do the nouveau way and REnouveau it :nouveau:
13:01 fdobridge: <g​fxstrand> Well, "class"... RT is basically stateless. They could give us the class header and it would tell us almost nothing.
13:01 fdobridge: <k​arolherbst🐧🦀> well.. at least on how to execute them
13:02 fdobridge: <g​fxstrand> Sure. But that's like the easiest thing to RE.
13:02 fdobridge: <k​arolherbst🐧🦀> yeah...
13:02 fdobridge: <k​arolherbst🐧🦀> just mostly don't want to use our own headers for things 😄
13:03 fdobridge: <g​fxstrand> Sure
13:03 fdobridge: <g​fxstrand> No arguments there.
13:05 fdobridge: <k​arolherbst🐧🦀> it's kinda wonky that even with all the docs I have, nothing even mentions raytracing
13:06 fdobridge: <k​arolherbst🐧🦀> I'll try to bring it up on the next meeting with nvidia and see how the vibes are
13:06 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> For now we could do software raytracing :triangle_nvk:
13:09 fdobridge: <k​arolherbst🐧🦀> ` Like Turing, the second-generation RT Core in GA10x includes dedicated hardware units for BVH traversal and ray-triangle intersection testing`
13:09 fdobridge: <k​arolherbst🐧🦀> ` Once the SM has cast the ray, the RT Core will perform all of the calculations needed for BVH traversal and triangle intersection tests, and will return a hit or no hit to the SM.`
13:10 fdobridge: <k​arolherbst🐧🦀> ohh winky
13:10 fdobridge: <k​arolherbst🐧🦀> *wonky
13:10 fdobridge: <g​fxstrand> Sounds like Intel
13:10 fdobridge: <k​arolherbst🐧🦀> ` The GA10x SM can process two compute workloads simultaneously, and is not limited to just compute and graphics simultaneously as in prior GPU generations, allowing scenarios such as a compute-based denoising algorithm to run concurrently with RT Core-based ray tracing work.`
13:11 fdobridge: <k​arolherbst🐧🦀> but yeah... seems like we just program the RT cores and eat the result
13:12 fdobridge: <k​arolherbst🐧🦀> https://www.nvidia.com/content/PDF/nvidia-ampere-ga-102-gpu-architecture-whitepaper-v2.pdf
13:12 fdobridge: <g​fxstrand> Well, actually, I expect it to be like Intel but with more automagic around stack management and call/return/resume.
13:12 fdobridge: <g​fxstrand> But I need to see some IR first.
13:13 fdobridge: <k​arolherbst🐧🦀> the thing is.. I see nothing for ray tracing in the ISA docs I have
13:14 fdobridge: <k​arolherbst🐧🦀> but as far as stack management goes
13:14 fdobridge: <k​arolherbst🐧🦀> there is no stack anymore
13:15 fdobridge: <k​arolherbst🐧🦀> you even have to save the return address yourself and everything
13:15 fdobridge: <m​ohamexiety> that's in general? or RT only? 😮
13:16 fdobridge: <k​arolherbst🐧🦀> in general
13:16 fdobridge: <k​arolherbst🐧🦀> they got rid of the stack in volta
13:17 fdobridge: <m​ohamexiety> that's interesting
13:18 fdobridge: <k​arolherbst🐧🦀> well.. the stack was a pain to deal with anyway
13:18 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> So is there only the heap and registers?
13:18 fdobridge: <k​arolherbst🐧🦀> yeah, but you have special "barrier" registers for thread mask management and other wonky stuff
13:19 fdobridge: <k​arolherbst🐧🦀> forcing the thread group to run in quad mode is also all explicit. You safe the old mask, do your quad stuff and restore the mask
13:21 fdobridge: <g​fxstrand> "stack" was maybe the wrong term. What I mean is that I expect local mem to "just work". This is as opposed to Intel where you get a thread ID which you have to track and then spilling is all manual via global mem.
13:22 fdobridge: <k​arolherbst🐧🦀> ahhh
13:22 fdobridge: <g​fxstrand> Sure, you might have to save and restore stuff but I expect you don't have to juggle thread IDs or anything dumb like that.
13:23 fdobridge: <k​arolherbst🐧🦀> ahh right, yeah, that's probably not as painful on nvidia
13:24 fdobridge: <k​arolherbst🐧🦀> some hardware is really wonky on that ID stuff.. even AMD is weird
13:24 fdobridge: <k​arolherbst🐧🦀> when trying to implement non uniform work group, I got told that AMD hardware doesn't know how big their blocks are 🙃
13:24 fdobridge: <k​arolherbst🐧🦀> why make everything so painful
13:25 fdobridge: <k​arolherbst🐧🦀> nvidia has sys vals for a bunch of random stuff, launched threads, active threads, ID on all the levels, etc...
13:26 fdobridge: <k​arolherbst🐧🦀> uhhhhhhhhhhh
13:26 fdobridge: <k​arolherbst🐧🦀> trying to debug some stupid nv50 regression, and it's sending commands to the hardware which the gl driver 100% doesn't send 🙃 or maybe gdb is just silly to me today
14:13 fdobridge: <g​eorgeouzou> what about the bvh building? Is this done with normal compute shaders?
14:42 fdobridge: <k​arolherbst🐧🦀> wouldn't be surprising if that's done in compute
14:46 fdobridge: <g​fxstrand> That's done in compute shaders.
14:48 fdobridge:<g​fxstrand> is watching drm-misc and being disappointed. 🙃
14:52 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> i think there should be a proper error message when trying to run the new uAPI NVK on old uAPI kernel :nouveau:
14:53 fdobridge: <e​sdrastarsis> Will nouveau gallium be dropped when Zink is working on NVK?
14:54 fdobridge: <g​fxstrand> Maybe? 🤷🏻‍♀️ That's all still TBD. We need to see how well it works, first. Nouveau gallium will be the plan for pre-kepler probably forever, though.
14:55 fdobridge: <g​fxstrand> I can try to cook one up. Unfortunately, that's actually kind of annoying to do properly due to how things are initialized and by whom and in what order.
14:56 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Inb4 Triang3l decides to learn old NVIDIA hardware and make Fermikan 😅
14:56 fdobridge: <g​fxstrand> Actually... I've got an idea for a plan.
14:57 fdobridge: <g​fxstrand> It'll just take a bit of re-arranging.
14:57 fdobridge: <e​sdrastarsis> I see
15:00 fdobridge: <g​fxstrand> The paradox of Zink is that, gallium is good enough at this point that, if you build your Vulkan driver right (which I have) then, by the time you have a competent Vulkan feature set, you can build a gallium driver by re-using bits of the Vulkan driver for a fraction of the cost of building a whole gallium driver from scratch.
15:00 fdobridge: <k​arolherbst🐧🦀> yeah...
15:01 fdobridge: <g​fxstrand> Zink is a paradox of sorts. Gallium is good enough at this point that, if you build your Vulkan driver right (which I have) then, by the time you have a competent Vulkan feature set, you can build a gallium driver by re-using bits of the Vulkan driver for a fraction of the cost of building a whole gallium driver from scratch. This means that, while Zink looks like it saves you a pile of work, it doesn't really. (edited)
15:01 fdobridge: <k​arolherbst🐧🦀> moving some of the state emission into common code shouldn't be all too painful (and use it from both even). The pain points with gl drivers is mostly that you are fighting with gallium, the CTS and the hardware at once 🙃
15:02 fdobridge: <g​fxstrand> Reusing state emission isn't important.
15:02 fdobridge: <g​fxstrand> Not as long as you do it reasonably competently.
15:03 fdobridge: <k​arolherbst🐧🦀> yeah, fair, my point is rather, in vulkan you don't have to deal with an abstraction layer and can focus on the hardware bits, and once you understand the hardware, writing a gallium driver let's you focus on the gallium bits
15:03 fdobridge: <g​fxstrand> The problem with nouveau GL isn't that it's a gallium driver and not a Vulkan driver. It's that it's a crufty pile of 💩.
15:03 fdobridge: <k​arolherbst🐧🦀> it's just kinda sad, that people still start with GL these days
15:03 fdobridge: <k​arolherbst🐧🦀> 😄
15:03 fdobridge: <k​arolherbst🐧🦀> yeah, fair
15:03 fdobridge: <g​fxstrand> And I mean that it the best possible way. 🙃
15:03 fdobridge: <k​arolherbst🐧🦀> I wonder how much of that is due to how gallium was 15 years ago
15:03 fdobridge: <k​arolherbst🐧🦀> or well.. 10
15:03 fdobridge: <k​arolherbst🐧🦀> or 15?
15:03 fdobridge: <k​arolherbst🐧🦀> it's been long
15:04 fdobridge: <g​fxstrand> Probably quite a bit
15:04 fdobridge: <k​arolherbst🐧🦀> and also understanding of the hardware wasn't the best
15:04 fdobridge: <k​arolherbst🐧🦀> for fun reasons, nvc0 is kinda the main driver and nv50 was a copy of that
15:04 fdobridge: <k​arolherbst🐧🦀> and nv50 is still terrible in a few places
15:04 fdobridge: <g​fxstrand> There are many ways for a code bade to become 💩 that don't involve it being designed poorly at the start.
15:04 fdobridge: <g​fxstrand> There are many ways for a code base to become 💩 that don't involve it being designed poorly at the start. (edited)
15:05 fdobridge: <e​sdrastarsis> What's funny is that the gallium driver is faster than NVK for some reason, but I haven't tested it with the new uAPI
15:05 fdobridge: <k​arolherbst🐧🦀> anyway.. a new driver would be better
15:05 fdobridge: <k​arolherbst🐧🦀> the gallium driver also doesn't use global mem for ubos 😄
15:05 fdobridge: <k​arolherbst🐧🦀> ubos are one reason why stuff is fast on nvidia hardware
15:05 fdobridge: <k​arolherbst🐧🦀> ubos are... _fast_
15:05 fdobridge: <g​fxstrand> Most code bases tend towards 💩 over time unless great care and effort are put into preventing the 💩ification.
15:06 fdobridge: <g​fxstrand> Oh, that's because we don't use real uniforms yet.
15:06 fdobridge: <g​fxstrand> Jinx
15:06 fdobridge: <k​arolherbst🐧🦀> yeah.. I'm sure using ubos will speed up things by x3 at least 😛
15:06 fdobridge: <k​arolherbst🐧🦀> ohhh
15:06 fdobridge: <k​arolherbst🐧🦀> you can even test it in gl
15:07 fdobridge: <k​arolherbst🐧🦀> we have code to spill ubos, might want to spill all of them.. though it might be compute only stuff
15:07 fdobridge: <k​arolherbst🐧🦀> mhhh
15:07 fdobridge: <k​arolherbst🐧🦀> it's a bit weird, but compute only has 8 slots...
15:07 fdobridge: <k​arolherbst🐧🦀> and two are used for uniforms and driver stuff
15:08 fdobridge: <k​arolherbst🐧🦀> sooo.. advertizing 8 isn't as trivial as one would hope
15:09 fdobridge: <k​arolherbst🐧🦀> gl requires 8 per stage, no idea what vulkan requires, if it requires anything at all for ubos
15:09 fdobridge: <g​fxstrand> We'll get there in time. Annoyingly, though, proper UBO support is also blocked on NVK. Sure, I could do something that works with legacy bound UBOs and we probably should eventually for Pascal and earlier but we really want bindless and that's not something codegen is likely to ever support.
15:10 fdobridge: <g​fxstrand> We'll get there in time. Annoyingly, though, proper UBO support is also blocked on NAK. Sure, I could do something that works with legacy bound UBOs and we probably should eventually for Pascal and earlier but we really want bindless and that's not something codegen is likely to ever support. (edited)
15:11 fdobridge: <k​arolherbst🐧🦀> yeah.. it would be quite a mess to add in codegen
15:11 fdobridge: <k​arolherbst🐧🦀> though...
15:11 fdobridge: <k​arolherbst🐧🦀> shouldn't be too hard
15:11 fdobridge: <k​arolherbst🐧🦀> just add a `.bindless` flag like we did for textures 🙃
15:11 fdobridge: <k​arolherbst🐧🦀> on `Symbol`
15:12 fdobridge: <k​arolherbst🐧🦀> and then the indirect isn't an indirect index, but the ubo address
15:12 fdobridge: <k​arolherbst🐧🦀> at least I think that would be the least painful way inside codegen
15:12 fdobridge: <g​fxstrand> You need uniform register support
15:12 fdobridge: <k​arolherbst🐧🦀> mhhhhhhhhh....
15:12 fdobridge: <k​arolherbst🐧🦀> I forgot about that
15:13 fdobridge: <g​fxstrand> Yeah...
15:13 fdobridge: <g​fxstrand> That's why NAK doesn't have them yet.
15:13 fdobridge: <g​fxstrand> I need to get spilling sorted first then UGPRs then bindless UBOs.
15:13 fdobridge: <k​arolherbst🐧🦀> though I don't think bindless ubos are special compared to bound ones, I think the initial data uploading just happens later. I actually wonder if bindless ubos share the remaining free slots and what happens if you need more than that
15:14 fdobridge: <g​fxstrand> AFAICT, bindless UBOs are pure magic
15:14 fdobridge: <k​arolherbst🐧🦀> they might also just have a page cache and unload accessed pages
15:14 fdobridge: <k​arolherbst🐧🦀> *upload
15:14 fdobridge: <g​fxstrand> I think so
15:14 fdobridge: <k​arolherbst🐧🦀> should be easy to figure out
15:15 fdobridge: <k​arolherbst🐧🦀> just need some proper profiling
15:15 fdobridge: <g​fxstrand> I don't think there's any state associated with them. That's why they're bindless. 🙃
15:15 fdobridge: <k​arolherbst🐧🦀> though uploading the entire ubo would be simple
15:15 fdobridge: <k​arolherbst🐧🦀> you have the size in the address
15:15 fdobridge: <k​arolherbst🐧🦀> and the hardware could just map it
15:16 fdobridge: <k​arolherbst🐧🦀> and they just use unused ubo slots
15:16 fdobridge: <k​arolherbst🐧🦀> "lazy binding" might be a proper term here? 😄
15:17 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Just like cats?
15:17 fdobridge: <k​arolherbst🐧🦀> faster
15:17 fdobridge: <k​arolherbst🐧🦀> ubos on nvidia have gpr access speed
15:17 fdobridge: <e​sdrastarsis> gpr?
15:17 fdobridge: <k​arolherbst🐧🦀> registers
15:17 fdobridge: <k​arolherbst🐧🦀> using ubos can even be faster than registers
15:18 fdobridge: <k​arolherbst🐧🦀> for instance, if an instruction can't take a full 32 bit immediate value, you'd have to move it into a register first
15:18 fdobridge: <k​arolherbst🐧🦀> with an ubo, you can just extract such constants and have a constant ubo you use instead
15:18 fdobridge: <k​arolherbst🐧🦀> so you even kill the mov and are faster
15:18 fdobridge: <k​arolherbst🐧🦀> (and you might use less registers)
15:18 fdobridge: <g​eorgeouzou> Are they using the same memory as shared compute memory?
15:19 fdobridge: <k​arolherbst🐧🦀> no
15:19 fdobridge: <k​arolherbst🐧🦀> shared memory is L2 cache
15:19 fdobridge: <k​arolherbst🐧🦀> and slower
15:19 fdobridge: <g​eorgeouzou> Oh this is even faster then
15:19 fdobridge: <k​arolherbst🐧🦀> well.. as I said: UBOs are as fast as registers
15:19 fdobridge: <k​arolherbst🐧🦀> they have blocks for ubos and you prefill them with data before draw
15:20 fdobridge: <k​arolherbst🐧🦀> sure, you still have the memory access, but you only have to do it once
15:20 fdobridge: <g​eorgeouzou> If the data in the ubo is large they only load the data that is used by the shader?
15:20 fdobridge: <k​arolherbst🐧🦀> no, you upload the entire thing
15:20 fdobridge: <g​eorgeouzou> Because I think they have like a 64kb limit
15:20 fdobridge: <k​arolherbst🐧🦀> yeah
15:21 fdobridge: <k​arolherbst🐧🦀> it's 64k
15:21 fdobridge: <k​arolherbst🐧🦀> and you have 18 slots on modern hardware
15:21 fdobridge: <k​arolherbst🐧🦀> you also have a register file of 64k 🙃
15:21 dakr: airlied, gfxstrand: Just read your messages, I will fix up the SPDX and copyright stuff. I can also apply the series together with your uAPI fixup patch to drm-misc-next. However, I wonder if we want this to go through drm-misc?
15:21 fdobridge: <k​arolherbst🐧🦀> ohh wait.. the register file is 256k
15:21 fdobridge: <k​arolherbst🐧🦀> 64k * 4
15:23 fdobridge: <g​eorgeouzou> If one has multiple ubos that all together are above 64k ? Some spill to global memory right?
15:23 fdobridge: <g​eorgeouzou> I mean bound to the 18 slots
15:23 fdobridge: <k​arolherbst🐧🦀> all 18 exist in hardware, yes
15:24 fdobridge: <k​arolherbst🐧🦀> compute only has 8 for unknown reasons
15:24 fdobridge: <g​eorgeouzou> Hmm
15:26 fdobridge: <k​arolherbst🐧🦀> sadly none of the nvidia whitepapers talk in detail about bindless ubos 😢
15:27 fdobridge: <k​arolherbst🐧🦀> but uhm... I got told that one of my guesses isn't wrong
15:42 fdobridge: <k​arolherbst🐧🦀> @mhenning if you got some time, mind reviewing https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23724 ?
15:48 fdobridge: <k​arolherbst🐧🦀> pain... ubuntu "LTS" 22.04 updates from LTS 5.15 to EoL 6.2... :painpeko:
15:54 gfxstrand: dakr: Where else would it go?
15:54 gfxstrand: dakr: Genuine question. I don't actually know. (-:
15:56 gfxstrand: I just believe airlied when he says branch names. 😂
16:09 dakr: Dunno, the MAINTAINERS file mentions https://gitlab.freedesktop.org/drm/nouveau.git, sometimes Dave also pulls directly from Bens tree...
16:11 gfxstrand: I don't know either and Dave won't be around for a while (if at all today) :-/
16:11 dakr: I mean, he clearly stated drm-misc above.. :D
16:11 gfxstrand: :D
16:15 karolherbst: yeah.. whatever. drm-misc or the nouveau tree or something. We can use the nouveau tree, but then it needs to be a proper pull request and uhhh.. it's kinda annoying. The hope was ti use gitlab with CI and everything, but generally it's more work than just pushing through drm-misc directly
16:27 dakr: So drm-misc it is. :)
16:28 karolherbst: yep
17:10 fdobridge: <g​fxstrand> It's kinda horrible and I kinda hate it but I think this works: https://gitlab.freedesktop.org/nouveau/mesa/-/merge_requests/253
17:12 fdobridge: <g​fxstrand> It's kinda horrible and I kinda hate it but I think this works: https://gitlab.freedesktop.org/nouveau/mesa/-/merge_requests/25 (edited)
17:12 fdobridge: <g​fxstrand> It's kinda horrible and I kinda hate it but I think this works: https://gitlab.freedesktop.org/nouveau/mesa/-/merge_requests/253 (edited)
17:47 fdobridge: <k​arolherbst🐧🦀> yeah, I think that's the proper way of doing so
17:47 fdobridge: <k​arolherbst🐧🦀> those version numbers are alwyas kinda wonky
17:50 fdobridge: <g​fxstrand> Yeah, checking if `VM_INIT` succeeds seems like it should be reliable.
17:50 fdobridge: <g​fxstrand> I just don't like how intertwined everything is inside the winsys but part of that is because it's all intertwined inside the kernel APIs.
17:51 fdobridge: <k​arolherbst🐧🦀> yeah...
17:52 fdobridge: <g​fxstrand> One day, I may decide I care enough to detangle it all
17:52 fdobridge: <g​fxstrand> Today is not that day
17:52 fdobridge: <k​arolherbst🐧🦀> mhhh... on the kernel side?
17:52 fdobridge: <g​fxstrand> userspace could be less tangled, too.
17:52 fdobridge: <k​arolherbst🐧🦀> where specifically though?
17:52 fdobridge: <g​fxstrand> I started trying to but bo_create was being more magical than needed and that was going to make it a pain
17:53 fdobridge: <k​arolherbst🐧🦀> ahh
17:53 fdobridge: <g​fxstrand> What we really want is a `nv_device_info_init(drmDevicePtr device);` and then drop the info from `nouveau_device`. It becomes a VM manager and BO cache and not much else.
17:54 fdobridge: <g​fxstrand> What we really want is a `nv_device_info_init(drmDevicePtr device, struct nv_device_info *info);` and then drop the info from `nouveau_device`. It becomes a VM manager and BO cache and not much else. (edited)
17:54 fdobridge: <k​arolherbst🐧🦀> yeah.. that's probably a good idea
17:54 fdobridge: <g​fxstrand> It can all be done and I've got a rough plan. I just hit `-ENOSPOONS`
18:02 fdobridge: <g​fxstrand> Seems to work. I'm gonna merge it.
18:05 fdobridge: <m​ohamexiety> did something change with how we handle initialization in a recent commit? pulled latest `nvk/main` and now I can't run
18:05 fdobridge: <m​ohamexiety>
18:05 fdobridge: <m​ohamexiety> ```
18:06 fdobridge: <m​ohamexiety> [mesa] [mohamed@fedora build]$ export NVK_I_WANT_A_BROKEN_VULKAN_DRIVER=1
18:06 fdobridge: <m​ohamexiety> [mesa] [mohamed@fedora build]$ vulkaninfo
18:06 fdobridge: <m​ohamexiety> WARNING: [Loader Message] Code 0 : loader_scanned_icd_add: Driver /home/mohamed/dev/mesa-dev/mesa/build/src/nouveau/vulkan/libvulkan_nouveau.so supports Vulkan 1.3, but only supports loader interface version 4. Interface version 5 or newer required to support this version of Vulkan (Policy #LDP_DRIVER_7)
18:06 fdobridge: <m​ohamexiety> MESA: error: ../src/nouveau/vulkan/nvk_physical_device.c:679: VK_ERROR_INCOMPATIBLE_DRIVER
18:06 fdobridge: <m​ohamexiety> ERROR: [../src/nouveau/vulkan/nvk_physical_device.c:679] Code 0 : VK_ERROR_INCOMPATIBLE_DRIVER
18:06 fdobridge: <m​ohamexiety> ERROR: [Loader Message] Code 0 : setup_loader_term_phys_devs: Failed to detect any valid GPUs in the current config
18:06 fdobridge: <m​ohamexiety> ERROR at /builddir/build/BUILD/Vulkan-Tools-sdk-1.3.216.0/vulkaninfo/vulkaninfo.h:231:vkEnumeratePhysicalDevices failed with ERROR_INITIALIZATION_FAILED
18:06 fdobridge: <m​ohamexiety> ```
18:06 fdobridge: <k​arolherbst🐧🦀> yeah, you'll need linux 6.6
18:06 fdobridge: <m​ohamexiety> ugh, now this is risky
18:07 fdobridge: <m​ohamexiety> I thought 6.6 was needed for Turing+ only
18:08 fdobridge: <k​arolherbst🐧🦀> nope, for everything
18:09 fdobridge: <m​ohamexiety> I see.
18:09 fdobridge: <m​ohamexiety> main issue I am worried about upgrading is the weird firmware stuff I ran into earlier with the 3080 making me unable to boot again. currently, this system outright doesn't recognize/init the 3080 so all is fine
18:09 fdobridge: <m​ohamexiety> buuut I guess I can try
18:09 fdobridge: <k​arolherbst🐧🦀> don't you have grub or something?
18:09 fdobridge: <m​ohamexiety> yes
18:09 fdobridge: <k​arolherbst🐧🦀> but yeah.. we might want to figure out what's the problem with your 3080
18:10 fdobridge: <k​arolherbst🐧🦀> _but_ it should be alright if your mesa is new enough, because I think you just ran into a userspace bug with gnome, no?
18:11 fdobridge: <m​ohamexiety> the userspace bug was due to firmware init failing somewhere during boot
18:11 fdobridge: <k​arolherbst🐧🦀> ohhh...
18:11 fdobridge: <k​arolherbst🐧🦀> right...
18:11 fdobridge: <k​arolherbst🐧🦀> do you have a log from that?
18:11 fdobridge: <g​fxstrand> You can build with `-Dnvk-legacy-uapi=true` for now
18:11 fdobridge: <k​arolherbst🐧🦀> I think if we forward that to nvidia it might help figuring it out
18:12 fdobridge: <g​fxstrand> We'll probably rip out the legacy UAPI code before the next Mesa release gets branched but having it in there for a short period makes development a tiny bit easier.
18:20 fdobridge: <m​ohamexiety> that worked, thanks!
18:22 fdobridge: <k​arolherbst🐧🦀> system values are now TGSI free in codegen :3
18:22 fdobridge: <k​arolherbst🐧🦀> well.. MR is assigned to marge, but it might make it easier to implement certain things
18:37 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> That kernel version doesn't exist right now 🫃
18:39 dakr: gfxstrand, airlied: applied the series to drm-misc-next.
18:52 gfxstrand: dakr: \o/
18:52 gfxstrand: Building now....
19:02 fdobridge: <g​fxstrand> @karolherbst Can I please get an RB for the "Import drm_nouveau.h" patch in the NVK MR?
19:02 fdobridge: <g​fxstrand> I'd like that one to have a proper RB tag
19:07 fdobridge: <k​arolherbst🐧🦀> does that commit have a different name, because I can't find it
19:10 fdobridge: <g​fxstrand> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326/diffs?commit_id=2ee043a82bf690a0dc0b6aca6de07bee578ad6f0
19:11 fdobridge: <m​henning> Are we certain that the new uapi will land in kernel 6.6? If there's any chance it might slip it might make sense to make the error message a more generic "kernel version too old" instead
19:11 fdobridge: <g​fxstrand> The 6.5 window only recently closed. We'll hit 6.6.
19:11 fdobridge: <g​fxstrand> And if we don't, we can update the message and back-port the fix.
19:15 fdobridge: <k​arolherbst🐧🦀> done
19:17 fdobridge: <k​arolherbst🐧🦀> we really have to fix gpu recovery 😢 but it's such a painful thing to debug
19:18 fdobridge: <g​fxstrand> Pardon me while I assign this little MR to marge....
19:19 fdobridge: <k​arolherbst🐧🦀> mhhh... gitlab needs gifs or something
19:19 fdobridge: <g​fxstrand> Ugh... That sysval MR is going to conflict silently.
19:19 fdobridge: <g​fxstrand> Can we delay it?
19:19 fdobridge: <k​arolherbst🐧🦀> uhh...
19:19 fdobridge: <k​arolherbst🐧🦀> rebase on top of it?
19:19 fdobridge: <g​fxstrand> It's going to be less painful to rebase sysvals
19:20 fdobridge: <k​arolherbst🐧🦀> okay
19:20 fdobridge: <g​fxstrand> I'll do the rebase.
19:20 fdobridge: <k​arolherbst🐧🦀> anyway, unassigned from marge
19:21 fdobridge: <k​arolherbst🐧🦀> though the big question is if CI will agree with our plans or not 🙂
19:37 fdobridge: <g​fxstrand> I really need to denylist some of these synchronization tests....
19:38 fdobridge: <g​fxstrand> Also, I'm getting a lot of crashes in this run and I don't know why...
20:00 fdobridge: <a​irlied> I hope someone is babysitting Marge :-p
20:11 fdobridge: <k​arolherbst🐧🦀> it's probably fine
20:19 fdobridge: <g​fxstrand> And... marge fail.
20:19 fdobridge: <g​fxstrand> Totally my fault
20:20 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Which revision of this patch should I use?: https://patchwork.freedesktop.org/series/112994 (revision 11 and 12 look weird to me)
20:21 fdobridge: <a​irlied> I suppose I should write a kernel blog
20:22 fdobridge: <g​fxstrand> Just grab drm-misc
20:23 fdobridge: <a​irlied> for raytracing, you could get a simple demo and use my nvidia cmd tracer to work out some bits I suppose
20:24 fdobridge: <k​arolherbst🐧🦀> that moment you rebase 16000 commits
20:33 fdobridge: <a​irlied> I think we've entered the dreaded wait for marge to timeout phase
20:34 fdobridge: <k​arolherbst🐧🦀> you still have 1.5 hours until it's Saturday for me, don't disappoint me, you said it's going to land today 😛
20:37 fdobridge: <g​fxstrand> Second build failure was @airlied 😛
20:41 fdobridge: <m​ohamexiety> this is very exciting to watch honestly.. I can't wait!
20:43 fdobridge: <g​fxstrand> Third build failure is people adding too many Mesa build flags. 🙄
20:44 fdobridge: <k​arolherbst🐧🦀> just remove them all
20:45 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> This exact error striked again :nope_gears:
20:48 fdobridge: <p​rop_energy_ball> I mean that could be removed it'd just make my life more painful :-)
20:48 fdobridge: <p​rop_energy_ball> Does NVK really not support hvv rn?
20:51 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> NVK has 2 heaps right now: a device-local heap (for the VRAM) and a host-visible/coherent heap (for the system RAM)
21:06 fdobridge: <a​irlied> okay I wrote a blogpost, now to hold off
21:06 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Where can I find it?
21:06 airlied: dakr: you might need to build with the nouveau svm option enabled, and send a follow patch if it still breaks
21:10 fdobridge: <a​irlied> I can't publish it until marge succeeds 🙂
21:15 fdobridge: <g​fxstrand> All the build tests pass. This time for sure!
21:17 fdobridge: <k​arolherbst🐧🦀> it doesn't build for me with the legacy uapi enabled
21:19 fdobridge: <g​fxstrand> Then don't enable legacy uapi. 😛
21:20 fdobridge: <k​arolherbst🐧🦀> don't ship with that option then 😛
21:20 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> When was the legacy uAPI created?
21:20 fdobridge: <k​arolherbst🐧🦀> it was before history was recorded
21:23 fdobridge: <g​fxstrand> Fixed. Sadly, I lost a race with marge so we'll see if that screwed anything up
21:24 fdobridge: <k​arolherbst🐧🦀> it probably does
21:24 fdobridge: <k​arolherbst🐧🦀> still have 36 minutes tho
21:27 fdobridge: <a​irlied> yeah might be another 1hr timeout wait
21:28 fdobridge: <k​arolherbst🐧🦀> 🥲
21:31 fdobridge: <g​fxstrand> I figred out how to cancel the pipeline so marge would kick it back to me.
21:31 fdobridge: <g​fxstrand> Kicked back to marge
21:49 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> 🇬🇧
21:49 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1137140354689277992/Screenshot_20230805_004629.png
21:55 fdobridge: <g​fxstrand> Ah, the terror of trying to land a giant MR which touches all the CI even though it affects none of it. 😅
22:02 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Have you encountered hanging issues with the new uAPI? 🐸
22:03 fdobridge: <g​fxstrand> Things have seemed a little less stable but not bad.
22:04 fdobridge: <g​fxstrand> They were more stable on the branch I was running than on drm-next. IDK why.
22:05 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> vkcube (X11) works fine until you try to close it but vkcube-wayland freezes on the first frame (push_sync has no effect and dmesg is too silent)
22:06 fdobridge: <g​fxstrand> I wouldn't be surprised if there are some VK <-> GL interop issues.
22:06 fdobridge: <g​fxstrand> Feel free to file the first NVK bug. 🙂
22:09 fdobridge: <e​sdrastarsis> merged 🥳
22:10 fdobridge: <g​fxstrand> 🎉
22:11 fdobridge: <g​eorgeouzou> 🎉 nice!
22:12 fdobridge: <k​arolherbst🐧🦀> 🎉
22:13 fdobridge: <k​arolherbst🐧🦀> phase of the moon
22:16 fdobridge: <g​fxstrand> Ugh... It's my wifi driver. 🙃
22:16 fdobridge: <g​fxstrand> Gotta love early rc kernels...
22:17 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> That's why I'm building the stable kernel instead 🐸
22:17 fdobridge: <g​fxstrand> I should just denylist iwlwifi
22:19 fdobridge: <g​fxstrand> It's not like that machine will ever use wifi
22:24 fdobridge: <p​homes> 🥳
22:28 fdobridge: <m​henning> 🎊
22:34 fdobridge: <g​fxstrand> https://www.collabora.com/news-and-blog/news-and-events/nvk-has-landed.html
22:37 fdobridge: <k​arolherbst🐧🦀> @gfxstrand do you wanna test https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24447 or should I just assign?
22:37 fdobridge: <k​arolherbst🐧🦀> though it shouldn't change anything... or is doing nvk weirdo things on that side?
22:37 fdobridge: <k​arolherbst🐧🦀> should probably check
22:38 fdobridge: <g​fxstrand> I'm gonna test
22:38 fdobridge: <g​fxstrand> Give me a minute. Need to disable the wifi driver first. 😂
22:38 fdobridge: <k​arolherbst🐧🦀> ohh.. nvk uses `nvc0_program_assign_varying_slots` mhh...
22:38 fdobridge: <k​arolherbst🐧🦀> mhhhh
22:38 fdobridge: <k​arolherbst🐧🦀> it's copied code
22:38 fdobridge: <k​arolherbst🐧🦀> yeah.. `nvk_vtgp_gen_header` needs updating
22:38 fdobridge: <k​arolherbst🐧🦀> lemme
22:40 fdobridge: <g​fxstrand> I didn't see that updated in nvc0_program.c
22:40 fdobridge: <k​arolherbst🐧🦀> now it should be fine
22:41 fdobridge: <k​arolherbst🐧🦀> probably would have failed to compile as I typed the value now
22:42 fdobridge: <k​arolherbst🐧🦀> not sure I'm gonna find the spoons to rework the input/output stuff, but it shouldn't be _that_ terrible either
22:43 fdobridge: <k​arolherbst🐧🦀> I should do a `s/PIPE_SHADER/MESA_SHADER/` commit 🙂
22:44 fdobridge: <k​arolherbst🐧🦀> mhh there is no `PIPE_SHADER_TYPES` equivalent
22:46 fdobridge: <k​arolherbst🐧🦀> but it's also used in a wierdo way..
22:46 fdobridge: <k​arolherbst🐧🦀> ehh.. I'll deal with it later
22:52 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I think I may have missed some patches (I now rebuilt the kernel with pretty much all the required patches)
23:05 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> And that was it 🐸
23:05 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1137159317758431272/Screenshot_20230805_020420.png
23:09 fdobridge: <g​fxstrand> 🥳
23:10 fdobridge: <k​arolherbst🐧🦀> wasn't there this thing to promote bindless ubos to bound one, or was that quite the pita to actually use in vulkan?
23:11 fdobridge: <g​fxstrand> Not something easy and automatic to hook up.
23:11 fdobridge: <g​fxstrand> Some drivers do. ANV does.
23:11 fdobridge: <k​arolherbst🐧🦀> Right..
23:14 fdobridge: <k​arolherbst🐧🦀> might make sense to extract some of it to common code. I might even look into it, because we'll need it anyway for older gens
23:16 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Overwatch 2 still crashes with the new uAPI 🤔
23:17 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> https://pastebin.com/xQKFMFvW
23:19 fdobridge: <k​arolherbst🐧🦀> uhhh
23:20 fdobridge: <k​arolherbst🐧🦀> I think you run into push buffer corruptions 😄
23:20 fdobridge: <k​arolherbst🐧🦀> which... shouldn't happen
23:20 fdobridge: <k​arolherbst🐧🦀> `c597 mthd 05b0 data 20010703` that's totally bogus
23:21 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> That date is older than me 🧓
23:22 fdobridge: <k​arolherbst🐧🦀> @gfxstrand nvk should probably start calling `nv_push_validate` again
23:24 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> @esdrastarsis Is your GPU temperature visible with GSP? And what kernel branch do you use for GSP support now?
23:25 fdobridge: <e​sdrastarsis> No, latest Ben's kernel tree
23:25 fdobridge: <e​sdrastarsis> Nothing related to sensors is visible with GSP
23:32 fdobridge: <k​arolherbst🐧🦀> @asdqueerfromeu mind running with this patch and check if it asserts?
23:32 fdobridge: <k​arolherbst🐧🦀>
23:32 fdobridge: <k​arolherbst🐧🦀> ```patch
23:32 fdobridge: <k​arolherbst🐧🦀> diff --git a/src/nouveau/vulkan/nvk_queue_drm_nouveau.c b/src/nouveau/vulkan/nvk_queue_drm_nouveau.c
23:32 fdobridge: <k​arolherbst🐧🦀> index b387530d90b..1ab4cf6a375 100644
23:32 fdobridge: <k​arolherbst🐧🦀> --- a/src/nouveau/vulkan/nvk_queue_drm_nouveau.c
23:32 fdobridge: <k​arolherbst🐧🦀> +++ b/src/nouveau/vulkan/nvk_queue_drm_nouveau.c
23:32 fdobridge: <k​arolherbst🐧🦀> @@ -477,6 +477,7 @@ nvk_queue_submit_drm_nouveau(struct nvk_queue *queue,
23:32 fdobridge: <k​arolherbst🐧🦀> for (unsigned i = 0; i < submit->command_buffer_count; i++) {
23:32 fdobridge: <k​arolherbst🐧🦀> struct nvk_cmd_buffer *cmd =
23:32 fdobridge: <k​arolherbst🐧🦀> container_of(submit->command_buffers[i], struct nvk_cmd_buffer, vk);
23:32 fdobridge: <k​arolherbst🐧🦀> + nv_push_validate(&cmd->push);
23:32 fdobridge: <k​arolherbst🐧🦀>
23:32 fdobridge: <k​arolherbst🐧🦀> list_for_each_entry_safe(struct nvk_cmd_bo, bo, &cmd->bos, link)
23:32 fdobridge: <k​arolherbst🐧🦀> push_add_bo(&pb, bo->bo, NOUVEAU_WS_BO_RD);
23:32 fdobridge: <k​arolherbst🐧🦀> ```
23:32 fdobridge: <k​arolherbst🐧🦀> need asserts enabled and stuff
23:33 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Also I just noticed that the DXVK frametime graph is now rendering correctly on NVK (so someone definitely did some codegen improvements) 🐸
23:34 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Rebuilding NVK now
23:34 fdobridge: <k​arolherbst🐧🦀> I hope you have `-Ddebug=true` set or something
23:34 fdobridge: <k​arolherbst🐧🦀> ehhh
23:35 fdobridge: <k​arolherbst🐧🦀> `-Db_ndebug=false`
23:35 fdobridge: <k​arolherbst🐧🦀> why have 1 flag if you can have 100
23:35 fdobridge: <k​arolherbst🐧🦀> in theory that change _should_ prevent any garbage to be sent to the GPU 😄
23:36 fdobridge: <k​arolherbst🐧🦀> and I think we want that for CI runs anyway, so it's less instable
23:36 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> `exe: ../mesa/src/nouveau/nvidia-headers/nv_push.c:28: nv_push_validate: Assertion 'push->end != push->start' failed.` 🤔
23:36 fdobridge: <k​arolherbst🐧🦀> sounds like it's working
23:36 fdobridge: <k​arolherbst🐧🦀> uhhh.. or maybe not
23:36 fdobridge: <k​arolherbst🐧🦀> ehh
23:37 fdobridge: <k​arolherbst🐧🦀> you might want to remove _that_ assert
23:37 fdobridge: <k​arolherbst🐧🦀> I think we actually submit empty stuff
23:37 fdobridge: <k​arolherbst🐧🦀> 😄
23:37 fdobridge: <k​arolherbst🐧🦀> yeah, so just delete that ` /* submitting empty push buffers is probably a bug */ assert(push->end != push->start);` part
23:38 fdobridge: <k​arolherbst🐧🦀> I wonder if I should turn it into a _full_ validator
23:39 fdobridge: <k​arolherbst🐧🦀> that would be a _fun_ project
23:43 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I didn't hit the assert this time (I got a DEVICE_LOST though)
23:44 fdobridge: <k​arolherbst🐧🦀> mhh
23:44 fdobridge: <k​arolherbst🐧🦀> could also be some random memory corruption
23:45 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I do have to turn off the 1 << 11 assert for the game to load its characters though
23:46 fdobridge: <k​arolherbst🐧🦀> mhhh?
23:49 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Ekstrand even had to do this: https://gitlab.freedesktop.org/gfxstrand/mesa/-/commit/76067b14d786b62ec003cfd87c18d25f7e9570db
23:50 fdobridge: <k​arolherbst🐧🦀> mhhh
23:50 fdobridge: <k​arolherbst🐧🦀> yeah, well.. that's fine
23:50 fdobridge: <k​arolherbst🐧🦀> or at least shouldn't cause corrupted commands
23:51 fdobridge: <k​arolherbst🐧🦀> mhhhhh
23:51 fdobridge: <k​arolherbst🐧🦀> I think I know what happens
23:54 fdobridge: <k​arolherbst🐧🦀> mind ditching the patch and run with `NVK_DEBUG=push_dump` and upload that entire log?
23:54 fdobridge: <k​arolherbst🐧🦀> it will be _huge_ probably
23:55 fdobridge: <k​arolherbst🐧🦀> ohh
23:55 fdobridge: <k​arolherbst🐧🦀> forget what I said
23:55 fdobridge: <k​arolherbst🐧🦀> run with `NVK_DEBUG=push_sync`
23:55 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> With the nv_push_validate dropped?
23:56 fdobridge: <k​arolherbst🐧🦀> yeah
23:56 fdobridge: <k​arolherbst🐧🦀> push_sync should dump the last failed submission
23:59 fdobridge: <k​arolherbst🐧🦀> I'm sure nvk somewhere submits an empty command, which shouldn't happen, probably some for loop being wrong 🙂