<tomeu>
bbrezillon: every kernel commit I try has different failure modes, so I think we should declare the project closed and move to something else
<bbrezillon>
tomeu: :D
<bbrezillon>
tomeu: I guess you already tried cherry-picking only the fix you need on top of 5.3
<tomeu>
the fix I need?
<bbrezillon>
didn't you say you needed a fix for the H64 to work?
<tomeu>
ah yes, I need the DT chances, etc
<tomeu>
but even with those it wasn't working, I guess something else got fixed since then
<tomeu>
anyway, I'm testing now on veyron
<bbrezillon>
tomeu: and it fails there too?
<tomeu>
in different ways
<bbrezillon>
like...
<tomeu>
different faults at different times
<bbrezillon>
can you make sure all jobs are stopped when the FD is closed?
<tomeu>
I'm going to add a debug feature to panfrost that syncs after each job and prints the exception and fault address for each job, if any
<tomeu>
so I make sure I'm seeing issues caused by concurrency, and no others
<tomeu>
bbrezillon: I commented out everything in postclose, and I still saw those in t720 :/
<tomeu>
it's problematic when the faults are printed to the kernel and the deqp output goes to the console
<bbrezillon>
just add an atomic_t to panfrost_file_priv that's incremented everytime a job is submitted, and decremented at job_cleanup time
<bbrezillon>
hm, not sure dropping what's in the postclose will help
<bbrezillon>
by doing that you probably introduce other bugs
<bbrezillon>
tomeu: if the number of active jobs after panfrost_job_close() is != 0, you have a problem
kherbst has joined #panfrost
karolherbst has quit [Disconnected by services]
kherbst is now known as karolherbst
guillaume_g has quit [Quit: Konversation terminated!]
guillaume_g has joined #panfrost
<alyssa>
urjaman: "'/* TODO: Remove me I'm a fossil */' ... this doesnt actually help in understanding :P" Oops :p
<alyssa>
tomeu: I've been hitting INSTR_INVALID_PC with MRT stuff :|
<alyssa>
urjaman: spill code is so broken at this point.
<alyssa>
I would rewrite from the top if I thought I could do better :|
<alyssa>
There are so many subtle issues so I'm not sure ;;
davidlt has joined #panfrost
davidlt has quit [Ping timeout: 240 seconds]
steev has joined #panfrost
wens has quit [Ping timeout: 265 seconds]
wens has joined #panfrost
<alyssa>
I've been just doing cleanup for spill code rn
<alyssa>
When spilling fails, simply failing to RA rather than aborting the whole program is probably a step up
<alyssa>
So now we get graphical corruption instead of crash.
<alyssa>
Which I guess should also help debug visually.
<robher>
bbrezillon: we already have a per FD counter incremented of job submit. The AS counter.
<alyssa>
urjaman: Congrats on becoming a mesa contributor :tada:
<alyssa>
Wait you did the oq stuff
<alyssa>
Congrats retracted ;P
<urjaman>
thanks but i think yeah that had already happened :P
<alyssa>
I think I'll need uh to do this more methodically.
<alyssa>
...The fact I can run LXDE inside Weston/Wayland via glamor is
<alyssa>
bizarre
<urjaman>
the way Xwayland uses glamor is different from the usual Xorg, but i'm not sure how exactly
<alyssa>
Slightly different, yes
<urjaman>
maybe it's in GLES mode i dont remember
<alyssa>
urjaman: Were you the one asking about LXDE btw?
<urjaman>
nah i use XFCE
<alyssa>
K
<urjaman>
(for playing around with Xwayland i have sway ...)
<bbrezillon>
robher: not sure what you mean
<robher>
bbrezillon: The AS counter could be used instead of a new job counter atomic.
<bbrezillon>
robher: oh, gpu_usecount
<robher>
bbrezillon: panfrost_mmu.as_count
<bbrezillon>
but the AS counter is for the AS, not for a BO mapping in this AS
<bbrezillon>
gpu_usecount is a per BO thing
<bbrezillon>
but I'm not sure we're talking about the same thing
<bbrezillon>
okay, got it, you're replying to my suggestion to add an atomic_t added to panfrost_file_priv
<bbrezillon>
sorry, I thought we were talking about patch 8 of my 5.4 fixes series
<bbrezillon>
yep, as count can be used for that
<robher>
right.
<robher>
bbrezillon: BTW, there's maybe another way to track gpu BO usage. Create a "GPU BO list". If we use the same listhead then a BO can't be on the purge list at the same time. That's kind of how msm works with its active and inactive lists.
<bbrezillon>
robher: could work too
<bbrezillon>
it just requires reworking the way we add things to the shrinker list
<bbrezillon>
(we'd need to only add the BO to this list once all its active users are gone)
<bbrezillon>
and by active user, I'm thinking about GPU jobs
<alyssa>
*aggressively cleaning up code intensifies*
<robher>
bbrezillon: I'm going to apply your patches 2-5. Okay?
<bbrezillon>
robher: okay
<bbrezillon>
note that the one fixing most (all?) of the bugs I had is patch 7
<bbrezillon>
patch 8 is probably fixing bugs when the system is under memory pressure
<bbrezillon>
the other ones (patch 2-5) are just things I noticed along the way
<bbrezillon>
robher: are you sure you want to apply patch 2?
<bbrezillon>
you seemed to think this one was not really needed
<robher>
bbrezillon: Yeah, my main concern was just around lockdep being happy.
<alyssa>
Can't tell if I'm getting closer or just moving the problem.
wens has quit [Ping timeout: 268 seconds]
guillaume_g has quit [Quit: Konversation terminated!]
<steev>
hey all, not sure if this is the right place, i'm just trying to track down... where to even report this, or if it has been fixed, and i'm just missing a patch or what. i've got a nanopi neo4 (rk3399) and when moving to a 5.4 kernel (armbian), lightdm just keeps repeatedly crashing. dmesg shows broken atomic modeset userspace detected, disabling atomic... and the xorg log... spits out https://pastebin.com/2GQFCEJP - i've never seen this
<steev>
before, and trying to search for LookupColor panfrost, google hasn't seen anything with those before
<alyssa>
steev: working on it.
<steev>
assuming the workaround that i use (use fbdev) is the workaround for now?
<steev>
s/use/force/
<alyssa>
It turns out register spilling is really hard :-(
<steev>
way over my head, i appreciate you working on it :)
<alyssa>
I confess I'm stuck on this
<alyssa>
but I'm also stubborn
<alyssa>
so
<steev>
The part I don’t quite understand is, the nanopc t4 doesn’t have the same issue; I would have kinda expected all rk3399 to have the issue - is it a ram thing? The neo4 only has 1GB
<alyssa>
...?
<alyssa>
If it's the same bug it affects all panfrost devices
<steev>
That’s what I was expecting
<steev>
Let me double check that I didn’t force fbdev on the pct4
<alyssa>
Hopefully I can make some forward progress sooner than later.
<steev>
fingers crossed - i'm re-setting up the nanopc t4 - i forgot i was trying to get the mipi lcd working on it, which sadly isn't quite there yet, not sure why
<urjaman>
i'm taking a break from dumping code into my brain, but i was thinking for when i get back into it...
<urjaman>
does mesa have some standalone shader compiler tool that i could feed the shader into and see what comes out without running the whole app? (in this case Xorg)
<abordado>
There is one for bifrost, and I built one for midgard, but i haven't submitted it yet because i'm having some issue with the build system
<abordado>
The last commit shows the issue i'm currently having, other than that it should work
<urjaman>
thanks, i'll take a deeper look when i get back into this
<steev>
alyssa: ah, no, i was wrong, same thing happens on the nanopc t4 :)
davidlt has joined #panfrost
stikonas has joined #panfrost
davidlt has quit [Remote host closed the connection]
davidlt has joined #panfrost
<alyssa>
steev: Weee.
<alyssa>
urjaman: We used to have one, I removed it since it was just becoming a maintenance burden and nobody was using it.
<alyssa>
See ea6b58144467f9eeb8e249cff07e354ad14ef12a
<alyssa>
abordado: ^^
<alyssa>
"do not commit this please" relatable ;p
<alyssa>
urjaman: Ooo@@
<alyssa>
Ooo!!!
<urjaman>
oo?
<alyssa>
urjaman: I got the glamor/lxde shader working / compiling fine
<alyssa>
Granted the last change I made is a total hack
<alyssa>
More work needed but I feel marginally more motivated :)
<urjaman>
Ooo indeed.
<alyssa>
This change also fixes projtex (which we have an issue opened about on gitlab)
<alyssa>
It doesn't fix neverball though
<alyssa>
In conclusion spilling is so broken there are multiple big issues >.<
<urjaman>
neverball broke too? gosh
<urjaman>
shows how often i try it :P
<alyssa>
Unfortunately so
TheKit has joined #panfrost
<alyssa>
....Oof.
<alyssa>
Okay, more shuffling and I have neverball working but glamor is broken again :p
<alyssa>
And a third iteration has neverball and glamor working but terrain broken
<alyssa>
Musical chairs, but with register spilling!
<alyssa>
....and all three at once! We have a winner! I hope.
<alyssa>
Spilling is still broken but much less so it looks like :)
<alyssa>
Okay, the compiler side of spilling is somewhat better.
<alyssa>
Unfortunately we're not done yet ... the next question will be allocating the right size of stack.
<alyssa>
(Otherwise you get graphical corruption.)
<alyssa>
Ugh I remember this being a pain to figure out last time .......
Pak0st has joined #panfrost
afaerber has quit [Quit: Leaving]
<Pak0st>
Interesting, everything is rendered as if you a looking into a mirror with Godot, not just the editor but running a project as well (took some silly guesstimate where to click to adjust and start a random project with gles2). Somewhere along the way between mesa 19.2 and 19.3-rc6 the visual artifacts went away from the editor and everything is as
<Pak0st>
if looking into a mirror (clicking the buttons/fields are on their original place). Playing a simple 2D game looked faster than 19.2, mirror thing aside
<alyssa>
I've heard, yes. Somebody sent an apitrace of godot which I do plan to look at.
* alyssa
has been having a debug spree
<HdkR>
Planar reflections for everyone :D
afaerber has joined #panfrost
<Pak0st>
:D
<alyssa>
......Okay, yes, I see what you mean
<alyssa>
(In the apitrace)
<alyssa>
Genuinely not sure how we could be *that* reflected :P
<Pak0st>
It's fun looking at it and figuring out where to click for awhile :D The text in particular begins to looks like a bunch of hieroglyphs the more I stare at it
<alyssa>
I remember etr worked right after XDC ... that's still a painful 2 month bisection ...
<Lyude>
didn't it work at xdc? I remember you showing us it
<Lyude>
or was that a different tux racer
<alyssa>
Different tux racer but both worked
<Lyude>
ah
<alyssa>
Oh wait
<alyssa>
It's spilling and I needed the "make thread local storage massive" patch
<alyssa>
With that etr is fine again
<alyssa>
Nevermind why so many apps are spilling ... :V
<alyssa>
So I guess figuring out how to calculate the size of thread local storage ... will be the next task!
<alyssa>
Well. next week :)
<alyssa>
or Sunday, maybe
Pak0st has joined #panfrost
Pak0st has quit [Remote host closed the connection]
NeuroScr_ has quit [Ping timeout: 250 seconds]
NeuroScr has joined #panfrost
Pak0st has joined #panfrost
vstehle has quit [Ping timeout: 250 seconds]
<Pak0st>
alyssa: Applied the patch and it did change something. The initial logo is shown as it should be yet the editor's ui seems mirrored a bit differently. If there is time tomorrow, I will read on how to grab an apitrace