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