<chewitt>
these are things I've accumulated from comments here and patches submitted to LKML with "panfrost" in the name
<chewitt>
(scroll back a couple of pages to find the 5.12-rc1 commit and work up from there)
<chewitt>
i'm concerned that most of the patches missed the 5.12 merge window
<chewitt>
as I see a lot of conflicts in various board vendor and distro forums between users experimenting with panfrost and maintainers who loathe patches
<chewitt>
i.e. right now the patches are prob. needed but aren't being added, so the panfrost experience suffers
<chewitt>
my tree seems to be used/raided by a few people these days so I'd like to validate the panfrost related bits are correct :)
camus has joined #panfrost
kaspter has quit [Remote host closed the connection]
camus is now known as kaspter
<bbrezillon>
alyssa: thank you. The faults you see are caused by my code, not yours, debugging it right now...
<bbrezillon>
chewitt: it looks good to me at first glance
<chewitt>
bbrezillon please take a long/second glance :)
guillaume_g has joined #panfrost
camus1 has joined #panfrost
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #panfrost
camus1 has quit [Ping timeout: 245 seconds]
camus1 has joined #panfrost
kaspter has quit [Ping timeout: 245 seconds]
camus1 is now known as kaspter
nlhowell has joined #panfrost
raster has joined #panfrost
warpme_ has joined #panfrost
karolherbst has joined #panfrost
ente has quit [Ping timeout: 246 seconds]
ente has joined #panfrost
stikonas has joined #panfrost
ente has quit [Ping timeout: 246 seconds]
chewitt has quit [Read error: Connection reset by peer]
chewitt has joined #panfrost
chewitt has quit [Read error: Connection reset by peer]
<macc24>
umm, minecraft bedrock edition broke on g72
<macc24>
it just started heavily stuttering for no reason at random times
chewitt has joined #panfrost
<macc24>
especially when there's a lot of particles involged
robmur01_ is now known as robmur01
chewitt has quit [Read error: Connection reset by peer]
chewitt has joined #panfrost
<tomeu>
macc24: anything in dmesg?
<macc24>
tomeu: nothing that suspicious
<tomeu>
hrm
<tomeu>
macc24: are you planning to bisect?
<macc24>
tomeu: yes
<tomeu>
cool, hopefully we will have soon some machines with g72 in CI
<macc24>
like a month ago it was fine
<alyssa>
bbrezillon: ack, one thing I don't understand is what the +0x200 loads are about
<alyssa>
unsure if that'll trash the cache, I guess if you have the right number of threads it's fine
<alyssa>
still deserves a comment
alpernebbi has joined #panfrost
<bbrezillon>
alyssa: 128 threads, each of them loading 4 bytes
<alyssa>
right, ok
<alyssa>
same as the DDK then..?
<bbrezillon>
yep
<alyssa>
fair enough.
<bbrezillon>
min max search is much faster no, but I seem to have a corruption on dEQP-GLES31.functional.draw_indirect.draw_elements_indirect.indices.index_int when I run the all indirect draw tests sequentially
<bbrezillon>
s/no/now/
<alyssa>
:|
<bbrezillon>
alyssa: job exception status field is supposed to be updated when the job is done, not when the whole chain is done, right?
<alyssa>
bbrezillon: I believe so.
<macc24>
according to git bisect 2bd2a03657b0289dc745324f700c99bfe13ebd0f broke minecraft ,_,
jwalts has joined #panfrost
<tomeu>
macc24: but that commit should only affect midgard
<macc24>
tomeu: yes, i know
<tomeu>
maybe the bug doesn't reproduce in 100% of the runs?
<macc24>
it does
<macc24>
it was constantly bad and now i'm looking when did i clone 32bit mesa on my duet
<bbrezillon>
alyssa: hm, for some reason the GPU faults on the vertex job, but none of the min-max-index-search and indirect-draw jobs have been executed (the vertex job has a dep on the indirect draw job, which has a dep on the min-max one)
<macc24>
i bisected the wrong tree ,_,
<alyssa>
bbrezillon: Is the ordering of jobs correct?
<alyssa>
Jobs need to be in a topological sort of the dep graph, otherwise deps are ignored.
<alyssa>
In other words, the hardware logic is "if we have processed a job with index dep_1, wait for it"
<alyssa>
but if you wait on a job that doesn't exist, nothing happens, and if you have something like "job 1, dep 2 ---> job 2", there's no dep either, it _has_ to be "job 2 --> job 1, dep 2"
sammwch has joined #panfrost
heddwch has quit [Ping timeout: 264 seconds]
sammwch is now known as hrddwkh
hrddwkh is now known as heddwch
<bbrezillon>
alyssa: yep, they are
<bbrezillon>
anyway, I think I just found the problem (off-by one in the min-max search logic)
<alyssa>
macc24: that'd do it
<alyssa>
bbrezillon:
<macc24>
alyssa: how do you make a typo across 2 keys lol
heddwch has quit [Disconnected by services]
<alyssa>
icecream95: no idea
<alyssa>
macc24: ^^
<jwalts>
I have a simple fragment shader that fails NIR validation after glsl_to_nir, is there someone I should ping? I reduced it to just "outFrag = ( mat2(v) - mat2(1.) )[0]"
<alyssa>
does it happen with !panfrost?
<jwalts>
I've just reproduced it with the bifrost_compiler, yes
<macc24>
brb, writing !panfrost driver
<alyssa>
bifrost is panfrost
<jwalts>
oh, with not panfrost you meant, sorry. yes it does
<italove>
it seems that the original MR failed CI again, but now it's not our fault
<alyssa>
whoop
zkrx has quit [Ping timeout: 245 seconds]
<alyssa>
Take #2 of RA is 160x faster on a Skia shader I'm playing with (yes, 160x. not a typo.)
<alyssa>
I guess it's worth finishing the branch.
zkrx has joined #panfrost
<italove>
is it also LCRA or is it something different?
<alyssa>
italove: Bifrost master is using LCRA, since the original Bifrost RA was written in an evening while sitting in the Robarts Library in the middle of the school week.
<alyssa>
It was supposed to be a temporary hack using LCRA (with some of the most complex parts of LCRA disabled since most of the complexity is to deal with Midgard's issues)
<alyssa>
Days before the lockdown. That was not a good week :p
<italove>
I see
<italove>
so the new one is based on another paper?
<alyssa>
\shrug/
<alyssa>
I'm just writing code and seeing where it taks me
<italove>
fair enough :)
archetech has joined #panfrost
guillaume_g has quit [Quit: Konversation terminated!]
<cwabbott>
alyssa: btw, it sounds like you're forming clauses *before* RA? that seems like it might be a mistake
<cwabbott>
if you're forming clauses after RA, then you don't have to worry about any of that nonsense during RA and you can just lift the ACO vector stuff directly
<cwabbott>
or, if you want, lift my WIP RA rewrite for freedreno
<alyssa>
cwabbott: I am forming clauses before RA, because doing it the other way would (also) be a mistake.
<cwabbott>
why?
<alyssa>
since the program's register pressure is affected by the clauses formed
<cwabbott>
i just don't think it's worth the pain
<alyssa>
Maybe not.. I don't see how it would work otherwise though
<amonakov>
alyssa: is that because of t registers?
<alyssa>
amonakov: that's part of it
<amonakov>
how many t regs are there?
<alyssa>
the need to schedule out-of-order to form clauses though is the other issue unless I'm deluded
<cwabbott>
the lima gp compiler does try to fully take advantage of the t registers (or the gp equivalent), if you want you can go read it and then run away :)
<alyssa>
i'm scared of the gp ;)
<cwabbott>
and yes, you need to schedule out-of-order to form clauses, but pretty much every "grown-up" compiler has both a pre and post RA scheduler
<cwabbott>
it's just something you can't do without
<cwabbott>
*grown-up backend
<amonakov>
(what do you mean by OoO scheduling here?)
<alyssa>
yeah.. I'm expecting pre/post RA scheduling to be necessary
<alyssa>
Still not clear to me what the 'right' place to split up work is.
<alyssa>
I had envisioned pre-RA scheduling to do the heavylifting (incl. forming clauses), and post-RA scheduling would just cleanup spills/fills/remats.
<alyssa>
Given all of the above are message-passing instructions they need their own clauses anyway so the modification is trivial (what we do now).
<alyssa>
That breaks down if you need to insert moves cheaply, though. Works ok if we go out of SSA at NIR time.
<alyssa>
I worry that scheduling clauses post-RA would require too many false dependencies (could be mitigated with round robin RA, I guess)
Elpaulo has joined #panfrost
raster has quit [Quit: Gettin' stinky!]
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #panfrost
karolherbst has quit [Quit: duh 🐧]
archetech has quit [Quit: Konversation terminated!]
sammwch has joined #panfrost
heddwch has quit [Ping timeout: 260 seconds]
sammwch has quit [Remote host closed the connection]
heddwch has joined #panfrost
alpernebbi has quit [Quit: alpernebbi]
karolherbst has joined #panfrost
jwalts has quit [Remote host closed the connection]
karolherbst has quit [Read error: Connection reset by peer]