03:24 <i509vcb> Lynne: Company: Depends what you want for traces, renderdoc I think allows manually signalling start and end of a command submission. There is also the VK_LAYER_LUNARG_api_dump layer

03:25 <i509vcb> That layer just dumps every function call to the driver to stdout

03:26 <Company> GTK has a file format for its drawing commands, so you can dump the whole window rendering calls to a file and load them back to replay them

03:26 <Company> we also have tools to edit them, replay them to a file etc

03:27 <Company> so whenever I have a bug, I can just bisect in the GTK format - and once I'm done I'd like to generate a minimal Vulkan/GL dump for filing issues or having others look at

03:29 <Company> might be worthwhile to add renderdoc support for our replay tool - or even add an instruction that generates renderdoc output

03:31 <HdkR> gfxreconstruct also lets you assign a global hotkey hook which is nice

03:34 <Company> I wonder how hard it'd be to have a gtk4-rendernode-tool gfxreconstruct input.node output.gfxr

03:36 <Company> because that stuff seems really nontrivial to use

03:36 <Company> which sucks for casual users

07:26 <mediaim> https://shanetully.com/2013/12/writing-a-self-mutating-x86_64-c-program/ such a hack basically was something that i thought about, I am not yet skilled enough, i understand that event loop ends with jumping back to do the poll again though. And that there is a way to manipulate the blocking to return -1, so you get two code paths, blocking code path and the success code path.

07:52 <mediaim> i think further enhancements can be done with making read(2) buf to execute function pointer from a lib, then marking a new strong definition of whatever the function pointer from library was called, to merge it into pc-relative binary, through linker that deals with loads and call sites. And then trace those functions by pointing something to them too.

16:07 <vdavid003[m]> Hi, this is kinda not related to DRI at all, just simply linux driver dev, but I was directed here for my question, so I'll try anyways.... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/MzYZKJhJgFfxAfrnXMiJuPrw>)

17:37 <mediaim> Over the web they say, immediate pointers is c99 thing, works in asm too though, but instead of calling the whole linker twice like suggested before, it's also possible to have a small machine code parser, very tiny that when print is done rewrites the load addresses, those would make easier to isolate the case, pointer value dereferences can point to the code at pass two. Though combined pass is better like nested loop. I finished with event loops, bu

17:37 <mediaim> now testing how to feed things to solvers. Practicing but goes ok.

17:52 <mediaim> That's however a battle we know we'll win. We put computers to make computation like they were intended to, if someone wants to pay for the effort of development would be bonus, but not strict necessity, we'll get there shortly anyways.

18:50 <DemiMarie> vdavid003: Possibly a `dma_alloc_coherent()` problem, but it could also be that other hardware in the SoC has its own caches that need to be invalidated. I’d just allocate normal (cacheable) memory and insert the appropriate cache flushes.

18:52 <DemiMarie> Disclaimer: I’ve never used such an SoC myself, much less written a driver for one. I’m just going off of the mailing list conversations I have read.

20:36 <mareko> dcbaker: do you mean wayland-protocols?

20:38 <dcbaker> mareko: I tagged the wrong person, I meant markco, sorry