<alyssa>
chewitt: Er I thought I pushed a patch to fix that
<alyssa>
Wait translate_swizzle?
<alyssa>
chewitt: Regardless, pull the latest code and rebuild
<alyssa>
(From connor-updated-formats branch)
<chewitt>
that's the current panfrost master + narmstrong changes for amlogic + PR17
<chewitt>
ahh.. using PR17 from about ~2 hours ago
<chewitt>
I see there are updates
<alyssa>
I've been busy :)
<chewitt>
rebuilding..
<cyrozap>
So I pretty much just spent my whole weekend messing with U-Boot and bringing up Arch Linux ARM on most of the rest of my mini PCs.
<cyrozap>
Now I have a mainline U-Boot and kernel running on a Tinker Board (RK3288, Mali-T760 MP4), an ODROID-C2 (Amlogic S905, Mali-450 MP3), and two Orange Pi PC 2's (Allwinner H5, Mali-450 MP4).
<mifritscher>
:)
* cyrozap
is basking in the glory of fully-FOSS boot
<cyrozap>
Now that I've gotten the hang of this, next weekend I'll probably try fiddling around with booting mainline U-Boot+kernel on my RK3399 boxes.
<cyrozap>
Oops, minor correction--the ODROID-C2 still has a mostly-proprietary boot process, with proprietary BL2, SCP_BL2, and BL31 components (though supposedly the BL2 sources were open for a while before being closed?)
<tomeu>
chewitt: awesome! so the issue with text is fixed?
<chewitt>
yes, that's resolved
<chewitt>
one down .. lots to go :)
* tomeu
is now installing gnome-shell in his board :)
chewitt has quit [Quit: Adios!]
pH5 has joined #panfrost
<narmstrong>
alyssa: is it easily possible to render to a AFBC fb plane ?
BenG83 has quit [Ping timeout: 258 seconds]
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
MoeIcenowy has joined #panfrost
<tomeu>
narmstrong: I'm interested in looking at that, but haven't checked if the rockchip display driver already has support for it
<tomeu>
narmstrong: does meson support it in mainline already?
BenG83 has joined #panfrost
<narmstrong>
tomeu: no, and offical support from ARM (with proper DRM modifiers) is not yet merged anyway
<narmstrong>
tomeu: but I'll be interested to support it, for panfrost and for the bifrost libmali on newer amlogic socs
<narmstrong>
alyssa: opened !18 to add the meson winsys driver
<narmstrong>
alyssa: and !19
_whitelogger has joined #panfrost
raster has joined #panfrost
afaerber has quit [Quit: Leaving]
afaerber has joined #panfrost
stikonas_ has joined #panfrost
stikonas_ has quit [Remote host closed the connection]
stikonas_ has joined #panfrost
stikonas_ has quit [Remote host closed the connection]
gtucker has joined #panfrost
chewitt has joined #panfrost
raster has quit [Remote host closed the connection]
griffinp has joined #panfrost
robher has joined #panfrost
<chewitt>
@alyssa I know we know there are memleaks, but..
<chewitt>
if I leave Kodi open on the 'settings > system info' page you can watch the free mem count down in 1MB increments :)
raster has joined #panfrost
<tomeu>
hehe
<tomeu>
raster: were you able to get things running?
<tomeu>
alyssa: any thoughts on GL_TEXTURE_RECTANGLE support?
<tomeu>
hmm, it didn't need much hacking to get gnome-shell to render half a cursor on the screen :)
NeuroScr has joined #panfrost
<tomeu>
alyssa: basically, I needed to comment out two asserts to get the process up and running (though not much rendered to the screen)
<tomeu>
assert(!depth_stencil->alpha.enabled);
<tomeu>
gnome-shell depends on some ES3 stuff
<tomeu>
and assert(template->target == PIPE_TEXTURE_2D);
<tomeu>
we were getting a PIPE_TEXTURE_RECT instead, though it should be quite similar to a 2D, from what I have seen
<tomeu>
I'm getting these in the console each frame:
<tomeu>
Jan 07 15:58:00 cizrna kernel: mali ff9a0000.gpu: error detected from slot 0, job status 0x00000058 (DATA_INVALID_FAULT)
<tomeu>
Jan 07 15:58:00 cizrna kernel: mali ff9a0000.gpu: t6xx: GPU fault 0x58 from job slot 0
<raster>
tomeu: oh hey man
<raster>
was just chatting with beata....
<raster>
ummm no- havent got it working
<raster>
i'm wondering what i have gotten wrong
<raster>
i've basically got
<raster>
failed to load driver: rockchip
<raster>
and a whole bunch of other faileds...
<raster>
even tho i enabled the rockship dri driver
<alyssa>
narmstrong: Yeah, AFBC rendering is just a matter of some refactors
<alyssa>
FBOs are already all AFBC (de facto mandated by the hardware, since at the time I didn't know enough about formats to do it any other way. And by the time I could have done it a different way, I mean, it's the better approach)
<alyssa>
tomeu: Oh, neat. DATA_INVALID_FAULT is... possibly the most annoying fault to deal with, since it's so vague. Panwrap helps but.. yeah
<alyssa>
Rect textures aren't something I've looked into but ought to be easy enough, I can poke at that today if you'd like
<raster>
alyssa: hey... you still do your work on a rockpro64?
<alyssa>
raster: A samsung chromebook plus, but yeah
<raster>
3399 right?
<alyssa>
Mm
<alyssa>
We recently merged code which bumps us to use the latest mali_kbase, so that probably breaks old everything
<raster>
hmmm
<alyssa>
I'm not sure if the newer rockpro64 images have corresponding newer mali_kbase versions
<raster>
well i had to enable the rockpro dri driver (not detailed in instructions for building panfrost)
<alyssa>
(At the same time, we also merged code to switch to an actual GBM driver, rather than the X11 hacks we had piling up before. So running from within X11 won't work anymore; you'll have to use DRM apps from the framebuffer)
<raster>
Linux rp64 4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1 #1 SMP Mon Oct 22 20:59:41 UTC 2018 aarch64 GNU/Linux
<alyssa>
I haven't the foggiest idea what tree ayufan tracks anymore..
<chewitt>
one of our devs has a 4.20 or 4.21 branch for RK stuff .. he's busy writing a stateless V4L2 decoder so needed the newer kernel
<chewitt>
I'll see if I can dig up the URL
<alyssa>
raster: Just to make sure, are you trying to load X11 apps from within X, or DRM/GBM apps from the console?
<raster>
hmmm. the mali drivers do work (with some minor wl compositor+client buffer bind/sync issues)
<raster>
just trying drm in xonsole atm
<raster>
console
<alyssa>
Alright, that's good
<raster>
havent even gotten to wl clients yet
<alyssa>
To state the obvious, /dev/mali0 is chmod 666'd?
<raster>
chewitt: if there is one that has hdmi working.. that'd be great
<raster>
alyssa: yup
* alyssa
blinks
<alyssa>
Hmm
<raster>
it works as a user with mali drivers :)
<raster>
0 crw-rw-rw- 1 root video 10, 56 Jan 7 15:02 /dev/mali0
<raster>
already handled in udev...
<alyssa>
IIRC the Arm drivers might have been setuid or something? Just trying to eliminate all the "easy" answer :)
* alyssa
checks what kbase version ayufan is on
<raster>
well drivers cant be setuid
<raster>
they are .so's malled in by the calling process .. as the process
<raster>
i run the stuff as me :)
<alyssa>
Alright. Not sure what I heard then.
* alyssa
shrugs
<raster>
trying to get a panfrost setup at least working as well as panfrost currently works
<raster>
but still stuck at the doorway ... can't get in :)
<alyssa>
Wait, panfrost currently works on there?
<raster>
mali binary drivers work
<raster>
the rockchip released ones
<raster>
with this kernel
<alyssa>
" as panfrost currently works"
<alyssa>
Do you mean, like, older builds of Panfrost currently work as well?
<raster>
well as wellas YOU have it working
<alyssa>
Ah
<raster>
not working for me yet
* alyssa
hasn't built Panfrost on that particular device since XDC
<raster>
so ie - i see the same working bits and bugs as you do... not expecting panfrost to be fully working yet
<alyssa>
Understood
<raster>
i had hoped at least i'd get some thigns rendering...
<raster>
like images (argb) rectangles
<raster>
hoping alpha textures too
<raster>
and enough shader compiler correctness for these relatively simple shaders
<alyssa>
Alpha texttures should mostly work
<alyssa>
tomeu: What kernel are you on? Mainline?
<raster>
also enough gbm/drm buffer correctness for wl clients to work
<raster>
if i should compile/try another kernel... i'd love to know which one - problem is the mali drivers have to be patched in so its all a fragmented mess, thus why i ask :)
<alyssa>
Yeah :)
<raster>
i had hoped since you used it at xdc you still did :)
<alyssa>
Well, on my development Kevin (SC+), I'm running a pure mainline 4.20 kernel, straight off Torvalds' tree a week or two ago
<alyssa>
With tomeu/Lyude's mali_kbase fork compiled and insmod'd out-of-tree
<alyssa>
Since I wasn't sure either when merging their stuff so I figured it'd be safe to match the kernel exactly ;)
<raster>
well tbh last timei tried to merge a mali kernel patch into the kernel it was conflict hell and i lost interest in a day or so of figuring it out :)
<alyssa>
That's fair :P
<raster>
(without knowing the kernel changes that caused the conflicts nor the mali patch code either.. it was not too fun to figure it out :()
* alyssa
presses thumbs against temples
<raster>
last i heard the rp64 doesn't have working hdmi in mainline but its in linux-next or somthing
<raster>
no hdmi would be a bit of a... problem
<alyssa>
Ouch >_>
<alyssa>
raster: Any chance you have a RK3399 Chromebook floating around somewhere with Linux already running?
<raster>
i have found a 4.20 kernel ayufan built with hdmi in it
<raster>
so yay
<alyssa>
Oh! :)
<raster>
BUT...
<raster>
the kbase mali doesnt load....
<raster>
errr...
<raster>
maybe because i own it
<alyssa>
...and the plot thickens
<raster>
nope
<raster>
no such device... ?
<alyssa>
?!
<alyssa>
tomeu: Lyude: Any clues? ^^
<raster>
i am assuming it cant find the mali device
<raster>
... gzaarh
<Lyude>
Missing parts in your devicetree
<raster>
i was about to say...
<raster>
but the 4.4 had it
<raster>
gah
<Lyude>
which 4.4 kernel, mainline?
<raster>
chasing a magic kernel with the right patches, right config ... and right dt (patched or whatever) is not fun
<Lyude>
Or some sort of Android kernel, etc.
<raster>
4.4 from ayufan
<Lyude>
raster: yeah
<raster>
i just wanted to get on with userspace :)
<Lyude>
I think we are close enough to upstreaming though we should start sending all the required DT stuff for all the devices we have working so far upstream
<raster>
indeed
<Lyude>
what soc is this btw?
<raster>
3399
<alyssa>
Lyude: I thought the DT is upstream already for a bunch of devices
<Lyude>
alyssa: some devices don't have the Mali parts, I know meson doesnt
<alyssa>
Gotcha
<Lyude>
Rk3399 did though, at least I thought
<alyssa>
(The rockchips do, at least some)
<alyssa>
At least Kevin has it
<alyssa>
..I think
<raster>
well this is a 4.20 - not next...
<Lyude>
That should still have it though
<Lyude>
or Kevin does at least
<raster>
hmmm
<alyssa>
Lyude: What if the chromebooks have it but the boards don't maybe?
<Lyude>
It's probably just missing the one for your specific board
<raster>
odd that it's a kernel specifically for my board
<Lyude>
alyssa: it could be chromeos kernel, if that's what you are using, just has the dt stuff baked in
<raster>
[ 1808.670989] mali_kbase: Unknown symbol kbase_platform_unregister (err -2)
<raster>
etc.
<Lyude>
wat...
<raster>
well
* Lyude
takes a look
<raster>
[ 554.073830] Couldn't find the mali node
<raster>
actually no
<raster>
the above is right
<raster>
much earlier in boot
<alyssa>
I'm so confused
<Lyude>
hm. so kbase_platform_register()/kbase_platform_unregister() should be provided by ./driver/product/kernel/drivers/gpu/arm/midgard/platform/devicetree/mali_kbase_config_devicetree.c
<raster>
oh wait
<Lyude>
which makes me think maybe CONFIG_OF isn't being set, but that would mean you have dt off
<raster>
that might be.. i didnt build the kernel - found ayufan's 4.20
<raster>
CONFIG_OF=y
<raster>
thats from config.gz
<raster>
i'll let my kernel builds go overnight.. then i can do my own kernels from there.
<Lyude>
hol on
<raster>
will try again tomorrow
<raster>
:)
<raster>
?
<Lyude>
alight-one last thing if you have a second though
<raster>
i'm keeping the system mesa pkgs clean and untouched
<Lyude>
mhm-that's what I do as well
<raster>
this allows me to switch mali vs panfrost with some ld lib path fun
<raster>
and/or ld.so.conf fun
<Lyude>
So you should have some *panfrost*.so file in your mesa output dir if everything built correctly, if you've got that then the question must be why it's not probing the GPU
<Lyude>
alyssa: I don't have my buildtre setup at the office right now for reasons... would you mind doing a clean rebuild off master just to double check evrything's still working?
<cwabbott>
alyssa: maybe what we need to do is put the swizzle described by util_format into the spot next to the format (bottom/unk1) and the user-specified swizzle in the other place
<cwabbott>
and not compose them
<alyssa>
It's quite possible
<alyssa>
Gathering more data!
<cwabbott>
I guess gallium has a different idea of what alpha is than GL, but since this is gallium we have to obey gallium rules
<cwabbott>
actually, they have the same idea
<cwabbott>
I think what's happening is that your code is
<cwabbott>
whoops
<alyssa>
So the "alpha-only" texture is encoded with a MALI_R8_UNORM format code