<tomeu>
daniels: I put delays before and after submitting job batches and saw no differences, but I guess I should try as you say because it would be telling and quick
<tomeu>
alyssa: those are good suggestions, I have to look at panwrap at some point but was trying to postpone the time needed to setup the blob for as long as possible
<tomeu>
alyssa: btw, I'm getting error detected from slot 0, job status 0x00000058 (DATA_INVALID_FAULT) when running kmscube, but not with weston, which shows similar artifacts
<tomeu>
or I think, will check next time I hack on panfrost
TheKit has quit [Remote host closed the connection]
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
TheKit has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
<narmstrong>
alyssa: I also have error detected from slot 0, job status 0x00000058 (DATA_INVALID_FAULT), but output is correct
BenG83 has joined #panfrost
<narmstrong>
tomeu: I have near-zero-artifact weston now, but it blocks after a few seconds
<tomeu>
narmstrong: sounds great, what did you have to do?
<narmstrong>
same for kmscube, it stops after a few seconds
<tomeu>
will give another look at event handling when I get back to panfrost
<davidlt>
tomeu, you mean rendering or working weston?
<narmstrong>
tomeu: (It may be a shame) I backported all the panfrost patches on top of the lima-18.3 branch and took your "Don't emit framebuffer at context creation time", "Use struct base_jd_event_v2 when handling events" and "increment correctly kbase_ioctl_job_submit.addr array pointer" fixes
<narmstrong>
davidlt: both
<davidlt>
nice, that's a nice progress even for 2 seconds :)
<narmstrong>
tomeu: I created a monster, but I will be able to run Kodi with it (Lima renders perfectly with kodi)
<tomeu>
I'm a bit confused, what has lima to do with this?
<narmstrong>
davidlt: sure ! It's a great move, considering we don;'t have a binary libMali for the t820
<narmstrong>
tomeu: nothing, but it doesn't use mesa master branch, but the 18.3 release, it may be related
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
<narmstrong>
davidlt: but I can't run es2gears_wayland or glmars2-es2-wayland, I get an error initializing EGL
<tomeu>
ok, then I guess I won't be able to directly help with it
<tomeu>
narmstrong: where is the process blocked?
<narmstrong>
tomeu: no idea, I need to figure that out, when blocked weston can't be killed and stays defunct, but it's the same behaviour as with kmscube, I see a bunch of `TODO panfrost_flush_resource` then nothing
<tomeu>
ok, if it's in force_flush_fragment, then we probably need to expand it to handle more events, like I did with BASE_JD_EVENT_JOB_INVALID
<narmstrong>
ok, it's the `error detected from slot 0, job status 0x00000058 (DATA_INVALID_FAULT)` that causes the blocking
<narmstrong>
And I can't even stop GDB in this case
<tomeu>
if you attach to the blocked process with gdb -p <pid>, you cannot get a backtrace?
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
<chewitt>
tomeu: the backport to 18.3 is largely my request .. we are proving/testing lima on other hardware from the same OS build-system so the lima/panfrost patch-sets need to coexist
<chewitt>
using 'stable' releases as the base is also lots easier when working with large patch-sets
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
raster has joined #panfrost
<narmstrong>
tomeu: no it’s stuck in the kernel, it’s a wait_event_killable... I’m trying to switch to an interruptible wait so I can backtrace
<narmstrong>
But the gpu fault is the main issue ! And I have really no idea how to solve it
<narmstrong>
I’m not sure Alyssa worked a lot on this kbase driver version, so maybe it was fixed in the older version
<mmind00>
narmstrong: looks like I still need to pester someone for a Reviewed-by, before I can apply that
<mmind00>
narmstrong: and yep, at least on the lima side this made output a bit nicer
<narmstrong>
mmind00: oh I missed it
<narmstrong>
I can r-b it
<narmstrong>
mmind00: can you apply it ?
<narmstrong>
now you can :shipit:
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
<Lyude>
narmstrong: not 100% sure myself either, I'm thinking a place to start might be getting some replays and start trying to disable various steps to see which one causes the error to go away
<Lyude>
have you used panwrap before?
<narmstrong>
Lyude: not at all
<Lyude>
alyssa: btw, do you know if it's possible that different Mali GPUs in the t8xx generation might not all have the same fragment shader core and thus, some might only support SFBDs?
<Lyude>
I've been meaning to check the Mali GPU props to make sure we aren't hitting some silly issue like that
<Lyude>
narmstrong: so currently the mesa fork we have builds a libpanwrap.so
<Lyude>
If you LD_PRELOAD it and run something with panfrost, it will generate a "replay" which essentially consists of an autogenerated C program based off the API interactions between kernel and panfrost
<Lyude>
If you compile and run that program, it's supposed to be identical to the actual demo you ran, but since it's all C code you can modify the replay, recompile and mess around with it without needing to change panfrost
<narmstrong>
Wow super cool !
<Lyude>
Mhm-its a neat idea Alyssa got from Lima, I think they used to have something similar
<Lyude>
narmstrong: something I forgot to mention-i haven't tested replays with the kapi update
<Lyude>
So some stuff in that might need fixing
<Lyude>
It generates code, but I haven't tried compiling any of it
<alyssa>
tomeu: panwrap is not just for the blob, it's also for tracing our own driver :P
<Lyude>
Until we have our own kmod of course
<alyssa>
Lyude: "btw, do you know if it's possible that different Mali GPUs in the t8xx generation might not all have the same fragment shader core and thus, some might only support SFBDs" This is highly unlikely
<alyssa>
Since SFBD/MFBD support corresponds to support for MRT, a feature mandated in ES 3.2
<Lyude>
alyssa: eventually we should probably split it back out again eventually so we can have it in a position so we can use it like how freedreno uses it in addition to just having replays: e.g. allow it to translate whatever kapi calls we make to our (eventual) kernel driver to mali_kbase to make new hw bringup easier
<Lyude>
alyssa: ahhh
<Lyude>
Good to know :)
<alyssa>
AFAIK, all t8xx is labeled as 3.2 compliant
<Lyude>
(also that panwrap split won't happen for a pretty long while, but figured I'd just put that out there)
<Lyude>
alyssa: does that make sense btw? I know you wanted to also figure out how to get the disasm integrated into mesa
<alyssa>
Lyude: Ehh
<alyssa>
The reason I had it split out is so we're sharing headers
<alyssa>
And every build of mesa also builds panwrap
<Lyude>
alyssa: mhm-we could just install the headers alongside mesa
<alyssa>
Which means I can gaurantee panwrap is still working at every given commit and not out of sync (which is what was happening like crazy)
<Lyude>
btw
<Lyude>
This wouldn't happen until we have a fully functional kernel driver
<alyssa>
Gotcha
<alyssa>
Lyude: Also, PM?
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
<narmstrong>
Lyude: I’ll have a run, thanks !
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
anarsoul|2 has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
pH5 has joined #panfrost
cwabbott_ has joined #panfrost
cwabbott has quit [Ping timeout: 250 seconds]
cwabbott_ is now known as cwabbott
robert_ancell has joined #panfrost
<narmstrong>
Lyude: currently trying, but dummy question, where does it "generate" the code ?
<narmstrong>
`LD_PRELOAD=/usr/local/lib/aarch64-linux-gnu/libpanwrap.so ldd` shows me libpanwrap in the list
<Lyude>
might be that panwrap needs to be updated to detect the new ioctls
<narmstrong>
let me retry
unoccupied has quit [Quit: WeeChat 2.2]
<Lyude>
narmstrong: if what you're trying now doesn't work I bet we just need to update panwrap a bit
<narmstrong>
Lyude: yeah maybe !
<Lyude>
narmstrong: the way it starts tracing is basically by overriding the ioctl() functions through the LD_PRELOAD, then checking what the arguments/file names being passed through to it are