alyssa 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
atler is now known as Guest49
atler has joined #panfrost
Guest49 has quit [Read error: Connection reset by peer]
stan_ has joined #panfrost
vstehle has quit [Ping timeout: 480 seconds]
stan has quit [Ping timeout: 480 seconds]
camus has joined #panfrost
FizzBuzz has joined #panfrost
camus1 has joined #panfrost
camus has quit [Read error: Connection reset by peer]
FizzBuzz has quit []
Luc has joined #panfrost
Luc has quit []
jkl has joined #panfrost
vstehle has joined #panfrost
davidlt has joined #panfrost
andrey-konovalov has joined #panfrost
rasterman has joined #panfrost
davidlt_ has joined #panfrost
davidlt has quit [Ping timeout: 480 seconds]
amonakov has left #panfrost [#panfrost]
<stepri01>
alyssa: JIT allocation is all about reducing the memory usage while providing the kernel flexibility in ordering jobs on the hardware.
<stepri01>
The idea is instead of allocating temporary buffers (especially the tiler heap) upfront you just signal to the kernel via the soft-jobs that memory will be needed
<stepri01>
the kernel can then opportunistically keep buffers around but free them if there's memory pressure (the shrinker is called)
<stepri01>
but instead of user space having to guess how many buffers are going to be needed (as with the 'HEAP' buffers in Panfrost) JIT explicitly marks the time when the buffer needs to be allocated/freed
<stepri01>
JIT is not needed for functionality, it is an optimisation. Apparently Vulkan made the memory management harder so this got pushed on the kernel driver
<stepri01>
whether it was actually a good thing overall or not I don't know - from a kernel perspective it's not nice ('random' memory allocations - and no idea ahead of time how much memory might be needed)
<stepri01>
but the folks writing the Vulkan driver seemed to think it was important
camus has joined #panfrost
camus1 has quit [Ping timeout: 480 seconds]
jkl has quit [Ping timeout: 480 seconds]
<cwabbott>
iirc the main use-case was for VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT
<cwabbott>
vulkan renderpasses can potentially contain more attachments than you can fit in tile memory, so you have to "spill" some attachments to memory
<cwabbott>
it's a lot like (simple) register allocation/scheduling
<cwabbott>
the user allocates some images, and says up-front that they never leave the bounds of the renderpass so you can avoid actually allocating memory for them... unless you need to spill
<cwabbott>
and you don't know when allocating the memory which render pass it will be used with as the actual binding of framebuffers with renderpasses can happen dynamically (iirc)
<icecream95>
I wonder if it would be helpful to have a more structured format for pandecode dumps
<icecream95>
Votes for {XML, SQL, JSON, Other}?
<icecream95>
SELECT * FROM trace JOIN dcd ON dcd.id = trace.dcd WHERE type = 'fragment' AND NOT dcd.occlusion = 0;
jernej has joined #panfrost
jernej_ has quit [Read error: Connection reset by peer]
<urja>
i didnt know it was disableable to that extent
robmur01__ has quit []
robmur01 has joined #panfrost
jambalaya has joined #panfrost
thecycoone has quit [Ping timeout: 480 seconds]
camus has quit [Remote host closed the connection]
camus has joined #panfrost
thecycoone has joined #panfrost
jkl has quit [Ping timeout: 480 seconds]
<stepri01>
but the folks writing the Vulkan driver seemed to think it was important
<stepri01>
sorry - didn't mean to post that! ;)
camus has quit [Remote host closed the connection]
camus has joined #panfrost
pastly-antispam has quit [Quit: WeeChat 2.3]
<stepri01>
cwabbott: VK's LAZILY_ALLOCATED bit is different to JIT. That is AIUI much more like the existing Panfrost HEAP memory type
<alyssa>
stepri01: Gotcha, thank you
<alyssa>
For reference a DDK I was looking at used JIT alloc/free jobs at the begin/end of the submit, and I wasn't sure if that was a hardware thing (Valhall) or a platform thing (Android) or a modern thing (last time I set up a DDK for tracing was years ago)
<stepri01>
it's entirely possible to emulate JIT in user space, but the performance is problematic! ;)
<alyssa>
Sure :)
<alyssa>
I'm just looking a OpenGL, for what it's worth.
<alyssa>
But it sounds like they might be JIT alloc'ing the tiler heap, whereas older DDKs would have GROWABLE'd them.
<stepri01>
yes JIT is a relatively new feature, so it's taken a while for things to move over to it
wwilly has joined #panfrost
camus1 has joined #panfrost
camus has quit [Read error: Connection reset by peer]
wolfshappen has joined #panfrost
<robmur01>
heh, it's starting to go a bit Rumsfeld with the known UNKNOWNs vs. unknown UNKNOWNs :D
<bbrezillon>
:)
<alyssa>
robmur01: The rule of robust switch() statements -- use case: to handle all the possible cases and use default: to handle all the impossible ones ;-)
<stepri01>
hmm, looks like there's something horrid with memory reclaim :(
<alyssa>
the OOM killer...
<alyssa>
...and the OOM reaper
<alyssa>
someone needs to write a horror novel
andrey-konovalov has quit [Ping timeout: 480 seconds]
<alyssa>
Call it "Internals of the Linux Kernel"
<stepri01>
I suspect it might be an actual bug though - daniels sugggested a while ago we should provide an debugfs feature to test the reclaim code
<alyssa>
stepri01: On that note we really need better ways to test the shrinker
<stepri01>
yes - that's what I meant by reclaim ;)
<alyssa>
oh got it
<alyssa>
(and interactions between the shrinker and closing fd's / jobs hanging / faults / etc, at least some of which seem to be broken at any given time)
<stepri01>
first step would be a simple way of triggering the shrinker which should let lockdep do much of it's magic and report problems
andrey-konovalov has joined #panfrost
<stepri01>
anyway, my cats need feeding, and I'm away tomorrow - so it'll have to wait until at least Wednesday!
<alyssa>
🐈
<bbrezillon>
stepri01: I can reproduce that without the shrinker being involved
<bbrezillon>
and it's an actual deadlock, not just lockdep complaining
<bbrezillon>
my bad, there's no deadlock, just a lockdep splat complaining about a potential deadlock, I got confused by the igt failure resulting from the delay induced by the deadlock backtrace
<bbrezillon>
still, I don't see why the resubmit jobs should be part of the dma signaling section
alpernebbi has quit [Quit: alpernebbi]
jkl has joined #panfrost
atler has joined #panfrost
rasterman has quit [Ping timeout: 480 seconds]
rasterman has joined #panfrost
<robclark>
alyssa: not sure if you've noticed yet that int16 isn't super-best-friends with loop unrolling.. was thinking to make a stab at a nir pass to shuffle conversions around and lower phi's to 16b, which I suspect would be useful to you as well
<alyssa>
robclark: not super best friends indeed..
<robclark>
it's hurting the all-important gfxbench
<alyssa>
heh
<alyssa>
right now I have INT16 disabled entirely since it has some problem interactions in the GLSL compiler that causes crashes
<alyssa>
^crashes in the GLSL compiler
<robclark>
huh.. at least deqp-gles2/3/31 seemed happy enough with INT16
<alyssa>
interaction of all the 16-bit CAPs together