06:04fdobridge: <gfxstrand> I'm starting to think so, yes. Something to do with clipping.
06:04fdobridge: <gfxstrand> It's the only thing that makes sense at this point.
06:04fdobridge: <gfxstrand> I've run out of documented bits to twiddle.
06:05fdobridge: <gfxstrand> And now that I've verified that NVK, Nvidia, and ANV are all getting exactly the same depth values for other pixels, I know bias is working correctly and that they're not shutting it off like it looked in the trace from @airlied. There's something missing with clip settings.
06:06fdobridge: <gfxstrand> I also think there might be a chicken bit we're missing because when I was originally getting depth clipping working, it wasn't clipping properly to one of the planes. I had to smash the guardband scale to 1 and use the guardband to clip Z in order to clip both planes. That seems very wrong.
06:07fdobridge: <gfxstrand> This seems fundamental enough that I suspect there's an MMIO bit or two for the clipper that we're just missing.
06:09fdobridge: <gfxstrand> A quick grep of OGK isn't being particularly instructive.
06:11fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> Does that require reverse-engineering?
06:15fdobridge: <gfxstrand> Sometimes we can ask people at NVIDIA and they just tell us.
08:19fdobridge: <karolherbst🐧🦀> yeah, I got told about the fp helper invoc stuff after I asked
09:01fdobridge: <karolherbst🐧🦀> @gfxstrand but now that we know what we are looking for, we should be able to find it ourselves. Mind dumping all pushbuffers, especially the macro invocations? And it kinda has to be one of those: https://nv-tegra.nvidia.com/r/gitweb?p=linux-nvgpu.git;a=blob;f=drivers/gpu/nvgpu/hal/gr/init/gr_init_gv11b.c;h=6f6f6bb9709dfa3170cf8837fea9c768caf31930;hb=refs/heads/rel-36#l58
09:01fdobridge: <karolherbst🐧🦀> unless they do it on the kernel side for everything
09:01fdobridge: <karolherbst🐧🦀> but maybe it's again gr_pri_gpcs_tpcs_sm_disp_ctrl 🙃
09:01fdobridge: <karolherbst🐧🦀> try flipping random bits until it works
09:01fdobridge: <karolherbst🐧🦀> set it all to 0 and all to 1 for starters
09:01fdobridge: <karolherbst🐧🦀> `0x404468, /* gr_pri_mme_max_instructions */` might come in handy at some point
09:01fdobridge: <karolherbst🐧🦀> `0x418380, /* gr_pri_gpcs_rasterarb_line_class */` it has "raster" in it's name
09:01fdobridge: <karolherbst🐧🦀> but yeah, if you summarize what you need I can send an email to Andy, or you can do it, either way should work
15:27fdobridge: <gfxstrand> Oh, like z_cull_ctx_debug, maybe? 😂
15:28fdobridge: <gfxstrand> Oh, like zcull_ctx_debug, maybe? 😂 (edited)
15:29fdobridge: <gfxstrand> I've got a dump of their stuff somewhere still. I'll try and dig through it.
15:29fdobridge: <gfxstrand> Or maybe I should play with @marysaka's new dumper
15:53fdobridge: <marysaka> I also have a branch with a tool for the push decoding if you need that <https://gitlab.freedesktop.org/marysaka/mesa/-/tree/nouveau/pushbuf-dump-tool>
16:24benjaminl: oh lol I wrote a similar tool last week, not knowing this existed
16:24benjaminl: this version is significantly nicer :)
16:44benjaminl: is there a chance someone has already written a CLI front-end for the MME simulators as well?
17:00fdobridge: <marysaka> I didn't but it could be nice to have one (with some way to pretty print instructions from a blob too)
17:04fdobridge: <gfxstrand> Do I need to use ogk for your dumper or will it work on the blob kernel?
17:05fdobridge: <marysaka> ogk? For envyhooks you need blob driver with version 535.113.01
17:06fdobridge: <karolherbst🐧🦀> ogk is the open source version
17:06fdobridge: <marysaka> oh I only tested with the blob one
17:06fdobridge: <marysaka> but I use the open source one for ioctl arg struct
17:06fdobridge: <marysaka> but I use the open source one for ioctl arg structs (edited)
17:06fdobridge: <gfxstrand> Okay
17:06fdobridge: <gfxstrand> Yeah, I don't want to mess with OGK
17:07fdobridge: <gfxstrand> Blob is better
17:07fdobridge: <marysaka> also you need to set ``EHKS_PUSHBUF_DUMP_DIR`` for it to actually dump stuffs
17:07fdobridge: <gfxstrand> Where is envyhooks?
17:07fdobridge: <marysaka> https://gitlab.freedesktop.org/marysaka/envyhooks
17:08fdobridge: <gfxstrand> Thanks!
17:08fdobridge: <marysaka> (the pushbuf-dump-tool's branch was only for analysing the resulting output blobs)
17:08fdobridge: <gfxstrand> That's fine. Probably better that way anyway
17:08fdobridge: <marysaka> be aware that it does split a lot of files (used to be worse buut yeah)
17:09fdobridge: <gfxstrand> That's okay
17:09fdobridge: <marysaka> oh and yeah that's an LD_PRELOAD style thing
17:10fdobridge: <marysaka> and you need rust nightly (because of c_variadic, if you find a way to get ride of that I could use stable)
17:13fdobridge: <gfxstrand> @karolherbst I'm going to try and work on slides today. I think for the nouveau update talk, I'll plan to talk about NVK and the new uAPI and I'll leave GSP and any other nouveau happenings to you.
17:13fdobridge: <karolherbst🐧🦀> yeah, fair
17:13fdobridge: <karolherbst🐧🦀> I try to work on my slides and everything tomorrow
17:14fdobridge: <gfxstrand> @karolherbst Does RH have a slide deck template they want people using? I'm going to use the Collabora template for my NAK talk but the nouveau/NVK one should probably either be generic or some sort of hybrid.
17:14fdobridge: <karolherbst🐧🦀> uhh.. if there is I never actually bothered using it
17:14fdobridge: <gfxstrand> lol
17:14fdobridge: <gfxstrand> Maybe I'll just add some RH logos to the Collabora deck and make it a little less purple. 🙃
17:16fdobridge: <karolherbst🐧🦀> just mix the colors and use what's the result of it 🙃
17:16fdobridge: <karolherbst🐧🦀> but yeah, I don't particularly care about company branding and nobody told me to do it, so whatever 🤷
17:17fdobridge: <karolherbst🐧🦀> if they want to see their logos at a conference, they can sponsor it 🙃
17:26benjaminl: oh wow, this envyhooks thing is also massively nicer than what I was doing with a hacked demmt :)
17:26benjaminl: this is fantastic
17:27fdobridge: <marysaka> It's quite cursed (especially around catching write to USERD memory regions) but it does the job so far 😅
17:39benjaminl: demmt, even with modifications, only catches like 25% of the pushbufs
17:39benjaminl: I found the rest by looking at the binary diff on all the memory writes and then picking them out by hand
17:40karolherbst: yeah... demmt has big gaps these days
17:40karolherbst: and valgrind is unusable most of the time anyway, so it's good that we have something better now
17:41benjaminl: hmm, what makes valgrind unusable?
17:41karolherbst: it's slow
17:41benjaminl: I had to add a couple new ioctls to it for the chipset injection thing, but it was otherwise fine
17:41benjaminl: ah
17:41fdobridge: <marysaka> my thing mark the GPFIFO region mapped in process as read only and catch SIGFAULT on it
17:41karolherbst: it might be good enough for CTS, but if you start running game traces... uhh.. it takes a while
17:41karolherbst: valgrind runs an instruction simulator
17:43fdobridge: <gfxstrand> How about this?
17:43fdobridge: <gfxstrand> https://cdn.discordapp.com/attachments/1034184951790305330/1162445588495880262/image.png?ex=653bf6d1&is=652981d1&hm=4bbec2485a21b03e8ddca268e882c76b97f7e0af8638f11de50707c69915b466&
17:43fdobridge: <karolherbst🐧🦀> ahh yeah, that's good
17:44fdobridge: <gfxstrand> I had to use Inkscape to make the footer and export it at as a PNG because LibreOffice sucks but whatever...
17:44fdobridge: <karolherbst🐧🦀> 😄
17:45fdobridge: <karolherbst🐧🦀> the last time I used inkscape I uninstalled it 2 seconds later
17:45fdobridge: <gfxstrand> It's done now. It took me maybe 30m
17:46fdobridge: <gfxstrand> Most of that time was farting around with LibreOffice trying to get it to do things it can't. 😩
17:46fdobridge: <gfxstrand> The inkscape bit was like 5m
17:46fdobridge: <karolherbst🐧🦀> pain
17:46fdobridge: <karolherbst🐧🦀> I probably would have tried to do something with krita, but yeah...
17:47fdobridge: <gfxstrand> I'm pretty good with InkScape
17:50fdobridge: <gfxstrand> And... I just realized that it's totally fine to keep the Collabora green header text because it's pretty close to nvidia green. :triangle_nvk:
17:53fdobridge: <karolherbst🐧🦀> noice
17:54fdobridge: <gfxstrand> This looks way too marketing ready
17:54fdobridge: <gfxstrand> https://cdn.discordapp.com/attachments/1034184951790305330/1162448211647144027/image.png?ex=653bf942&is=65298442&hm=bfff6d8a3ace9ce1ae0373f592c514594ba150e88c9ca60946f028a2b989b261&
17:54fdobridge: <gfxstrand> (Squiggles are because it's a screenshot of the editor)
17:56fdobridge: <karolherbst🐧🦀> that looks way too professional, but we can keep the illusion
17:56fdobridge: <gfxstrand> I guess this is what happens when you become a PE (PowerPoint Engineer)
17:57fdobridge: <gfxstrand> Though I actually did manage to skip that job title...
17:57fdobridge: <gfxstrand> I was doing that job at Intel, though, by the end. 🙃
17:57fdobridge: <gfxstrand> Let's try not to remember that. 😅
17:57fdobridge: <gfxstrand> Let's try not to remember that... 😅 (edited)
17:57fdobridge: <karolherbst🐧🦀> mhhhhh
17:58fdobridge: <karolherbst🐧🦀> that's my next step 🙃
17:58fdobridge: <karolherbst🐧🦀> ah yes, apparently I'm a SSE now
17:59fdobridge: <karolherbst🐧🦀> I haven't asked if that also includes fancy PP slides...
18:03fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> SSE?
18:04fdobridge: <karolherbst🐧🦀> senior software engineer
18:04fdobridge: <karolherbst🐧🦀> Faith left a reference, so big thanks for that again 🙃
18:06fdobridge: <gfxstrand> You're welcome!
18:06fdobridge: <gfxstrand> Well earned, IMO
18:07fdobridge: <karolherbst🐧🦀> I'm just bad with all that title stuff, because I'm not particularly caring what title somebody has 🙃
18:08fdobridge: <karolherbst🐧🦀> maybe not that I'm more familiar with the process the next step won't take as long 😄
18:29fdobridge: <gfxstrand> Heh. Titles are kinda BS anyway.
18:29fdobridge: <gfxstrand> I've met a lot of utterly incompetent PEs
18:32fdobridge: <karolherbst🐧🦀> right, but you also worked for intel 🙃 I'm aware of the stories
18:34fdobridge: <karolherbst🐧🦀> but yeah... the entire process is unfair, and often promotions don't really have merit behind them or the rules are made in a way, that certain kinda of people have an advantage and other nonsense
19:44fdobridge: <airlied> 16 years in and I still don't know where to find the RH slide template
21:12fdobridge: <gfxstrand> So far, this slide deck is 90% snark
21:13Lyude: So - trying to get igt running again so I can see if most of the tests pass with atomic modesetting. I'm seeing that the current tests fail to actually instantiate the dma_copy class - I assume this has something to do with GSP?
21:13karolherbst: huh... I think that's a new one
21:14HdkR: Wait
21:14HdkR: Lyude: No XDC this year?
21:15HdkR: Who am i supposed to direct all this unbridled shitposting towards now?
21:16HdkR: karolherbst: No XDC? :O
21:16karolherbst: no XDC?
21:16HdkR: I don't see either of you on the participant list
21:16Lyude: i always forget to add myself :(
21:17Lyude: i will do that like asap haha
21:17karolherbst: :D
21:17karolherbst: I have two talks!
21:17HdkR: lol, I haven't really peeped the talks :D
21:17HdkR: whew, safe
21:17Lyude: karolherbst: I assumed something might have changed with the userspace interface maybe? Note that we actually use libdrm directly in igt, since we basically write stuff to a CPU buffer and then use the copy engine in order to make it tiled (along with clearing memory before we use it, but with the latest GSP changes I have a feeling I might be able to get rid of this bit)
21:19karolherbst: ahh yeah...
21:19karolherbst: since ampere even
21:19karolherbst: let me dig it up
21:20karolherbst: Lyude: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16784
21:20karolherbst: ehh
21:20karolherbst: wrong one
21:20karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17633
21:20karolherbst: we query the supported classes in userspace now
21:21karolherbst: and then just you know.. do the same thing as we do on the kernel side
21:21karolherbst: though the old way should still work
21:21karolherbst: but you'd still have to use the correct class from userspace
21:21Lyude: looked in open gpu docs and noticed another dma-copy class that isn't here
21:21Lyude: so that might just be the issue
21:21karolherbst: yeah... anyway, since ampere you have to allocate the dma-copy class
21:22karolherbst: and if you don't, it won't work
21:23Lyude: yeah that's what we did before :P, I just didn't have the latest class ID added to igt
21:23Lyude: just added it and it works fine now :)
21:23karolherbst: cool
21:27Lyude: eyyyyyyy already crashed the gpu :3
21:27Lyude: looks like I've got some bugs to track down
21:27fdobridge: <phomes> the marp extension in vscode is so nice for presentations. I am supposed to use this annoying power point template at work but all they ever get is the default marp theme 🙂
21:37Lyude: i like that fbcon seems to still work just fine with the display core crashed
21:43Lyude: karolherbst: [ 139.787588] nouveau 0000:1f:00.0: gsp: Xid:56 CMDre 00000001 00000200 00000001 00000005 0000000a ← any idea how we can decode this? surprisingly, I don't think we're getting any kind of normal NVdisplay error (…unless that's how we receive those errors now?)
21:45Lyude: …oh dear. hm.
22:16Lyude: (I mostly figured it out - it is the NVDisplay error code thankfully, just a little unsure which channel it's coming from now)
23:17fdobridge: <gfxstrand> @marysaka
23:17fdobridge: <gfxstrand> ```
23:17fdobridge: <gfxstrand> EHKS_PUSHBUF_DUMP_DIR=/tmp/dump VK_ICD_FILENAMES=/etc/vulkan/icd.d/nvidia_icd.json LD_PRELOAD=$HOME/projects/envyhooks/target/debug/libenvyhooks.so ./deqp-vk -n dEQP-VK.draw.renderpass.inverted_depth_ranges.nodepthclamp_deltasmall_bias_clamp_pos
23:17fdobridge: <gfxstrand> Writing test log into TestResults.qpa
23:17fdobridge: <gfxstrand> dEQP Core vulkan-cts-1.3.7.0-0-ged69dc1c51d02edd3db9e3747320a510f665766b (0xed69dc1c) starting..
23:17fdobridge: <gfxstrand> target implementation = 'Default'
23:17fdobridge: <gfxstrand> WARNING: GPFIFO data seems invalid, skipping GpFifoRawEntry { opcode: Nop, sync_wait: false, gpu_address: 67108864, size: 566 }
23:17fdobridge: <gfxstrand> WARNING: GPFIFO data seems invalid, skipping GpFifoRawEntry { opcode: Nop, sync_wait: false, gpu_address: 69992448, size: 64 }
23:17fdobridge: <gfxstrand> WARNING: GPFIFO data seems invalid, skipping GpFifoRawEntry { opcode: Nop, sync_wait: false, gpu_address: 67108864, size: 566 }
23:17fdobridge: <gfxstrand> WARNING: GPFIFO data seems invalid, skipping GpFifoRawEntry { opcode: Nop, sync_wait: false, gpu_address: 69992448, size: 64 }
23:17fdobridge: <gfxstrand> thread '<unnamed>' panicked at 'assertion failed: request_type != 0 || request_arg_size == 0', src/hooks/mod.rs:302:13
23:17fdobridge: <gfxstrand> note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
23:17fdobridge: <gfxstrand> fatal runtime error: failed to initiate panic, error 5
23:17fdobridge: <gfxstrand> ```
23:17fdobridge: <marysaka> huh
23:18fdobridge: <marysaka> ah right that's because I wasn't sure how to passthrough the ioctl arg, you can probably remove the assert @gfxstrand
23:20fdobridge: <gfxstrand> Hey, look! Pushbufs!
23:20fdobridge: <gfxstrand> 5 of them
23:29fdobridge: <gfxstrand> But none of them have 3D draw commands....
23:34fdobridge: <gfxstrand> I think it's because the CTS creates multiple devices and I'm not getting pushbufs from anything but the first one
23:34fdobridge: <gfxstrand> Which is dumb but what ya gonna do?
23:36fdobridge: <marysaka> huh..
23:37fdobridge: <marysaka> it should be catching all of them 😕
23:39fdobridge: <gfxstrand> Ugh... GDBing this thing is such a pain. 😂
23:45fdobridge: <marysaka> yeah I use single step :vReiAgony:
23:47fdobridge: <gfxstrand> Yeah, I'm not getting usable data out of this
23:48fdobridge: <gfxstrand> Maybe Turing is different? I'm using the same driver version you suggested.
23:49fdobridge: <marysaka> I'm quite confused because trying to run the same thing as you get me a BUS error when trying to query the GPGet value...
23:50fdobridge: <gfxstrand> Oh, no!
23:51fdobridge: <gfxstrand> Maybe I should just start poking MMIO regs blind....
23:51fdobridge: <marysaka> yeah I guess..
23:51fdobridge: <marysaka> I tested my thing with vkcube and other UI application so far.... not quite sure why this is breaking like that atm
23:54fdobridge: <karolherbst🐧🦀> at least you shouldn't be able to deal like real harm through the macro
23:55fdobridge: <karolherbst🐧🦀> worst case you disable error reporting and the kernel won't tear down the channel or something 🙃
23:56fdobridge: <marysaka> it's random uurgh
23:59fdobridge: <marysaka> @gfxstrand Okay I know why it wasn't dumping much, I have way more command buffers now, will remove the skip around no prefetch gpfifo entries