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
vstehle has quit [Ping timeout: 480 seconds]
pch has quit [Remote host closed the connection]
pch has joined #panfrost
JulianGro has quit [Read error: Connection reset by peer]
camus1 has quit []
camus has joined #panfrost
soreau has quit [Read error: Connection reset by peer]
soreau has joined #panfrost
erlehmann has joined #panfrost
benthumb2000 has joined #panfrost
Danct12 has joined #panfrost
Danct12 has quit [Quit: Quit]
erlehmann has quit [Ping timeout: 480 seconds]
erlehmann has joined #panfrost
erlehmann has quit [Ping timeout: 480 seconds]
erlehmann has joined #panfrost
tchebb_ has joined #panfrost
tchebb has quit [Ping timeout: 480 seconds]
vstehle has joined #panfrost
erlehmann has quit [Ping timeout: 480 seconds]
erlehmann has joined #panfrost
<bbrezillon>
anholt: not if they're still used. MADVISE can let you flag unused BOs, and the shrinker will collect them if the system is under mem pressure, but otherwise all BOs except the tiler are resident.
<macc24>
jekstrand: are you using any patches related to clock stuff?
<bbrezillon>
s/tiler/tiler heap/
guillaume_g has joined #panfrost
<jekstrand>
bbrezillon: I'm going to give it a third try but every time I try to run the secondaries MR, it tanks my vim3.
<jekstrand>
I don't know if there's something wrong with it or if it just enables some test that hangs the poor little GPU a bit too hard.
<bbrezillon>
jekstrand: any kernel panic splat on the serial console?
<jekstrand>
bbrezillon: It goes into a loop trying and failing to reset the GPU
<bbrezillon>
:-(
<jekstrand>
I've got a serial console on it so it's pretty easy to see it dump
<bbrezillon>
probably a set of tests that crash the GPU, and were not executed before the secondary-cmdbuf MR. Does it keep resetting the GPU after you kill deqp-vk?
<jekstrand>
I've not tried that
<jekstrand>
I need to go try sleeping again. We'll see where it's at in my morning.
<bbrezillon>
sure
<bbrezillon>
good night (or what's left of it anyway)
<icecream95>
jekstrand: I do suggest trying to apply the kernel patches I linked to above, they improved GPU fault handling a lot for me
<jekstrand>
icecream95: Yeah, I should. I've been trying to avoid building my own kernel, though. :-/
<jekstrand>
I guess I should probably get over that
<jekstrand>
bbrezillon: I guess it's also possible that maybe there's a bad test or a 2ndary bug where we end up corrupting the command list and infinite-looping and it happens to loop on something that hangs the GPU.
<bbrezillon>
jekstrand: if the GPU recovery logic was working correctly you wouldn't get blocked though
<bbrezillon>
well, if it really loops on the same test over and over again, you would, but that's unlikely to be the case, and we've so many race-related issues in the recovery path, that I'm tempted to blame the kernel on this one
<bbrezillon>
*we've had
<bbrezillon>
if it still happens with the patches icecream95 pointed you to, we can start considering a userspace bug
<bbrezillon>
BTW, it's weird that 5.16 is more crashy than 5.14+recovery-patches, since, AFAIR, 5.16 is supposed to have those patches applied, and I don't remember any big feature addition between 5.14 and 5.16...
* icecream95
notices the O(n^2) check for identical BOs in panvk_vX_device.c.. doing 100000 comparisons on queue submit is *definitely* going to work well for a production driver
<bbrezillon>
that's just a hack until we track resources correctly at the cmd_buffer level :P
<bbrezillon>
icecream95: patches are welcome
<icecream95>
bbrezillon: I remember complaints that my trying to use lavapipe with Panfrost would result in too much CPU overhead, now look at what you lot are doing :P
rasterman has joined #panfrost
<bbrezillon>
I don't remember complaining about that, but maybe I did. And I don't think I ever said panvk was performing better than your lavapipe+panfrost solution, or that it was anywhere close to production-readyness
<bbrezillon>
the thing is, lavapipe is clearly flagged as a sw-rast-only thing. If you want to change that, maybe you should convince other maintainers that it's the way to go.
<icecream95>
bbrezillon: That wasn't you complaining.. anyway I think by now there is no point in spending any more time on lavapipe+panfrost rather than panvk
MajorBiscuit has joined #panfrost
<icecream95>
It might be useful to have another driver to compare against, but there would be no point in spending a significant amount of time on it
rkanwal has joined #panfrost
erlehmann has quit [Ping timeout: 480 seconds]
erlehmann has joined #panfrost
erlehmann has quit [Ping timeout: 480 seconds]
<tomeu>
can't compare against the DDK? :)
<icecream95>
tomeu: I haven't found any blobs with Vulkan enabled yet…
<tomeu>
:(
<icecream95>
I guess there's always drivers for Android phones, but it would take actual effort to extract those…
<icecream95>
(Chrome OS Android drivers do not seem to have Vulkan)
<macc24>
icecream95: would a blob for g31 work on g72?
<macc24>
for vulkan stuff and whatever else
<icecream95>
macc24: Well.. I could get it to work without touching the hardware, but then it wouldn't be very useful
rkanwal has quit [Quit: rkanwal]
rkanwal has joined #panfrost
rkanwal has quit []
rkanwal has joined #panfrost
nlhowell has joined #panfrost
rkanwal has quit []
rkanwal has joined #panfrost
erlehmann has joined #panfrost
<jekstrand>
bbrezillon: Fingers crossed. My CTS run has survived this far and deqp-runner says it's only got 45 minutes to go.
alarumbe has quit [Remote host closed the connection]
alarumbe has joined #panfrost
<jekstrand>
bbrezillon: Third time's a charm! Secondary run complete. I just assigned marge. \o/
guillaume_g has quit []
<bbrezillon>
yay!
<jekstrand>
bbrezillon: I think that's a good chunk of the current ToDo list done.
<jekstrand>
bbrezillon: There's probably still some goodness in your wip branch but that's a lot of it, I think.
<bbrezillon>
definitely
<bbrezillon>
and I don't think I had much more tbh
<bbrezillon>
jekstrand: guess that means you'll have a new driver to review pretty soon, because all dozen dependencies have landed now :P
<jekstrand>
bbrezillon: lol
<jekstrand>
Yeah...
<jekstrand>
Hopefully, Mark will get my blog post published today or Monday and then my review can be "Read this and do everything it says". :D
<bbrezillon>
jekstrand: and I can then reply, 'I think I did, would you mind checking I didn't forget things' :P
<bbrezillon>
more seriously, I don't think it has to be thoroughly reviewed, we expect it to have some rough edges anyway, but getting it merged will simplify things for those working on the code base
<bbrezillon>
working out-of-tree is a bit of a pain