* alyssa
just landed a cleanup for liveness analysis
<alyssa>
Something I started on the plane and just finished
<alyssa>
Should put us in a good shape to integrate liveness analysis with the scheduler
<alyssa>
And even if that doesn't pan out, I mean ..... it was still a needed cleanup
_whitelogger has joined #panfrost
vstehle has joined #panfrost
davidlt has joined #panfrost
marvs has quit [Ping timeout: 246 seconds]
megi has joined #panfrost
marvs has joined #panfrost
raster has joined #panfrost
<robmur01>
hmm, so I managed to build mesa and kmscube in a 32-bit chroot
<robmur01>
kmscube did run and display OK, but stopping it threw the kernel into a loop of reporting spurious translation faults from taking a lock in panfrost_mmu_map_fault_addr
adjtm has quit [Ping timeout: 276 seconds]
mrfixit2001 has left #panfrost [#panfrost]
mrfixit2001 has joined #panfrost
<robmur01>
ah, native 64-bit also hits a GPU page fault on exit, but manages to do so cleanly without killing the kernel
<mrfixit2001>
Here are the gpu sched errors I get in dmesg when I run kmscube on my build: https://pastebin.com/fHfb6qKL
<mrfixit2001>
It doesn't kill the kernel or crash the board, just simply doesn't render anything to the screen.
<mrfixit2001>
I tried forcing the display as well, no luck
<mrfixit2001>
Have there been updates to kmscube that maybe I need to make sure I use?
<mrfixit2001>
Can you advise what compile flags you used for mesa when you compiled it for panfrost?
<robmur01>
mrfixit2001: FWIW I'm testing on a totally different machine, so there may be some additional variability there
<mrfixit2001>
understood. But thanks for testing at all ;) Which mali are you testing on? Mine is rk3399 mali t860
<robmur01>
I did try on my RK3399 last night, but for some reason the Arch kernel doesn't have compat enabled, so I fell down the rabbit-hole of trying to rebuild the kernel package 'properly'
<robmur01>
(in retrospect I really should have saved myself 2 hours by just bodging it)
<mrfixit2001>
haha well I can at least confirm my kernel build has CONFIG_COMPAT=y
<mrfixit2001>
which rk3399 did you try testing on and what kernel version
<robmur01>
right now I'm running a T820 (in FPGA) on an Arm Juno board; at home I'm playing with a NanoPC-T4
<robmur01>
come to think of it, the comparatively glacially-slow GPU is probably really good at tickling job-stop race conditions...
<robmur01>
nah, my Juno hacks only apply to the 'hard' T620 in the SoC itself - the FPGA expansion is a separate game ;)
afaerber has quit [Quit: Leaving]
<mrfixit2001>
Ok, so one thing I haven't yet investigated is perhaps some changes that may be needed to the device tree? Where can I find the source for the kernel and dts you're testing with
<robmur01>
Just loaded up a T860 bitfile and that works OK too, so it looks like this isn't a fundamental panfrost problem
<robmur01>
kernel here is 5.4-rc1 (with a few bits of extra tat which aren't relevant)
<robmur01>
I'd guess the principle difference is probably the display driver - I'll have another stab at testing this chroot on Rockchip over the weekend
<mrfixit2001>
So if we pretend that the kernel driver is "okay", since it actually does init properly... that leaves compiling mesa itself... do those build flags look correct?
<robmur01>
in the meantime, we definitely seem to have a race between stopping jobs and unmapping, yay...
yann has joined #panfrost
<robmur01>
FWIW this is with a fresh clone of mesa/master - the "add arbitrary build flags until it stops whining about dependencies I can't be bothered to install" process ended up with:
<robmur01>
and the 32-bit chroot environment is an "ArchLinuxARM-armv7-latest" image
adjtm has joined #panfrost
<rtp_>
robmur01: oh, so you're testing panfrost on t6xx ?
tlwoerner has quit [Ping timeout: 276 seconds]
tlwoerner has joined #panfrost
<robmur01>
rtp_: not really "testing", but I've been running stuff for giggles because it's there and I can :)
<rtp_>
robmur01: oh ok
<mrfixit2001>
robmur01 I'm building up the latest kernel and mesa commits to compare exactly what you've run.
<mrfixit2001>
I can't get away with those minimal mesa build flags however. It insists I set dri-drivers (in my case, to nothing) otherwise it complains about unknown arch
<mrfixit2001>
same with vulkan-drivers=
<robmur01>
hmm, so apparently meson can't be picking up the expected thing from "host_machine.cpu_family()"
<robmur01>
oh, wait, you mentioned buildroot so I guess you're cross-compiling. Derp...
<mrfixit2001>
exactly :) So cross-compiler needs these at a minimum. But I've left everything else out of the flags except what you provided as well as the dri and vulkan drivers. Bleeding edge commits on both.
<narmstrong>
mrfixit2001: hmm why would you absolutely test on 32bit arch ?
<narmstrong>
do you have a specific reason to stay on 32bit armv7 ?
<mrfixit2001>
performance on specific applications is optimal for 32-bit. My builds provide both a large list of emulators for retrogaming as well as kodi for media playback. Both perform better as 32-bit.
<mrfixit2001>
Everything is still compiled for armv8
<robmur01>
yeah, I guess emulators with dynamic recompilers for AArch32 but not AArch64 have a relatively strong argument
* robmur01
wonders if adding 32-bit compat jobs to the 64-bit CI platforms would be worthwhile
<narmstrong>
trying 64bit would validate the kernel, mesa and the HW :-)
<robmur01>
true, I guess if there's at least one 32-bit platform to test 32-bit builds already, then compat runs wouldn't really add much
<Lyude>
alyssa: that was a -really- good presentation, nice job!
<Lyude>
i learned a good bit myself from watching :)\
<Lyude>
*:)
<alyssa>
Lyude: Thank you!
<tlwoerner>
lol! _great_ sense of humour :-D
<alyssa>
tlwoerner: Huh?
<alyssa>
Who said I was joking?
<tlwoerner>
that's it... stay in character... lol
<alyssa>
tlwoerner: Character?
<tlwoerner>
so many talks at technical conferences are so dull, it's great to see when presenters actually put some effort into it
<narmstrong>
I always try to add funny memes, but often technical talks aren't funny _at all_
<alyssa>
narmstrong: Don't suppose you sw the stream?
<narmstrong>
I saw it, and it lacked funny memes on each slides !
<alyssa>
:D
yann has quit [Ping timeout: 246 seconds]
adjtm has quit [Ping timeout: 240 seconds]
<urjaman>
oh seems like i've missed something
stikonas has joined #panfrost
raster has quit [Remote host closed the connection]
Yardanico has joined #panfrost
afaerber has joined #panfrost
<tomeu>
robmur01: guess we could run at least run nightlies on armhf
<mrfixit2001>
sadly still no luck with the build. Latest commits from mainline kernel and mesa, and still seeing gpu sched errors. It's very odd to me that the other apps are looking for opengl as well.
<mrfixit2001>
interesting retroarch runs just like kmscube, starts up and everything but the display is blank. It's almost like it's rendering to the wrong layer or coordinates or something idk, but it doesn't crash.
<mrfixit2001>
applications that use sdl2, such as emulationstation and ppsspp fail and can't find opengl.
<mrfixit2001>
FWIW this is the only issue I see when running retroarch "warning: extension `GL_OES_standard_derivatives' unsupported in vertex shader" and
<mrfixit2001>
dmesg still has the gpu timeouts ofc
<Yardanico>
I tried to apply these because panfrost didn't work with generic arch linux arm kernel as well (there was a different error code in GPU Fault though)
<Yardanico>
ah, maybe these fixes didn't get applied, gonna check that
NeuroScr has joined #panfrost
<Yardanico>
So after applying these fixes it doesn't crash, but Xorg says there are no displays, and glxgears or glxinfo doesn't output anything about panfrost, maybe I should try latest mesa from git and not 19.2.0?
<Yardanico>
well, I mean, I launched xorg using xf86-video-fbturbo-git, not panfrost
<Yardanico>
ah, I'm a bit stupid, panfrost doesn't have an opengl AFAIK, only opengl es 2.0