alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - - Logs - <daniels> avoiding X is a huge feature
* alyssa snores
* alyssa tries to remember what state panwrap/decode is in
stikonas_ has quit [Remote host closed the connection]
stikonas_ has joined #panfrost
stikonas_ has quit [Remote host closed the connection]
stikonas_ has joined #panfrost
stikonas_ has quit [Remote host closed the connection]
stikonas_ has joined #panfrost
stikonas_ has quit [Remote host closed the connection]
stikonas_ has joined #panfrost
stikonas_ has quit [Remote host closed the connection]
stikonas_ has joined #panfrost
memeka has joined #panfrost
stikonas_ has quit [Remote host closed the connection]
stikonas_ has joined #panfrost
<alyssa> Alright, I just sent off an MR for the new panwrap
<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)
<anarsoul> alyssa: did you get your rp64 fixed?
<alyssa> anarsoul: No..
<anarsoul> :(
<alyssa> No idea what happened either
<alyssa> Maybe electrostatic discharge or something?
stikonas_ has quit [Remote host closed the connection]
mifritscher has quit [Ping timeout: 257 seconds]
<alyssa> Just sent off a patch for "pantrace"
<alyssa> Which is like panwrap, but implemented inside Panfrost proper, so there's no LD_PRELOAD
<alyssa> Broadly, panwrap is for legacy drivers, pantrace is for modern Panfrost
<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)
<HdkR> Makes sense :)
<alyssa> Said patch was suuuper easy to write thanks to last night's work
Elpaulo has joined #panfrost
<HdkR> hm
<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.
_whitelogger has joined #panfrost
<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)
<HdkR> alyssa: If you can, just dissable it entirely and hope the performance isn't too bad? :P
<HdkR> Since early-z is purely a performance thing when enabled
<alyssa> HdkR: I mean yeah but it's just... fdsafkjdsa;f
<HdkR> lol
<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..
<HdkR> yep yep, errata do that
<HdkR> GPU vendors don't really speak about errata publicly :P
<alyssa> Sadly :P
<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
<HdkR> I find if funny that AMD and Intel both had bugs with ASTC5x5 though :D
<alyssa> I would just like an explanation of what a "heuristic bias" is :V
<alyssa> Ahhhhhhhhhhhhh
<alyssa> HdkR: There's _another_ errata that applies that I overlooked (from the same list, crossreferenced with the new kbase):
<alyssa> "T76X [and also T86X, it looks like] cannot disable use_discard even if depth and stencil are read-only"
<alyssa> It's possible the hw doesn't have working early-z at all \?
<alyssa> (If so, that'd be super awkward, but at least means I'm not doing anything dumb on my end)
<HdkR> Interesting
<alyssa> HdkR: I mean, how do you interpret that?
<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
<HdkR> Seems like it yes
<alyssa> Alright, case closed then :)
<alyssa> -----Where our perf is vanishing too is emphatically case _not_ closed, tho
<alyssa> Wait wait wait wait
<alyssa> I seem to have performance counters dumps where we (like, Panfrost) _is_ using early-z testing
<alyssa> So maybe I just regressed something? but that doesn't explain the above? Case reopend
<HdkR> The case of Who murdered early-z
* alyssa rolleyes
<alyssa> I wonder if I could bisect this sanely...?
<HdkR> early-z was such a great person. Who would of thought that they had enemies
* alyssa sniffles
<alyssa> How could she leave us?
<alyssa> We'll miss you, late-z
* alyssa forgot how much of a pain mesa is to bisect
rhyskidd has quit [Ping timeout: 246 seconds]
<alyssa> uihfguiadyfgeuakfgdsal
<alyssa> I was an old version of mdgperf-analyze
<alyssa> Early-z testing was being used all along
<alyssa> Argh!
<alyssa> What a rabbit hole.
<HdkR> :D
<alyssa> ....This still seems wrong
<alyssa> ......So I found a magic bit that causes performance to skyrocket?
<alyssa> It is not at all obvious what setting it does :p
<alyssa> Other than consistently boost framerates :p
<alyssa> (I.e. I now have Phong shaded bunny hitting 60fps vsync like it should)
<alyssa> (The second highest nibble in "tiler_meta")
mifritscher has joined #panfrost
<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]
<alyssa> Ultimately, it looks like we'll need to understand how the various tiler buffers work together..
pH5 has joined #panfrost
BenG83 has joined #panfrost
BenG83 has quit [Ping timeout: 240 seconds]
raster has joined #panfrost
rhyskidd has joined #panfrost
vakkov_ has joined #panfrost
BenG83 has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
vakkov_ has quit [Ping timeout: 246 seconds]
afaerber has joined #panfrost
vakkov_ has joined #panfrost
vakkov_ has quit [Ping timeout: 244 seconds]
<cwabbott> alyssa: your thing seems to be working... at least, it outputs a bunch of stuff
<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
<cwabbott> like, one job will overwrite the memory of a previously completed job
<cwabbott> also, the android image on Lyude's device actually has tar, which I'm pleasantly surprised by
<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
raster has quit [Ping timeout: 255 seconds]
raster has joined #panfrost
raster has quit [Ping timeout: 268 seconds]
<Lyude> cwabbott: note, I've got the n2 now too
<cwabbott> Lyude: HdkR sent one to me too
<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...
<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.
<cwabbott> alyssa: a lot of the tests are "write something to FBO, wait for that to complete, then write to system framebuffer"
<cwabbott> in that case they tend to overwrite the FBO job with the system job
<alyssa> Blugh, yeah, okay, I'll fix it when I get time (this evening or tomorrow afternoon, probably)
<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?
* HdkR feels a larabel post coming
* cwabbott too
<cwabbott> what happens when I start sending patches to decode some bifrost thingy
<cwabbott> but I guess upstreaming it is okay
<cwabbott> I did have some changes to the original disassembler for handling 64-bit clauses
* alyssa class
<Lyude> cwabbott: nice!
raster has joined #panfrost
stikonas has joined #panfrost
afaerber has quit [Quit: Leaving]
raster has quit [Remote host closed the connection]
<HdkR> Nice tweet from Robert Foss :D
raster has joined #panfrost
raster has quit [Read error: Connection reset by peer]
pH5 has quit [Quit: bye]
BenG83 has quit [Read error: Connection reset by peer]
<alyssa> HdkR: Oh, awesome :)