<calcprogrammer1>
I'm trying to test Panfrost on my Rock Pi 4B. I'm using the official Debian image, dist-upgraded to buster. Built 5.2 kernel in a debian arm64 chroot and it's booting fine. Panfrost is loaded, /sys/class/drm/card0 and card1, renderD128 all there. Built several versions of Mesa several different ways (debian packaging, ninja install, with git master, 19.1, 19.1.1). Nothing seems to work though. I've tried
<calcprogrammer1>
startx/lightdm, kmscube, and weston. Every time I start something that should use Panfrost, I get kernel errors:
<calcprogrammer1>
OP said cloning master fixed it for him, but it didn't for me
<HdkR>
Maybe you need a newer kernel
<calcprogrammer1>
I'm using 5.2 final
vstehle has quit [Ping timeout: 244 seconds]
rhyskidd has quit [Quit: rhyskidd]
NeuroScr has joined #panfrost
Elpaulo has joined #panfrost
indy has quit [Ping timeout: 272 seconds]
marvs has joined #panfrost
davidlt has joined #panfrost
davidlt has quit [Ping timeout: 245 seconds]
NeuroScr has quit [Quit: NeuroScr]
vstehle has joined #panfrost
yann has quit [Ping timeout: 272 seconds]
tgall_foo has quit [Ping timeout: 272 seconds]
cwabbott has quit [Quit: cwabbott]
cwabbott has joined #panfrost
cwabbott has quit [Client Quit]
cwabbott has joined #panfrost
cwabbott has quit [Quit: cwabbott]
cwabbott has joined #panfrost
yann has joined #panfrost
cwabbott has quit [Quit: cwabbott]
cwabbott has joined #panfrost
raster has joined #panfrost
raster has quit [Remote host closed the connection]
raster has joined #panfrost
rhyskidd has joined #panfrost
adjtm has quit [Ping timeout: 248 seconds]
davidlt has joined #panfrost
davidlt has quit [Ping timeout: 272 seconds]
davidlt has joined #panfrost
adjtm has joined #panfrost
davidlt has quit [Ping timeout: 272 seconds]
davidlt has joined #panfrost
davidlt has quit [Ping timeout: 246 seconds]
afaerber has quit [Quit: Leaving]
afaerber has joined #panfrost
davidlt has joined #panfrost
xHire has quit [*.net *.split]
empty_string has quit [*.net *.split]
xHire has joined #panfrost
empty_string has joined #panfrost
yann has quit [Remote host closed the connection]
<alyssa>
calcprogrammer1: "Rock Pi 4B" is RK3399, yes?
<calcprogrammer1>
yes
<alyssa>
Alright, that's supported.
<alyssa>
Keep in mind, 19.1 is not supported.
<alyssa>
I don't know why people are trying to use it; Panfrost is specifically disabled in 19.1 since it wasn't ready for end-users and then people reenabled it and suddenly bugs happen (I wonder why)...
<alyssa>
19.2, on the other hand, I hope will be great!
<davidlt>
alyssa, are you planing to get Pinebook Pro?
<alyssa>
davidlt: I mean, I already have more RK3399 devices than I know what to do with ;)
<davidlt>
true, but it's a portable test bench with screen, keyboard and battery ;)
<alyssa>
So is Kevin
<davidlt>
silicon wise -- yes
<davidlt>
I don't think Pinebook Pro use USB PD for charging
<davidlt>
There is BT 5.0 support in Pinebook Pro, ability to use NVMe M.2, removable MMC storage
<davidlt>
and new addition: privacy switches
herbmilleriw has joined #panfrost
<daniels>
alyssa: is 19.1 still going to see another point release? if so, might be good to add a fprintf(stderr, "literally don't use this please\n"); to screen init
<tomeu>
alyssa: wonder what could be done about AFBC and modifiers, if we don't know how to drive the display and GPU HW for each of the supported AFBC variants
<tomeu>
guess AFBC_FORMAT_MOD_ROCKCHIP refers to a specific variant
<daniels>
yeah, it does
<daniels>
the definition is down in a vendor tree somewhere
<tomeu>
and guess we don't know which?
<daniels>
annoyingly I can't find the thread where AFBC_FORMAT_MOD_ROCKCHIP was actually submitted - I guess we'd have to figure out what that actually maps to in terms of the existing modifiers
<daniels>
probably the best way would be to ask the ChromeOS team to have a look and document it?
<tomeu>
yeah, i guess only the HW people know the details
<alyssa>
Granted, I'm not sure what exactly our hw does natively (on the GPU) and, assuming there are multiple configurations, how to poke at the other ones
<alyssa>
We know it's 16x16
<alyssa>
We don't know which of the other modifiers it does
* alyssa
grabs notes
<raster>
argh
<raster>
why doesnt ayufan upstream his dts's for the rockpro64?
* raster
hates ending up with kernels that dont boot because they cant find the emmc...
<alyssa>
Arrr
<raster>
aye
<raster>
2 gl clients in a wl compositor does not make panfrost happy :)
<tomeu>
that works here
<raster>
let me get my mesa totally up to date
<raster>
tomeu: thinged enede up frozen for me
<raster>
userspace - couldnt ssh in :)
<raster>
using linux-next
<raster>
i had to fix linux-next - build was broken. amdgpu drivers and new HMM stuff was broken
<raster>
didnt even copile
<raster>
# of build targets for mesa keeps going up. its 1008 now for me :)
<raster>
i remember it was like ~700 not long ago
<raster>
then 900 odd
<raster>
now over 1k
<alyssa>
tomeu: /me grumbles about code bloat
<raster>
code always bloats
<raster>
or it is dead
<raster>
:)
<rcf>
raster: on boring 5.2 I get similar results, though it didn't completely lock up.
<raster>
well i wate3d a min or 2 to ssh login
<raster>
gave up and hit reset :)
<raster>
it may have been working... slowly :)
raster has quit [Remote host closed the connection]
<tomeu>
OOM?
<rcf>
If I weren't focused in the terminal and able to hit Ctrl+C quickly it may not have ended so easily.
raster has joined #panfrost
<rcf>
That would seem to be the case, actually.
<alyssa>
OOM is very likely
<raster>
i have this weird thing still- this is newish in panfrost
<raster>
_evas_outbuf_egl_setup() eglCreateWindowSurface() fail for 0xaaab11ad74f0. code=0x3003
<raster>
havent quite dug into what config/params it is
<raster>
BUT
<raster>
the interesting thing is after this
<raster>
enlightenment does start
<raster>
something is up/screwy in kernel context somewhere
<raster>
and gl works
<raster>
this failed init then triggers future processes to work
<raster>
well elm test wont work
<raster>
no matter what
<raster>
but
<raster>
fbos seem to function now
<raster>
yay
<raster>
stuff not totally broken
<raster>
woot
<daniels>
0x3003 is EGL_BAD_ALLOC, which is usually only returned if you try to create two EGL surfaces from the same native window
<daniels>
if you run with EGL_LOG_LEVEL=debug, it should tell you where/why the error is being generated
<daniels>
given FBOs are working, it's not going to be down in the kernel, since the path to create an FBO and the path to create a native surface are exactly the same as far as the driver/kernel are concerned; the only difference is in higher API layers
<raster>
oh fbo's are parallel
<raster>
this is long pre any fbos
<daniels>
right, but I mean, if you can allocate FBOs and not window surfaces, then I would definitely be looking at EGL usage rather than 'something is up/screwy in kernel context'
<raster>
well more one process changes the behavior of a future process
<raster>
2 unrelated processes
<raster>
1nd always fails to init
<raster>
run aother that fails too
<raster>
then first succeeds after that
<raster>
obviously some out-of-process state changed permanently
<raster>
my guess its kernel state
<raster>
well there we go
<raster>
its going super slow again
<raster>
:)
<raster>
2 gl using wl clients hammering away - panfrost is not happy
<raster>
and i'm pretty up to date now
<alyssa>
Probably still OOM..
<alyssa>
How much memory is on the board?
<raster>
4gb
<raster>
:)
<alyssa>
Hmm :/
<raster>
ok
<raster>
i got a shell
<raster>
just
<raster>
free -m
<raster>
waiting for the results
<raster>
:)
<raster>
not sure its oom
<raster>
nope
<raster>
247m used
<alyssa>
Hrm
<raster>
i think its gpu resets
<alyssa>
That would do it, yes
<raster>
i see a lot of those
<alyssa>
raster: If you're able, could you launch with:
<alyssa>
PAN_MESA_DEBUG=trace
<alyssa>
That will spam a *lot* to stdout
<alyssa>
So redirect that to a file, compress it, and send it to me
<raster>
oh dear that will be spam from multiple processes
<raster>
remember this is gl wl compositor with 4 gl wl clients
<alyssa>
Presumably you'll have GPU faults even with 1 client..?
<raster>
2 of those are hammering away at 60fps with animation (simple stuff tho - like 10 triangles each)
<raster>
oh i see it often - yeah
<raster>
oh god
<raster>
dmesg is taking forever
<raster>
lots of unhandles pagefaults
<raster>
err unhandled pagefaults
<alyssa>
Yeah, I need a trace then
<alyssa>
And preferably also a snippet of dmesg (just enough to see some representative failing accesses)
davidlt has quit [Ping timeout: 245 seconds]
<raster>
also drm atomic wait for vblank timeout too
<raster>
i need to get something simpler/cleaner for u than this mess
<raster>
:)
<alyssa>
That would be apreciated! :P
<alyssa>
If you run E alone without any clients, does it fault too?
<raster>
just letting u know the rough kind of things i am seeing
<raster>
well gettign e to start is the above adventure
<raster>
it fails to init at all unless i get elementary_Test to fail to init egl first
<raster>
something is up therte with 1 process changing some kernel state so another then succeeds
<raster>
well i smell a rat :)
<raster>
i'll start with that
<alyssa>
Hm?
<raster>
let me reboto
<raster>
this is unusable :)
<raster>
reboot :)
<raster>
ok
<raster>
1st run
<raster>
oh wait
<raster>
it works now
<raster>
wtf?
<raster>
this is random
<raster>
ok
<raster>
e is up
<raster>
no dmesg complaints
<raster>
all good
<raster>
1 terminology up - gl rendering with htop (or should be gl)