00:05 dwlsalmeida[d]: mohamexiety[d]: ah right, I had already asked that
00:06 dwlsalmeida[d]: I am using Dave's old branch for now, which predates `nvkmd`, but I guess the main problem is that you seem to need a `nvk_device_memory` ?
00:06 dwlsalmeida[d]: ( which I assume to be what the first arg `nvkmd_mem` is)
00:07 mohamexiety[d]: There should be an alternative to it in the old API so the same principle applies I _think_ :thonk:
00:08 mohamexiety[d]: As for needing a memory object, yeah but you already have to have one to create the buffer right?
00:08 dwlsalmeida[d]: no, that's the problem
00:08 dwlsalmeida[d]: I am looking for the nouveau bo backing the buffer and I can't find it
00:09 dwlsalmeida[d]: maybe I am just tired lol
00:09 mohamexiety[d]: Yeah that’s interesting 😮
00:09 dwlsalmeida[d]: all you have is `buffer->addr`
00:17 dwlsalmeida[d]: btw, I noticed that all failures were in macroblocks located on the lower right side, so I added a constant to `_nvdec_h264_pic_s::stream_len`, and the problem is gone
00:17 dwlsalmeida[d]: 100% match
00:18 dwlsalmeida[d]: I have 0 idea what is going on, so dumping and comparing will probably be helpful. It also fixed other videos too
00:18 dwlsalmeida[d]: no idea why this doesn't fault either
00:23 dwlsalmeida[d]: airlied[d]: 56/135 fluster score on the JM test suite, for something that had absolutely 0 vectors passing, things are moving forward here
01:39 airlied[d]: we don't track the backing store for buffers, you'd have to add tracking for it to debug it
01:50 airlied[d]: have to work out where the stream_len is going wrong, might be some padding needed
01:52 dwlsalmeida[d]: It’s already padded to 256
01:52 dwlsalmeida[d]: Plus the extra 256 I have now added on top
01:53 dwlsalmeida[d]: No way to know before we dump what’s in the buffer, I’ll work on that next
01:54 dwlsalmeida[d]: Apparently error code 40 is out of data then
03:27 gfxstrand[d]: airlied[d]: Oh, there's already a clever trick for that. Look at the buffer bind code and the command buffer dumping code. If you set a flag, you can ask the nvkmd_device to map by GPU address.
03:28 gfxstrand[d]: I got tired of device generated commands being undumpable so I fixed that. 😁
03:45 gfxstrand[d]: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/nouveau/vulkan/nvk_buffer.c?ref_type=heads#L245
03:46 gfxstrand[d]: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/nouveau/vulkan/nvk_cmd_buffer.c?ref_type=heads#L1108
03:46 gfxstrand[d]: Just make sure you unref so you don't leak mems
09:50 mohamexiety[d]: Ooh that’s super cool and useful
19:29 gfxstrand[d]: Yeah, DGC was impossible to debug without it. There are still a few valid cases where the debug output would still be wrong but they're pretty unlikely.
19:31 gfxstrand[d]: The client would have to prepare commands, execute them, the product and execute again using the same memory in the middle of a single command buffer.
19:32 gfxstrand[d]: Even then, we could handle that case if we tried hard enough. It's just enough of an edge case that I kinda don't care.