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
camus1 has quit [Remote host closed the connection]
camus has joined #panfrost
camus1 has joined #panfrost
camus has quit [Read error: Connection reset by peer]
macc241 has joined #panfrost
macc24 has quit [Read error: Connection reset by peer]
macc241 has quit []
macc24 has joined #panfrost
atler is now known as Guest258
atler has joined #panfrost
camus has joined #panfrost
camus1 has quit [Remote host closed the connection]
Guest258 has quit [Ping timeout: 480 seconds]
camus1 has joined #panfrost
camus has quit [Ping timeout: 480 seconds]
camus1 has quit [Remote host closed the connection]
camus has joined #panfrost
camus has quit [Remote host closed the connection]
camus has quit [Remote host closed the connection]
camus has joined #panfrost
nlhowell has joined #panfrost
Danct12 has joined #panfrost
Danct12 has quit []
Daanct12 has quit [Ping timeout: 480 seconds]
warpme_ has joined #panfrost
camus has quit [Ping timeout: 480 seconds]
Danct12 has joined #panfrost
camus has joined #panfrost
<tomeu>
bbrezillon: should I need a FBD for the clear attachments? I thought they were required for tiler jobs, but cannot find one in the preload draws
<bbrezillon>
tomeu: yes, you need one, but this should be emitted in the close_batch() path
<tomeu>
ah, I see
<bbrezillon>
well, the descriptor itself should be allocated earlier
<bbrezillon>
since the tiler job points to the FBD
<tomeu>
bbrezillon: hmm, not sure I follow
<tomeu>
I see that when preloading, we don't emit a FBD
<tomeu>
but we do in buf2img, for example
<bbrezillon>
tomeu: because preloading is part of a draw sequence that has a fragment job + FBD at the end
<bbrezillon>
this might also be the case of your vkCmdClearAttachments() BTW
<tomeu>
bbrezillon: so the tiler job for preloading doesn't need to reference a FBD because there will be a fragment job at the end?
<tomeu>
vkCmdClearAttachments could be the only command in a render pass though
karolherbst has quit [Read error: Connection reset by peer]
karolherbst has joined #panfrost
jernej has quit [Ping timeout: 480 seconds]
jernej has joined #panfrost
<bbrezillon>
tomeu: right, for ClearAttachement you need to allocate the FBD and tiler context if no other draws have been queued
<tomeu>
so when the batch is closed, if there's no draws, then att the FBD and tiler context to the clear attach tiler job?
<bbrezillon>
not quite
<bbrezillon>
the fbd/tiler context should be allocated and attached to the tiler at tiler job emission time
<bbrezillon>
but we emit (AKA pan_pack() call) those descs when closing the batch
<bbrezillon>
tomeu: in panvk_CmdDraw() we call panvk_cmd_alloc_fb_desc() and panvk_cmd_alloc_tls_desc()
<bbrezillon>
you should do the same in panvk_CmdClearAttachments()
<tomeu>
ah, got it now, thanks!
<bbrezillon>
those helpers make sure the descs are allocated only if there were no fbd/tiler descs attached to the cmdbuf state
<icecream95>
Soo... There are (at least) two bugs causing the OpenSCAD regression, the second introduced before the first was fixed?
<icecream95>
*sigh*
* icecream95
restarts the bisect
<icecream95>
It seems alpha_func is getting changed without recalculating whether to use early/late Z
<icecream95>
Uh, no, there are *three* bugs, though I think two of them have been fixed by now
karolherbst has quit [Remote host closed the connection]
karolherbst has joined #panfrost
<tomeu>
uff, finally got a bunch of tests passing
rasterman has joined #panfrost
<bbrezillon>
tomeu: \o/
Bozzer has joined #panfrost
<tomeu>
a bit of a steep learning curve, the driver has changed quite a bit in the past 2 years
<HdkR>
yay
Bozzer has quit [Remote host closed the connection]
modem_ has joined #panfrost
modem_ has quit [Remote host closed the connection]
camus1 has joined #panfrost
camus has quit [Ping timeout: 480 seconds]
camus1 has quit [Ping timeout: 480 seconds]
camus has joined #panfrost
jernej has quit [Ping timeout: 480 seconds]
camus has quit [Ping timeout: 480 seconds]
jernej has joined #panfrost
<tomeu>
bbrezillon: btw, the calling of panvk_cmd_alloc_fb_desc is a bit convoluted
<tomeu>
we call it first, then call panvk_cmd_alloc_tls_desc which will call panvk_cmd_alloc_fb_desc again
<bbrezillon>
tomeu: that's because the tsd is part of the fbd on Midgard
<tomeu>
bbrezillon: so maybe panvk_cmd_alloc_tls_desc should instead assert that the fbd has been allocated?
<bbrezillon>
we could
<bbrezillon>
but I guess I did this to allow re-ordering calls
<bbrezillon>
oh, and we'll call only tls_alloc() when queuing a compute job, and if this job is part of a gfx pipeline (can happen for meta jobs), we still want to re-use the tls desc embedded in the fbd
<bbrezillon>
so I think it should stay like that
alpernebbi has joined #panfrost
<tomeu>
bbrezillon: guess I need to similarly call panvk_cmd_get_bifrost_tiler_context ?
<bbrezillon>
tomeu: right, something like panvk_draw_prepare_tiler_context()
<bbrezillon>
actually you can call panvk_draw_prepare_tiler_context(), since the clearattachments is just a draw
camus has joined #panfrost
robmur01 has quit [Quit: Leaving]
robmur01 has joined #panfrost
camus1 has joined #panfrost
robmur01 has quit [Quit: Leaving]
camus has quit [Ping timeout: 480 seconds]
<urja>
ah, it only took ... almost 9 hours of uptime this time to get to MMU wonkiness, but it still happens
<urja>
bbrezillon ^^ that's with a kernel based on (only my added HDMI things and such, nothing panfrost related by me) drm-misc-next from a day or two ago
<urja>
i was scrolling twitter when i noticed a graphical glitch and was immediately like "oh, lets take a look in dmesg"... yeah the visual effect of that is that randomly parts of the composited image you're looking at get wrong pages mapped somewhere in there (starting with just a pixel line or two garbled usually)
<urja>
https://urja.dev/glitchy.png apparently the glitches are visible if you take a screenshot, "neat" (see the youtube tab, and the toolbar icons... or whatever thats called anyways)
<tomeu>
bbrezillon: argh: panvk_cmd_get_bifrost_tiler_context wants to emit the descriptor, but I don't have yet a fb and thus have no width and height
<tomeu>
guess that one needs to be similarly split to allocate on ClearAttachments, and then emit at batch close time?
jernej has quit [Remote host closed the connection]
<robmur01>
urja: hmm, notable that it seems to be under memory pressure - I wonder if there's a race where addresses can be freed in the mm before they're actually unmapped?
jernej has joined #panfrost
* robmur01
grudgingly acknowledges that shrinker spam *can* be informative...
<urja>
yeah that's why i included a little bit of it, because started noting that there wasnt MMU wonk when we were still in the "filling up memory" stage of running :P
camus has joined #panfrost
wwilly_ has quit []
camus1 has quit [Ping timeout: 480 seconds]
<bbrezillon>
tomeu: I guess that happens when you have a secondary cmd buffer
<bbrezillon>
otherwise you should have a FB bound to the cmdbuf
camus1 has joined #panfrost
camus has quit [Ping timeout: 480 seconds]
camus1 has quit [Remote host closed the connection]
camus has joined #panfrost
camus has quit [Remote host closed the connection]
camus has joined #panfrost
camus has quit [Remote host closed the connection]
camus has joined #panfrost
camus has quit [Remote host closed the connection]
camus has joined #panfrost
camus1 has joined #panfrost
camus has quit [Remote host closed the connection]
camus has joined #panfrost
camus1 has quit [Ping timeout: 480 seconds]
camus has quit [Remote host closed the connection]
camus has joined #panfrost
warpme_ has quit [Quit: Connection closed for inactivity]
davidlt has quit [Ping timeout: 480 seconds]
nlhowell has quit [Ping timeout: 480 seconds]
alpernebbi has quit [Quit: alpernebbi]
bluebugs has quit [Remote host closed the connection]
cedric has joined #panfrost
cedric is now known as bluebugs
rasterman has quit [Quit: Gettin' stinky!]
camus has quit [Remote host closed the connection]
<robmur01>
aww, I was hoping that might be related to the similar issue I see in FreeCAD where a selected body is covered in an opaque yellow cube instead of its actual geometry being highlighted in yellow (I assume the cube is *supposed* to alpha-blend), but alas it is not helped :(
<icecream95>
robmur01: If you manage to get an apitrace of that, I could take a look at it