<HdkR>
Apparently the compiler doesn't need to do scheduling at all
<alyssa>
Sticking to scalar, that's good lol
<HdkR>
I wonder if they have any way to optimize uniform data paths like AMD and Nvidia has
<HdkR>
Huh
<HdkR>
a dynamically detected forwarding buffer
<HdkR>
Guess that drops temps entirely?
<alyssa>
New AFBC version...?
<HdkR>
Looks like we'll be able to reuse significant portions of the bifrost compiler code
<alyssa>
This just looks like Bifrost 2.0
<alyssa>
Then again, Bifrost was really just Midgard 2.0
<HdkR>
Which is fine
vstehle has joined #panfrost
fysa has quit [Remote host closed the connection]
_whitelogger has joined #panfrost
Elpaulo has joined #panfrost
tgall_foo has quit [Read error: Connection reset by peer]
<tomeu>
alyssa: just to be sure, we shouldn't be flipping buffers any more in Panfrost?
<alyssa>
tomeu: Nope, Gallium does the flippery for us; I just ignored it since I wanted to match with the blob (but that obviously breaks Gallium's assumptions); ML patch fixes that (but diverges from the blob's behaviour, but w/e)
<HdkR>
Which I've half reviewed atm
<HdkR>
:P
<tomeu>
alyssa: nice, only that with that, my wallpaper code hits a DATA_INVALID_FAULT :)
<alyssa>
Bah
<alyssa>
tomeu: PM me a pandecode before I fall asleep and I'll see :p
<tomeu>
working on it, but I don't think it's worth delaying sleep
<alyssa>
But Mommmm....
<HdkR>
You don't want to end up like me and stop sleeping
<alyssa>
Touche
<alyssa>
Nini everyone :)
<tomeu>
o/
<alyssa>
tomeu: Things to check for would be specifically the viewport (max has to be greater than min, etc)
<tomeu>
cool, will do
<alyssa>
And the texture descriptor (do we still have a custom stride? what sign is it? it should be positive)
<HdkR>
I'm actually planning on doing work in about 45 minutes. What are timezones, what is sleep?
<alyssa>
And just generally if you get any "zero tripped" type comments, I mean, that's not good ;P
<alyssa>
If all else fails... decode before the commit and decode after, and diff :P
<alyssa>
(Diff manually if you have to... honestly, that's how a lot of early bringup was done .... anyway :P)
* alyssa
zzz
<tomeu>
thanks!
<tomeu>
with a sleep between frames, everything renders fine and the GPU doesn't complain :)
<tomeu>
there's always a ADDR_RANGE_FAULT before the DATA_INVALID_FAULT start coming
pH5 has quit [Quit: bye]
pH5 has joined #panfrost
fysa has joined #panfrost
<tomeu>
well, if I revert this revert, things work just fine: Revert "mesa: unreference current winsys buffers when unbinding winsys buffers"
<tomeu>
and that's effectively adding dereferences
<tomeu>
puzzling
fysa has quit [Ping timeout: 245 seconds]
rhyskidd has quit [Ping timeout: 252 seconds]
yann has joined #panfrost
rhyskidd has joined #panfrost
afaerber has quit [Quit: Leaving]
stikonas has joined #panfrost
fysa has joined #panfrost
fysa has quit [Ping timeout: 246 seconds]
afaerber has joined #panfrost
rhyskidd_ has joined #panfrost
rhyskidd has quit [Ping timeout: 258 seconds]
rhyskidd_ is now known as rhyskidd
Elpaulo has quit [Quit: Elpaulo]
belgin has joined #panfrost
Elpaulo has joined #panfrost
belgin has quit [Quit: Leaving]
paulk-leonov has quit [Max SendQ exceeded]
_whitelogger has joined #panfrost
paulk-leonov has joined #panfrost
paulk-leonov has quit [Max SendQ exceeded]
<tomeu>
alyssa: btw, the blitter recursion problem is due to the flush in panfrost_set_framebuffer_state
<tomeu>
as I'm adding the wallpaper jobs on invalidate
tlwoerner_ is now known as tlwoerner
<bbrezillon>
tomeu: adding the wallpaper job so early might be a problem for partial_update()
* alyssa
blinks
<tomeu>
bbrezillon: in what way?
<bbrezillon>
we'd need to restrict the area where the reload-fb is done (there's no point reloading data that are to be discarded anyway)
<tomeu>
ah, of course
<tomeu>
when do we know the damage region?
<bbrezillon>
much later I guess
<bbrezillon>
and it might actually be updated iteratively AFAIU
<bbrezillon>
(not so sure about the last statement)
<bbrezillon>
ideally, we should create the wallpaper job(s) just before flushing
<alyssa>
^^ That
<bbrezillon>
when we know exactly what parts of the FBs will be kept
<alyssa>
tomeu: I'm wondering if it would be fruitful to refactor job creation entirely first, then the old-style "elided TILER at the end" solution would work
<bbrezillon>
alyssa: +1
<bbrezillon>
though I don't remember what tomeu fixed
<alyssa>
I mean the old-style impl was totally broken
<tomeu>
well, the code has changed quite a bit since I last tried, so I could look at generating the jobs at the end
<alyssa>
Tomeu found the issues I thought but it was easier to scrap it
<bbrezillon>
I know that re-ordering stuff at link time was not enough (this is what I did and it didn't work)
<tomeu>
if it doesn't work, maybe I will find out what we are missing
<alyssa>
Refactoring = getting rid of linked stage like Connor pointed out
<bbrezillon>
yes
<tomeu>
alyssa: but jobs would still be created as the draw calls are submitted, right?
<tomeu>
and not on flush
<alyssa>
No, created on flush
<bbrezillon>
tomeu: if we can create the jobs at flush time that's better
<alyssa>
But prepended to the list
<tomeu>
ah, all jobs, right? not only wallpaper jobs
<bbrezillon>
I only had wallpaper jobs in ming
<bbrezillon>
mind
<alyssa>
No, just wallpaper
<alyssa>
It's a linked list
<alyssa>
There's no reason we can't prepend a job
<bbrezillon>
other jobs would be created at draw time
<alyssa>
We need to link as we go, not the mess we have here where we have a "link stage" (that doesn't make sense)
<tomeu>
yeah, but I think we are missing something, because just the linking thing wasn't enough
<tomeu>
will be easy to check
<alyssa>
tomeu: AFAIU, you were linking the wallpaper to be the last job but then setting deps as the first and the hw got confused
<bbrezillon>
tomeu: that's what I remember from your debugging session 2 weeks ago
<bbrezillon>
the link order was not enough
<tomeu>
alyssa: I think the wallpaper jobs came right after the get_value job
<bbrezillon>
*fixing the link order
<tomeu>
so it wasn't just the dep fields, but also the next_job field
* alyssa
grumbles
<alyssa>
link order = next_job order
<bbrezillon>
tomeu: I had the next_job order fixed IIRC
<bbrezillon>
shadeslayer: it's another level of abstraction
<shadeslayer>
bbrezillon: oh ok
<bbrezillon>
it's like drm_panfrost --inherits-> drm_gem_shmem_object --inherits-> drm_gem_object
<shadeslayer>
bbrezillon: what's the difference between a gem_object and a shmem_gem_object though?
<shadeslayer>
I mean, I understand it's backed by shmem, but what does that really mean :)
<bbrezillon>
shadeslayer: that means that the memory is coming from a shmem instance attached to the DRM device
<bbrezillon>
we usually use that when the GPU has an iommu and/or support SG transfers as we don't need to have physically contiguous memory regions in that case
<bbrezillon>
but I'm no expert, robher might have a more detailed explanation
<shadeslayer>
hm, docs also say "GEM uses shmem to allocate anonymous pageable memory." later on
<bbrezillon>
shadeslayer: that's not always true
<bbrezillon>
see the CMA backed gem_object
<shadeslayer>
I see
paulk-leonov has joined #panfrost
yann has quit [Ping timeout: 252 seconds]
pH5 has quit [Quit: bye]
fysa has joined #panfrost
fysa has quit [Ping timeout: 272 seconds]
TheCycoTWO is now known as TheCycoONE
herbmilleriw has quit [Quit: Konversation terminated!]
herbmilleriw has joined #panfrost
fysa has joined #panfrost
fysa has quit [Ping timeout: 268 seconds]
chewitt has joined #panfrost
herbmilleriw has quit [Ping timeout: 268 seconds]
herbmilleriw has joined #panfrost
NeuroScr has joined #panfrost
narmstrong has quit [Ping timeout: 264 seconds]
afaerber has quit [Quit: Leaving]
narmstrong has joined #panfrost
stikonas_ has quit [Read error: Connection reset by peer]
stikonas has joined #panfrost
milloni has quit [Remote host closed the connection]