ChanServ changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs https://oftc.irclog.whitequark.org/panfrost - <macc24> i have been here before it was popular
<icecream95>
why is this "fragment shader" just ld_attr/lea_attr/st_cvt?
<icecream95>
maybe i'm allocating BOs wrong or something
<icecream95>
..and the "vertex" shader does a BLEND. I guess they were meant to be swapped around?
<icecream95>
I'm slightly concerned that the vertex job managed to execute fine. I wonder what it blended to...
<icecream95>
I so want to open up the blob in Ghidra to find out why it is doing this
camus has quit []
<icecream95>
More odd things: Why is there an eos clause that is obviously not the end of the shader (this is with a different glmark2 test)?
<alyssa>
icecream95: all of these raise so many questions
<alyssa>
details please :'o
<alyssa>
Speculation -- is this an indexed driver shading?
<alyssa>
So your "fragment shader" is actually the varying shader (doing a passthrough `vary = attr`), your "vertex" shader is the fragment shader, and there is a position shader somewhere else.
<alyssa>
The XML could have the two swapped, I could never get IDVS working on panfrost but I also could never get the g52 blob to do it at all so I assumed it was just broken
<alyssa>
Doing a +BLEND in a vertex shader ought to provoke an INSTR_INVALID_ENC fault, though I've never tested it lol
<alyssa>
eos not in the end of the shader, uhm, is this glmark2 -bloop maybe? and it's an early exit?
<alyssa>
the LLVM drivers compile while loops more efficiently than NIR drivers, so there's that
<alyssa>
(LLVM does `if cond { do { ... } while (cond)` whereas NIR implements it directly. That means LLVM does 1 branch [amortized] per iteration, where NIR needs 2.)
<alyssa>
[If the swapped shader thing is IDVS, i'd be curious to see what the nonsensical trace looks like]
camus has joined #panfrost
<icecream95>
This was with desktop and ideas. Some of the other tests (eg build, refract) do run normally
<icecream95>
All of the dEQP tests I've tried fail in similarily weird ways tho none caused faults
<alyssa>
Curious. This is running against a panfrost kernel over the network, or...?
<icecream95>
no network involved but panfrost.ko
<alyssa>
ack
<icecream95>
(I'm currently RiiRing the network stuff)
<alyssa>
naturally
robmur01_ has joined #panfrost
<icecream95>
Maybe it work more reliably if I put the kbase->panfrost shim in the kernel
robmur01 has quit [Read error: Connection reset by peer]
jernej_ has joined #panfrost
jernej has quit [Ping timeout: 480 seconds]
hanetzer has joined #panfrost
rcf has quit [Quit: WeeChat 3.1]
rcf has joined #panfrost
rando25892 has joined #panfrost
rando25902 has quit [Ping timeout: 480 seconds]
Lyude has quit [Quit: WeeChat 3.2]
Lyude has joined #panfrost
Daanct12 has quit [Quit: Quitting]
Danct12 has joined #panfrost
rasterman has joined #panfrost
jernej_ is now known as jernej
rasterman has quit [Quit: Gettin' stinky!]
<icecream95>
alyssa: Since you keep complaining about IDVS, I'll have a go trying to implement it now
* icecream95
wonders what the magic value used in IDVS position stores does
<icecream95>
For example: +ST_CVT.v4 t1, r58. r59, 0x0105e688, @r8
<icecream95>
it doesn't seem like it could be interpreted as an address
<icecream95>
Ohhh.. So it's a format, isn't it
<icecream95>
I always wondered why ST_CVT required three address components, now I know
<icecream95>
Though why is bit 24 set?
<daniels>
icecream95: er, bit 24? it's not that wide ...
<icecream95>
daniels: This is in the 32-bit constant used in the ST_CVT instruction (where the lower bits store a format)