00:10 fdobridge: <p​homes> I started to look at VK_KHR_draw_indirect_count. I got a bit stuck with the mme. I have the address of the count buffer as a mme_value64. Can I read the value from it into a mme_value.
00:10 fdobridge: <p​homes> https://gitlab.freedesktop.org/phomes/mesa/-/commit/c15023608085ffc3dc5e8bce27b19dabd49ed20f
00:38 illwieckz: ⁉️ is it legit C syntax? 🤔️ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nvkm/engine/gr/nv04.c#n1220
00:39 illwieckz: 🤨️ what does it do? 🧐️
00:42 airlied: it's a macro that might be overly magic, but I assume it pools the condition every 2000ms
00:42 karolherbst: yeah, it's a macro
00:42 karolherbst: and I hate it
00:42 karolherbst: it literally uses the GPU timer instead of the CPU one
00:43 karolherbst: and once the GPU is toast, the driver is toast as those things loop forever
00:43 karolherbst: just burn it to the ground
00:43 karolherbst: but Ben disagrees
00:44 karolherbst: anyway, it's some nifty macro around loading the timer from the GPU and some macro magic
00:45 karolherbst: it's actually causing real harm, as on laptops the gpu dieing because of runpm also means your system just dies
00:46 illwieckz: yeah, that looks to be a macro and to be intentional: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c4584adc37720b65ae44a84c660d47b3ebcf7dfb
00:46 karolherbst: I think it's a terrible idea to depend on the GPU timer for CPU code, but....
00:47 karolherbst: could use nice things like msleep_range instead
00:47 karolherbst: or just busy waiting with... something else
00:48 illwieckz: outside of what this code does, at first glance that code looks like a badly solved merge conflict that went unnoticed 😁️
00:48 mhenning: phomes: Glancing at the mme stuff, I think you have DWRITE, DREAD opcodes for accessing ram, but also I'm missing a lot of context, so this might not be the right thing
00:54 mhenning: (in particular, they're not atomics)
03:26 airlied: ass: 236641, Fail: 1804, Crash: 978, Warn: 4, Skip: 1396668, Timeout: 3, Flake: 1158, Duration: 3:15:35, Remaining: 0
03:26 airlied: Pass: 236641, Fail: 1804, Crash: 978, Warn: 4, Skip: 1396668, Timeout: 3, Flake: 1158, Duration: 3:15:35, Remaining: 0
03:27 airlied: low vm allocations and crash instead of fail gracefully on device loss
03:27 airlied: so that deqp runner starts a bunch of tests again
03:39 airlied: jekstrand: trivial fix in 152
04:12 jekstrand: airlied: merged
04:19 fdobridge: <j​ekstrand> Left you a bunch of comments on that commit. Hopefully I've given you enough breadcrumbs that you can figure out the rest.
04:20 fdobridge: <j​ekstrand> If you want to know what something does, look at mme_tu104_sim.c and the mme unit tests. The simulator isn't a perfect representation of the hardware but it's pretty close as far as I can tell.
04:22 fdobridge: <j​ekstrand> You would think so, but no. Those are basically for scratch memory within a single MME macro. There is a command which lets you dump said scratch out to memory but it's not that useful as far as I've found. I don't know if you can read memory into the DREAD/WRITE area or not. All my attempts failed.
04:22 fdobridge: <j​ekstrand> mhenning ^^
04:26 mhenning: Ah, I guess I misread that one then
04:27 fdobridge: <j​ekstrand> I do believe there has to be a way to get data into the DREAD/DWRITE area. I just haven't figured out what it is. Every combination of things I try either does nothing, hangs the GPU, or errors out.
04:27 mhenning: If you don't use that much, then are there other ways to return data from the mme to cpu code?
04:28 mhenning: and yeah, I wouldn't be surprised if we're missing some information on how it works
04:28 fdobridge: <j​ekstrand> Yeah, you can use `SET_REPORT_SEMAPHORE` from the MME to write out arbitrary data.
04:29 fdobridge: <j​ekstrand> That's how all the query stuff works currently.
04:29 fdobridge: <j​ekstrand> One of these days, I suspect we'll want to do it from a shader but I did it all in MME for now.
04:31 jekstrand: If you have more data to write, you might be able to set up some sort of DMA. IDK if there's a 3D engine DMA that can target arbitrary destination addresses, though.
04:33 mhenning: yeah, I wouldn't know either. I haven't paid too much attention to those parts of the hardware yet
04:34 mhenning:starts wondering if the mme can run doom
04:36 fdobridge: <j​ekstrand> 😂
04:38 fdobridge: <j​ekstrand> It is Turing complete except for the infinite part. I think you could theoretically compile Doom for it but you'd run into problems where the MME upload space isn't big enough.
04:48 mhenning: blast. foiled by program size issues again
04:49 mhenning: on the bright side, rendering things to the screen from the mme should be doable
20:36 fdobridge: <g​ouz> Hello all!
20:36 fdobridge: <g​ouz> I started the experimentation with base_instance support. I tried to pass it to the UBO through the MME. Some draw-instance tests seem to pass but i do not even know why 😄
20:36 fdobridge: <g​ouz> Even then the draw-indirect instanced cases do not seem to pass.
20:36 fdobridge: <g​ouz> https://gitlab.freedesktop.org/georgeouzou/mesa/-/commit/0e0b88028cbdc63923b17c8fc5c94f256ed35a75
20:39 fdobridge: <g​ouz> i believe i miss something about the LOAD_CONSTANT_BUFFER emits
23:14 mntirc: tagr: hi, i'm currently evaluating mainline on a xavier nx and found some of your work supporting gv11b in drm/mesa, was this ever finished / does it work nowadays?
23:52 mntirc: this hints at xavier being similar to desktop gpu/voltas? does mesa/nouveau just work if the drm plumbing is there? https://gitlab.freedesktop.org/mesa/mesa/-/commit/ff534e1b5066f1c8e7969f99f40ec080eee1b907