00:37 <NightsOnly[m]> hmmm, i managed to get it compiled and installed with ninja install. Although i am somewhat confused on how to get it working?

00:37 <NightsOnly[m]> like, how do i attempt to use it and have something crash so i can figure out what needs implementing?

01:30 <chadmed> DYLD_INSERT_LIBRARIES=/path/to/your/compiled/libGL.1.dyld then run whatever opengl program you want to profile

01:32 <chadmed> you should keep in mind that virtually all opengl software for macos is going to be built for and linked against amd64 libraries, so they will not accept your arm64 mesa libGL. alyssa has been using the dEQP conformance tests since you can build them yourself.

01:37 <chadmed> the Metal shader examples are just used to get memory dumps of data structures to see how the hardware expects things like textures to be presented to it for processing, since we can assume that Apple's Metal libraries do this the "correct" way for the hardware. that information is then used to teach mesa how to do the same thing for GLES shader programs

02:30 <phire> right, I'm writing up an infodump for you marcan

02:31 <phire> you still interested at looking into gpu stuff today?

04:59 <phire> https://github.com/phire/m1n1/blob/gpu-RE/phire-gpu-infodump.md

08:28 <sven> endpoint 0x1 is probably the normal rtkit crashlog

08:36 <phire> thanks. Prehaps I should be trying harder to crash it

08:46 <sven> just send 0x40 or 0x22 to it and it should crash

08:47 <sven> https://github.com/AsahiLinux/m1n1/blob/41f0874f9999d2ac95ef5418dfae4fdd42cdc507/proxyclient/m1n1/fw/asc/crash.py#L137

08:48 <sven> weird that gfx-asc can essentially get access to every page

08:48 <phire> yes, it's very privliaged

08:57 <phire> oh... thank you crashlog and your very creative endpoint naming scheme of "user01" and "user02"

08:58 <phire> RTKit Task List: rtk_ep_work, power, agx_background, agx_recovery, agx_interrupt, agx_power, agx_sampler

10:11 <phire> forcing crashes hasn't told me that much

10:13 <phire> ep 0x21 crashes when you send it message types it doesn't exist, but doesn't seem to do any checking on the args to the 0x83 message

10:13 <phire> EP 0x20 doesn't seem to crash no matter what you send it

10:15 <phire> well, unless you do something stupid like senting a null pointer on it's init data

10:16 <phire> GFX PANIC - Unable to grab init data from host - agx_background(2)

11:27 <marcan> phire: the kick via ASC plus shared memory ring buffer/work queue pattern is used for DCP, so finding one of those somewhere wouldn't surprise me as a work submission mechanism

11:27 <marcan> *via mbox

11:30 <phire> yeah, sounds right

11:30 <phire> and way more sane than my other theories

11:30 <phire> though the DCP ASC looks nothing kike the GFX ASC. I doubt they are related

11:31 <marcan> I mean the general idea

11:31 <marcan> obviously GFX does not use EPIC nor that bizarro dcpep thing

11:31 <marcan> but e.g. the kick stuff is also kinda how syslog works

11:32 <phire> yeah, the general idea

11:39 <phire> I'm current mapping out this "init data" struct

11:40 <phire> if there is an address to a shared memory queue, it should be there

11:43 <marcan> I would expect at least a few global queues and then possibly some per-context stuff or similar

11:43 <marcan> the latter could be dynamically allocated via global messages

11:44 <phire> yeah, I haven't even tried to look for the per-context stuff, because I assume there needs to be a global queue to set the context

11:44 <phire> GFX PANIC - Host-mapped FW allocations are disabled, but FW only supports enabled (init_data_addr=0xffffffa0000b0000)! - agx_background(2)

11:45 <phire> that's an interesting panic

11:45 <marcan> heh

11:45 <marcan> it's also possible the GPU allocates the queues btw, and updates the structure or something

11:46 <phire> monitoring doesn't show any updates to this structure

12:49 <alyssa> phire: Keep in mind that WindowServer renders everything via Metal internally

12:50 <alyssa> so unless you're doing all this headless, the "is Metal in use?" piece is questionable

12:50 <alyssa> (Maybe you *are* doing it headless, though?)

12:51 <phire> what I mean is that I've only seen in while running the metal spinning cube example, not during login or on the desktop

12:52 <alyssa> ok.. my point is that login and the desktop are both using the GPU heavily

12:52 <alyssa> (and that there will be kicks and work submitted from those too)

12:53 <phire> yes... I agree it is odd that only that example would cause them

12:54 <alyssa> phire: It might be worth it to run a metal compute kernel test over SSH with no display connected (lid closed for the laptop, I guess)

12:54 <alyssa> signal:noise ratio might be better for finding the kick

12:55 <phire> hmm, lid closed might work

13:01 <phire> well... m1n1 crashes if I boot when the lid closed

13:03 <phire> did stop most of the kicks. I think it still drew the white apple logo

13:08 <marcan> phire: that's because it goes into suspend

13:08 <marcan> you need to disable that

13:08 <phire> in macos settings?

13:08 <marcan> yes, I think that should work

13:08 <marcan> you could also just turn off the screen

13:08 <marcan> I think setting the brightness to 0 should stop display updates, but it shouldn't suspend

13:18 <phire> setting the "prevent sleep when display off" option didn't stop it from sleeping

13:19 <phire> and setting zero brightness doesn't prevent rendering

13:22 <phire> this apparently works: ssh in, then close the lind

13:22 <phire> s/lind/lid/

13:56 <alyssa> funny

15:11 <phire> Alright, I've found a set of circular buffers

15:11 <alyssa> :D