ChanServ changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs - <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
<jekstrand> Yeah
<jekstrand> I hear you
<bbrezillon> jekstrand: those failures are related to the event issue I was talking about the other day
<jekstrand> bbrezillon: Hrm...
<jekstrand> bbrezillon: I saw that some of the exec twice stuff didn't work but didn't realize it was events
<bbrezillon> we get passed an unsignaled event that translate to a syncobj with a NULL fence
<bbrezillon> and the driver rejects the command submission
<bbrezillon> jekstrand: see; for the original discussion
<bbrezillon> jekstrand: uh, wait, I think dEQP-VK.api.command_buffers.record_many_draws_secondary_2 was passing here
<bbrezillon> ah, nevermind, it's a whitelist
rkanwal has quit []
rkanwal has joined #panfrost
rkanwal has quit []
alyssa has joined #panfrost
<alyssa> Milestone: my Valhall bring up branch should now pass GLES 2.0 conformance :-D
<anarsoul> alyssa: yay!
<alyssa> 53 files changed, 5304 insertions(+), 690 deletions(-)
<alyssa> I seem to be writing code faster than I'm upstreaming code. Shame :|
<alyssa> posted the top 20 easy patches, after which we're down to
<alyssa> 46 files changed, 5116 insertions(+), 574 deletions(-)
<alyssa> that doesn't help all that much, does it :V
<HdkR> \o/
MajorBiscuit has quit [Ping timeout: 480 seconds]
<macc24> alyssa: if u git reset --hard u can go to `0 files changed`
<alyssa> thonk
* alyssa stares at dEQP-GLES3.functional.shaders.texture_functions.texture.sampler2darrayshadow_vertex
<alyssa> ok, gles2 passing, gles3 very close, gles31 far away... woof
<alyssa> Pass: 441, Fail: 11, Crash: 225, Skip: 820, Flake: 3, Duration: 46, Remaining: 18:45
<alyssa> gles31 is not happy lol
<alyssa> 65% passing for gles31. yeah, will have to tackle that next lol
anarsoul|2 has joined #panfrost
anarsoul has quit [Read error: Connection reset by peer]
<alyssa> Pass: 11409, Fail: 254, Crash: 5316, Warn: 22, Skip: 20689, Flake: 101, Duration: 7:47, Remaining: 0
<alyssa> okay yeah so we have some serious compiler work for gles31 (...and literally any vulkan)
<alyssa> but hey, 67% passing is a C
<alyssa> will have to RiiR to get any better
<macc24> alyssa: 67% passed is way better than my grades in school :D
<alyssa> snrkt
<alyssa> framebuffer_fetch stuff is failing, that looks like a low hanging fruit
<macc24> alyssa: btw, is kevin usable yet with panfrost for people who don't like slideshows?
<alyssa> ...sure?
<alyssa> Midgard stopped receiving active dev a year and a half ago...
<macc24> i remember its absurd screen resolution being... problematic
<macc24> oh
<alyssa> but I use two Kevins as primary machines (with panfrost obviously) and it works for me? YMMV
macc24 has quit [Quit: ZNC 1.7.5+deb4 -]
macc24 has joined #panfrost
<macc24> server administration tip: don't press the power button when you don't want t o
<alyssa> was just missing a wait before ld_tile, that gets us further
<alyssa> MSAA tests still failing
anarsoul|2 has quit []
anarsoul has joined #panfrost
erlehmann has quit [Ping timeout: 480 seconds]
erlehmann has joined #panfrost
pch has quit [Read error: Connection reset by peer]
davidlt has joined #panfrost
soreau has quit [Read error: Connection reset by peer]
soreau has joined #panfrost
pch has joined #panfrost
JulianGro has joined #panfrost
davidlt has quit [Ping timeout: 480 seconds]