01:05 <alyssa> Alright, I just sent off an MR for the new panwrap

01:05 <alyssa> I'm debating if I want to write support for generating traces _directly_ from panfrost (bypassing the need for panwrap at all when we're using sufficiently new panfrost -- which is good, because panwrap is always a little finicky)

01:06 <anarsoul> alyssa: did you get your rp64 fixed?

01:06 <alyssa> anarsoul: No..

01:06 <anarsoul> :(

01:07 <alyssa> No idea what happened either

01:07 <alyssa> Maybe electrostatic discharge or something?

03:45 <alyssa> Just sent off a patch for "pantrace"

03:45 <alyssa> Which is like panwrap, but implemented inside Panfrost proper, so there's no LD_PRELOAD

03:46 <alyssa> Broadly, panwrap is for legacy drivers, pantrace is for modern Panfrost

03:46 <alyssa> This will be especially good when we implement the DRM driver (since we don't need to port panwrap to get the equivalent functionality)

03:46 <HdkR> Makes sense :)

03:47 <alyssa> Said patch was suuuper easy to write thanks to last night's work

03:54 <HdkR> hm

03:56 <HdkR> cwabbott: Do you have a Hardkernel emmc reader? Might be difficult to write an image to the included eMMC. I could burn the default Ubuntu image on to it for you.

04:19 <alyssa> So, the bit I labeled "MALI_NO_ALPHA_TO_COVERAGE" is very clearly the "use early-z test" bit... the fact that the hardware disagrees heavily suggests there's an errata at play (and there is -- this hardware has a documented errata about early-z but I can't decipher what it means)

04:25 <HdkR> alyssa: If you can, just dissable it entirely and hope the performance isn't too bad? :P

04:26 <HdkR> Since early-z is purely a performance thing when enabled

04:37 <alyssa> HdkR: I mean yeah but it's just... fdsafkjdsa;f

04:37 <HdkR> lol

04:37 <alyssa> In the Midgard public optimization manuals, there's a list of conditions where early-z can't run... this is not in the list..

04:38 <HdkR> yep yep, errata do that

04:38 <HdkR> GPU vendors don't really speak about errata publicly :P

04:41 <alyssa> Sadly :P

04:42 <HdkR> Intel is pretty open about them and there are a lot of things about it on AMD. Not sure if either have a list of hardware errata though

04:42 <HdkR> I find if funny that AMD and Intel both had bugs with ASTC5x5 though :D

04:42 <alyssa> I would just like an explanation of what a "heuristic bias" is :V

04:51 <alyssa> Ahhhhhhhhhhhhh

04:51 <alyssa> HdkR: There's _another_ errata that applies that I overlooked (from the same list, crossreferenced with the new kbase):

04:51 <alyssa> "T76X [and also T86X, it looks like] cannot disable use_discard even if depth and stencil are read-only"

04:52 <alyssa> It's possible the hw doesn't have working early-z at all \?

04:52 <alyssa> (If so, that'd be super awkward, but at least means I'm not doing anything dumb on my end)

04:53 <HdkR> Interesting

04:54 <alyssa> HdkR: I mean, how do you interpret that?

04:55 <alyssa> We know that early-z is disabled when the shader does a discard op, so if the hardware can't disable "use_discard" -- which I guess is the flag we call MALI_CAN_DISCARD -- then presumably it can't _enable_ early-z either

04:57 <HdkR> Seems like it yes

04:59 <alyssa> Alright, case closed then :)

04:59 <alyssa> -----Where our perf is vanishing too is emphatically case _not_ closed, tho

05:05 <alyssa> Wait wait wait wait

05:05 <alyssa> I seem to have performance counters dumps where we (like, Panfrost) _is_ using early-z testing

05:06 <alyssa> So maybe I just regressed something? but that doesn't explain the above? Case reopend

05:07 <HdkR> The case of Who murdered early-z

05:08 <alyssa> I wonder if I could bisect this sanely...?

05:08 <HdkR> early-z was such a great person. Who would of thought that they had enemies

05:09 <alyssa> How could she leave us?

05:09 <alyssa> We'll miss you, late-z

05:39 <alyssa> uihfguiadyfgeuakfgdsal

05:40 <alyssa> I was an old version of mdgperf-analyze

05:40 <alyssa> Early-z testing was being used all along

05:40 <alyssa> Argh!

05:40 <alyssa> What a rabbit hole.

05:40 <HdkR> :D

05:43 <alyssa> ....This still seems wrong

06:35 <alyssa> ......So I found a magic bit that causes performance to skyrocket?

06:36 <alyssa> It is not at all obvious what setting it does :p

06:36 <alyssa> Other than consistently boost framerates :p

06:36 <alyssa> (I.e. I now have Phong shaded bunny hitting 60fps vsync like it should)

06:37 <alyssa> (The second highest nibble in "tiler_meta")

07:14 <alyssa> [Meanwhile, it regresses a ton of stuff to set it in nonobvious ways. Symtoms include nondeterministic faulting and vertices being stuck to (0, 0) in STK]

07:14 <alyssa> Ultimately, it looks like we'll need to understand how the various tiler buffers work together..

14:43 <cwabbott> alyssa: your thing seems to be working... at least, it outputs a bunch of stuff

14:44 <cwabbott> how do you deal with multiple jobs, when one job overwrites the memory of a previous one? I've definitely seen that for some more complicated tests

14:45 <cwabbott> like, one job will overwrite the memory of a previously completed job

14:46 <cwabbott> also, the android image on Lyude's device actually has tar, which I'm pleasantly surprised by

14:50 <cwabbott> alyssa: seems like we need to keep track of how many jobs we've submitted, and replay_memory() needs to create a different memory file for each submission

16:21 <Lyude> cwabbott: note, I've got the n2 now too

16:23 <cwabbott> Lyude: HdkR sent one to me too

16:27 <alyssa> cwabbott: I was trying to ignore that part, since I was assuming thanks to pipelining, for a single-frame test the blob couldn't overwrite memory anyway, but...

16:27 <alyssa> Yeah, I guess we'll need to version memory files. Shouldn't be too hard to layer that capability on top of what's already there.

16:28 <cwabbott> alyssa: a lot of the tests are "write something to FBO, wait for that to complete, then write to system framebuffer"

16:28 <cwabbott> in that case they tend to overwrite the FBO job with the system job

16:28 <alyssa> Blugh, yeah, okay, I'll fix it when I get time (this evening or tomorrow afternoon, probably)

16:29 <alyssa> As an aside: Do you want me to upstream the Bifrost disassembler (well, HdkR's fork of it) so that works in pandecode as well?

16:31 <cwabbott> what happens when I start sending patches to decode some bifrost thingy

16:31 <cwabbott> but I guess upstreaming it is okay

16:32 <cwabbott> I did have some changes to the original disassembler for handling 64-bit clauses

16:35 <Lyude> cwabbott: nice!

20:27 <HdkR> Nice tweet from Robert Foss :D

23:34 <alyssa> HdkR: Oh, awesome :)