stikonas has quit [Remote host closed the connection]
stikonas has joined #panfrost
raster has quit [Quit: Gettin' stinky!]
stikonas has quit [Remote host closed the connection]
kaspter has joined #panfrost
icecream95 has joined #panfrost
bbrezillon has quit [Ping timeout: 256 seconds]
vstehle has quit [Ping timeout: 260 seconds]
kaspter has quit [Ping timeout: 264 seconds]
kaspter has joined #panfrost
camus1 has joined #panfrost
kaspter has quit [Ping timeout: 264 seconds]
camus1 is now known as kaspter
italove has joined #panfrost
italove has quit [Ping timeout: 256 seconds]
<HdkR>
I see all these Bifrost commits coming in. Keep up the good work! :D
<archetech>
\o/
archetech has quit [Quit: Konversation terminated!]
archetech has joined #panfrost
Green has joined #panfrost
<SolidHal>
ahhhh "Purging %lu bytes" is from panfrost_gen_shrinker.c
<SolidHal>
*panfrost_gem_shrinker.c
<SolidHal>
any clue why it is an info level message?
<chewitt>
because someone forgot to make it something else?
<SolidHal>
it doesn't even label itself as panfrost :/
<SolidHal>
scared me for a sec
<chewitt>
it's not the worst thing I see in dmesg :)
<SolidHal>
oh certainly not, I see some nice errors from panfrost on 5.9.7 that I didn't on 5.9.4 and graphical glitches to go with them. The purging messages were more just confusing
camus1 has joined #panfrost
kaspter has quit [Ping timeout: 264 seconds]
camus1 is now known as kaspter
_whitelogger has joined #panfrost
rak-zero has joined #panfrost
italove has joined #panfrost
davidlt has joined #panfrost
vstehle has joined #panfrost
kaspter has quit [Ping timeout: 264 seconds]
camus1 has joined #panfrost
camus1 is now known as kaspter
kaspter has quit [Ping timeout: 265 seconds]
kaspter has joined #panfrost
rando25892 has quit [Ping timeout: 256 seconds]
rando25892 has joined #panfrost
kaspter has quit [Ping timeout: 256 seconds]
kaspter has joined #panfrost
icecream95 has quit [Ping timeout: 260 seconds]
raster has joined #panfrost
camus1 has joined #panfrost
kaspter has quit [Ping timeout: 256 seconds]
camus1 is now known as kaspter
italove has quit [Quit: Lost terminal]
camus1 has joined #panfrost
kaspter has quit [Ping timeout: 256 seconds]
camus1 is now known as kaspter
<tomeu>
there was some patch in lkml addressing this, I don't know what the conclusion was
stikonas has joined #panfrost
<tomeu>
alyssa: apparently a newer CTS manages to crash panfrost in these tests: dEQP-GLES2.functional.shaders.indexing.tmp_array.float_const_write**
<tomeu>
but only on midgard
stikonas has quit [Remote host closed the connection]
stikonas has joined #panfrost
camus1 has joined #panfrost
kaspter has quit [Ping timeout: 256 seconds]
camus1 is now known as kaspter
rak-zero has quit [Ping timeout: 258 seconds]
gcl_ is now known as gcl
kaspter has quit [Ping timeout: 265 seconds]
bbrezillon has joined #panfrost
<alyssa>
SolidHal: it does seem to slow things down, it's not the end of the world but not a good thing and ideally we wouldn't be hitting it in normal use
<alyssa>
tomeu: hm, crash how/
alpernebbi has joined #panfrost
archetech has quit [Quit: Leaving]
<tomeu>
alyssa: no idea, sorry, just saw it in CI when deqp was updated
<dstzd>
is there an easy way to make sure card0 is rockchip-drm and card1 is panfrost? they seem to be reverse on my system. is it like that for anyone else?
<macc24>
dstzd: is it bad?
<macc24>
/dev/dri/by-path still exists
<dstzd>
i don't think so but i'm trying to get the hardware video decode patches going on my system and i'm having some difficulty
<urjaman>
build the rockchip driver into the kernel and load panfrost as a module
<dstzd>
it's probably just mpv being stupid though
<dstzd>
ah thats probably it. when they are both builtins p comes before r
<alyssa>
I wonder what other yaks I can shave this morning to avoid the all-consuming existential dread of scheduling clauses.
archetech has quit [Quit: Leaving]
robmur01_ is now known as robmur01
<robmur01>
why, full SFBD support of course! :P
<alyssa>
>:p
archetech has joined #panfrost
<alyssa>
robmur01: what support are you missing
<alyssa>
ES2 basically works on t720
kaspter has joined #panfrost
<dstzd>
SFBD?
<alyssa>
t6xx and t720
<alyssa>
I feel sick.
kaspter has quit [Quit: kaspter]
nlhowell has joined #panfrost
<alyssa>
Okay, this might be a wild idea, but - what if we tried to schedule a (generalized) clause optimally?
<alyssa>
Since Bifrost mandates no more than one message-passing passing instruction per clause, stage 1 of the scheduler just schedule message passing instructions, with the in between to be 'filled in' later.
<alyssa>
Stage 1 acts on a given basic block.
<alyssa>
Stage 2 then, filling in the clause, is only interested in the subset of instructions that can actually be scheduled between the two adjacent message-passing instructions.
<alyssa>
You _can_ construct edge cases where the program does no control flow and no input/output except the very beginning and very end and just does huge amounts of ALU in between, but..
<alyssa>
That seems kinda unlikely for real world shaders (*citation needed)
archetech has quit [Quit: Leaving]
<alyssa>
Again, a priori checking every possible instruction sequence is exponential.
<alyssa>
But Bifrost is so heavily constrained that the set of options probably small at every step, and given the above clause structure, the problem space is significantly smaller than the whole program.
<alyssa>
For a slight tradeoff, we can bound the search at the clause boundary, so we end up searching no more than 16 layers deep (rather than arbitrarily many -- no matter how much consecutive ALU you do, 16 is the recursion limit so to speak)
<alyssa>
And you can still bound the solution set at checking the best N options instead of all N options, another tradeoff between greedy (setting N=1) and fully optimal (unbounded)
<alyssa>
But... if N = 4, then this already allows for a single clause to require 4**16 = 4 billion steps
<alyssa>
So maybe it is unfeasible after all. Oh well. It'll make for fun experimentation later, and of course this sort of tuning doesn't affect any of the formal issues.
archetech has joined #panfrost
<archetech>
closer
<archetech>
oops not in armbian
archetech has quit [Quit: Leaving]
archetech has joined #panfrost
deuteragenie has joined #panfrost
<deuteragenie>
This scheduling problem smells like a CSP problem. Maybe it can be modeled in MiniZinc for example ?
<deuteragenie>
I suppose that it can be solved efficiently by bed and breakfast.
<robmur01>
alyssa: the most obvious one is that glmark2-es2 -bshadow still segfaults on t620 - IIRC we've still just got an assert in lieu of some required functionality for that
<deuteragenie>
Otherwise, feed the model into an ILP solver. But then what are the performance expectations ?
<robmur01>
but yeah, get on with the stuff that actually matters first :D
deuteragenie has quit [Ping timeout: 256 seconds]
deuteragenie has joined #panfrost
<alyssa>
deuteragenie: when all else fails, feed things into an ILP sovlver indewed :p
<robmur01>
alyssa: well, that at least gets as far as an assertion now - midgard_pack.h:30: v<=max
<robmur01>
coming from panfrost_emit_frag_shader
<bbrezillon>
macc24: dunno, as I said, I just added a few hacks to make it work and informed the people in charge of upstreaming this code about those problems
<alyssa>
robmur01: ugh..
<alyssa>
That's one of those useless "well you got something wrong!" errors
<alyssa>
no change you can get a backtrace to the caller in midgard_pack.h?
<alyssa>
chance
<robmur01>
pan_cmdstream.c:542
<alyssa>
oh wait
<robmur01>
(sorry, can't copy-paste off the TV on the other side of the room...)
<alyssa>
ok try now
<alyssa>
and now let's get back to scheduling
<alyssa>
curse you nerd sniper :p
* HdkR
lines up the shot
<robmur01>
well you did ask! :P
<alyssa>
you brought it up!
<alyssa>
HdkR: mathematicians are 3 points
<HdkR>
Programmers must be 1 then, since there are so many :P
<robmur01>
woo, now it runs like it used to - still doesn't actually render the shadow, but hey :D
<robmur01>
meanwhile, dEQP has finished cloning... >:)
<alyssa>
>::::
<alyssa>
:p
<alyssa>
taking that as a t-b
<alyssa>
!7557
<robmur01>
absolutely - thanks!
<alyssa>
😏
<robmur01>
and fortunately, dEQP doesn't seem to want to build on Arch... (complains it can't find something that's supposedly installed)
<alyssa>
I'm not sure why T720 never hit that, actually.
<robmur01>
hmm, although on a full run a bunch of other stuff has now gone wonky - terrain is completely flat, and on function, loops and conditionals only a small part of the bottom of the screen actually shows anything
<robmur01>
maybe park it as WIP for now - I should rustle up a T720 for comparison, and get this all logged in a proper issue