01:32fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> Finally something is going to be merged for gamescope
02:21fdobridge: <gfxstrand> And... CTS is happy. merged!
02:56fdobridge: <samantas5855> poggers
02:56fdobridge: <samantas5855> is nak merged?
05:53fdobridge: <airlied> @gfxstrand 229 is a simple bug fix
06:01fdobridge: <airlied> @zmike zink + glcts found a bug in my sparse impl already 😛
13:30fdobridge: <gfxstrand> Woo
14:22fdobridge: <gfxstrand> Merged. Surprised I didn't figure that out already, though.
14:26fdobridge: <gfxstrand> @asdqueerfromeu Any reason why you haven't made that VK_EXT_physical_device_drm patch an MR?
14:28fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> Moving it to common code would be better but I'm not sure how I should do that
14:29fdobridge: <gfxstrand> Now that we have the try_create_for_drm hook in `vk_physical_device`, you could do it in `enumerate_drm_physical_devices_locked()` or maybe with a helper that gets called from there.
14:30fdobridge: <gfxstrand> Then add a helper to fill out the query struct.
14:31fdobridge: <gfxstrand> Like maybe a `vk_physical_device_get_drm_properties()` helper.
14:32fdobridge: <gfxstrand> That's how I'd go about it, at least in the current infrastructure.
15:18fdobridge: <karolherbst🐧🦀> okay.. it's ada time
15:37fdobridge: <karolherbst🐧🦀> what's the way of getting GSP to run again?
15:49fdobridge: <esdrastarsis> It's the same way (using Ben's kernel branch 00.02-gsp-rm) but it looks like it's broken for turing and ampere, idk about ada
15:49fdobridge: <karolherbst🐧🦀> mhhh
15:49fdobridge: <esdrastarsis> and using 535.54.03 firmwares
15:49fdobridge: <esdrastarsis> and use 535.54.03 firmwares (edited)
15:51fdobridge: <mohamexiety> what goes into new GPU support btw? curious about that
15:51fdobridge: <karolherbst🐧🦀> depends on the generation
15:51fdobridge: <karolherbst🐧🦀> though I just want to enable the GL and vulkan bits
15:55fdobridge: <karolherbst🐧🦀> @esdrastarsis wasn't there a script I need to run or something?
15:56fdobridge: <karolherbst🐧🦀> ohh wait, that script moved into the tree
15:56fdobridge: <esdrastarsis> yes, in nouveau dir in openrm
15:56fdobridge: <esdrastarsis> yes, in nouveau dir in openrm repo (edited)
15:59fdobridge: <gfxstrand> How is the uAPI coming? I've been ignoring it until someone tells me to do otherwise but it is the thing that's blocking a merge into mesa/main
16:05fdobridge: <karolherbst🐧🦀> now let's see if it boots.. though I'm sure I forgot something important...
16:06fdobridge: <karolherbst🐧🦀> `[ 4.190680] nouveau 0000:01:00.0: gsp ctor failed: -2` 🥲
16:09fdobridge: <karolherbst🐧🦀> ahh shoo.. I forgot to add the gsp binary 😄
16:12fdobridge: <gfxstrand> That'll do it!
16:22fdobridge: <karolherbst🐧🦀> `[ 5.628244] [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on minor 0` :3
16:22fdobridge: <karolherbst🐧🦀> uhh
16:22fdobridge: <karolherbst🐧🦀> there are errors though
16:23fdobridge: <karolherbst🐧🦀> is there an ada gsp thing? mhh maybe I shouldn't have used the ampere one?
16:23fdobridge: <karolherbst🐧🦀> ehh wait, it's some DP nonsense
16:23fdobridge: <karolherbst🐧🦀> runtime pm is broken as unloading gsp fails...
16:23fdobridge: <karolherbst🐧🦀> classic
16:25fdobridge: <esdrastarsis> ampere firmware is for ampere, ada and hopper
16:26fdobridge: <karolherbst🐧🦀> okay, let's see if I can get GL stuff to run
16:49fdobridge: <karolherbst🐧🦀> getting `EACCES` from the kernel 🥲
16:51fdobridge: <karolherbst🐧🦀> why is this all so painful over ssh these days 😄
16:52fdobridge: <karolherbst🐧🦀> oh well...
16:52fdobridge: <karolherbst🐧🦀> after dinner
16:57anholt: hmm, lots of "dEQP error: ERROR: unknown op: 88" from nvk on gk20a. SULDP?
17:27karolherbst: huh...
17:28karolherbst: anholt: do you know since when it's happening?
17:28karolherbst: anholt: anyway, mind filing a bug and assign it to me?
17:29anholt: https://gitlab.freedesktop.org/anholt/mesa/-/jobs/41127859 didn't have it, so last couple months.
17:30anholt: would love to see my any comments on my nvk MRs. :/
17:31karolherbst: ohh this is with nvk.. right..
17:32karolherbst: I guess the chipset isn't set correctly or something for gk20a
17:38karolherbst: left a comment
17:40anholt: is nvk doing "get an r-b, hit the merge button?"
17:41karolherbst: I think Faith wants to test stuff before merging, not sure
17:43karolherbst: anholt: can you check what chipset is set inside "Target *Target::create"?
17:47anholt:needs to get one of these back on the desk
17:48anholt: unrelated: do PHYSICAL_STACK_OVERFLOW errors likely mean we're setting up slm wrong, or something else?
17:50karolherbst: nah, it's probably the call/return stack
17:50karolherbst: there is limited space and we can spill it to VRAM instead, which is slow
17:50karolherbst: but we don't do it for 3D at all
17:51karolherbst: let me find it..
17:53karolherbst: here is the todo in the gl driver: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/nouveau/nvc0/nvc0_program.c#L734
17:54karolherbst: and I think there was a compute toggle somwhere
17:55karolherbst: SHADER_LOCAL_MEMORY_CRS_SIZE
17:55karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/nouveau/nvc0/nve4_compute.c#L615
17:56karolherbst: we kinda have to be able to estimate how much a shader needs
17:56karolherbst: and if it's above 0x400? it needs to be spilled
17:56karolherbst: https://nvidia.github.io/open-gpu-doc/Shader-Program-Header/Shader-Program-Header.html
17:57karolherbst: call/return stack or CallReturnStack
18:18anholt: interesting that gallium is setting up some crs slm space, but not setting it in the program header.
18:18karolherbst: it's part of tls
18:18karolherbst: ehh wait, I missunderstood
18:18karolherbst: it's used for compute
18:18karolherbst: and I think it reads out the header to identify the size or something, no?
18:26anholt: karolherbst: 0xea chipset in the target
18:26karolherbst: mhhh weird...
18:26anholt: (same as reported in GL renderer)
18:27karolherbst: yeah.. I'm wondering why codegen doesn't lower OP_SULDP then
18:29karolherbst: mind dumping `tex.target` of that instruction?
18:29karolherbst: might have to cast to TexInstruction
18:29anholt: oh, convertSurfaceFormat is what turns SULDP into something else
18:29karolherbst: yeah
18:29anholt: ok, easy fix then,.
18:30karolherbst: I'm mostly wondering why it's not called
18:30karolherbst: maybe some nvk patch?
18:30anholt: the commit that I mentioned in the issue.
18:31karolherbst: ahh yeah..
18:31karolherbst: that would do it
18:32karolherbst: I guess PIPE_FORMAT_NONE needs special treatment then
18:33anholt: we just need to stop exposing a feature we don't actually support.
18:41anholt: chasing down another possible bug -- is there a doc with the opcs emitted by nv50_ir_emit_nvc0.cpp?
18:42karolherbst: nope
18:42karolherbst: I do however have the ISA doc under NDA from Volta+, depending on the opcode it might be applicable to older gens
18:43karolherbst: I can talk about details, but I can't quote or share the doc
18:49anholt: bah. smashing DoesLoadOrStore on didn't help SSBO stability anyway.
20:30anholt: gah. I'm setting shaderStorageImageReadWithoutFormat to false, but we still get tests like dEQP-VK.robustness.robustness2.bind.notemplate.r32i.unroll.nonvolatile.storage_image.no_fmt_qual.null_descriptor.samples_1.1d.comp doing no-format loads.
20:31anholt: hmm. maybe it's the format feature bit.
20:31fdobridge: <airlied> actually we should talk about the sync interface a bit, esp wrt imported/exported bos
20:32fdobridge: <airlied> the core gpuva management code is soon to go in, just need to sort through the nouveau specifics
20:32fdobridge: <airlied> now that you merged external fd I have to integrate that
20:34fdobridge: <gfxstrand> Yes. You want to have a live chat? I'm busy this afternoon but any other day this week should be fine.
20:36fdobridge: <karolherbst🐧🦀> uhhh.. we don't have the ada compute class headers
20:37fdobridge: <airlied> down with a bit of flu, but might be able to manage something tomorrow, I think the main question is do I need to have an explicit bo list on exec for external objects for synchronisation only?
20:37fdobridge: <airlied> for implicit sync purposes
20:37fdobridge: <gfxstrand> No, NVK will use the dma-buf sync_file import/export stuff.
20:38fdobridge: <gfxstrand> No Implicit sync outside of what's required for kernel-internal memory management.
20:43fdobridge: <karolherbst🐧🦀> does anybody know if prime offloading works with GSP? 😄
20:43fdobridge: <karolherbst🐧🦀> mhh.. uhh.. how do I do this then...
20:44fdobridge: <karolherbst🐧🦀> ohh maybe I can flip to nvidia only on this laptop
20:46fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> Last time I tried GSP the display output and temperature sensor was broken (and most apps I tried had the VRAM error)
20:46fdobridge: <airlied> @karolherbst yes I've done offload with gsp enabled on turing
20:48fdobridge: <karolherbst🐧🦀> mhhhhh, well.. running glxgears doesn't give me anything 🥲
20:48fdobridge: <karolherbst🐧🦀> but the GPU also doesn't complain about anything
20:57fdobridge: <karolherbst🐧🦀> the 3D class is _literally_ identical
20:57fdobridge: <karolherbst🐧🦀> (to ampere that is)
20:57fdobridge: <karolherbst🐧🦀> let me start X on the nvidia GPU, but I think display support was still broken with GSP? mhh
20:58fdobridge: <karolherbst🐧🦀> @airlied do you know how much display stuff is broken?
20:58fdobridge: <karolherbst🐧🦀> like.. does HDMI or DP work better?
21:00fdobridge: <karolherbst🐧🦀> looks like HDMI works
21:00fdobridge: <karolherbst🐧🦀> ehh wait.. that's on intel
21:03fdobridge: <karolherbst🐧🦀> I love how nothing works on this laptop
21:10fdobridge: <airlied> nope I haven't ran display, I think Ben has basics working on his machines, but the hw varies so much
21:11fdobridge: <karolherbst🐧🦀> yeah...
21:11fdobridge: <karolherbst🐧🦀> but I suspect prime is broken as it's also kinda broken on ampere sadly
21:11fdobridge: <karolherbst🐧🦀> maybe I just run the CTS and see if that complains
21:15fdobridge: <airlied> I assume you have Ben's latest branch
21:16fdobridge: <karolherbst🐧🦀> yeah fetched today
21:16fdobridge: <karolherbst🐧🦀> unless there is an ever newer one
21:16fdobridge: <karolherbst🐧🦀> 25db92a3e5514b0563efc2877003c303512d589a
21:29fdobridge: <airlied> @gfxstrand probably the most useful think I could ask is to review the uapi MR for required functionality that is missing
21:29fdobridge: <airlied> the code is a bit messy since it tries to keep the old uapi around for now, but otherwise it would be good to have it reviewed as it's a prereq for merging the kernel side
21:30fdobridge: <gfxstrand> Yup. Will do. I just didn't know how confident you were with stability, etc.
21:31fdobridge: <airlied> I can run CI runs on it most of the time
21:31fdobridge: <airlied> but lots of moving parts
21:32fdobridge: <gfxstrand> Yeah
21:32fdobridge: <airlied> but more looking for the, "this is missing explicit sync" type comments 😛
21:32fdobridge: <gfxstrand> Do you have a mostly working kernel branch you can recommend?
21:32fdobridge: <gfxstrand> I'll pull and play
21:33fdobridge: <airlied> https://gitlab.freedesktop.org/nouvelles/kernel/-/tree/new-uapi-drm-next-fixes?ref_type=heads
21:34fdobridge: <airlied> I think you have to manually add your favourite fix for helper invocations
21:41fdobridge: <kiwi> Any reason you recommend that branch over the newer one? https://gitlab.freedesktop.org/nouvelles/kernel/-/commits/new-uapi-drm-next
21:44airlied: aren't they the same branch?
21:49fdobridge: <kiwi> no, the second one's based on a newer kernel with the v7 gpuva manager, the other one's an older iteration
21:56fdobridge: <airlied> doh, they were the same a few days ago, @faith go the newer one 🙂
23:33anholt: no luck so far making tk1 stable for any subset of tests that do graphics rendering. queue syncing or INVALIDATE_TEXTURE_DATA_CACHE in pipeline barrier are not helping.
23:58karolherbst: yeah.. there is something super wonky going on and any time I try to look at it, I am not hitting errors...
23:59karolherbst: anholt: what kernel are you on atm btw?