alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - https://gitlab.freedesktop.org/panfrost - Logs https://freenode.irclog.whitequark.org/panfrost - Transientification is terminating. Memory reductions in progress.
<thefloweringash> gtucker: thanks for the details on depthcharge!
<thefloweringash> ezequielg: still having mixed results. my test image boots all the way to X but the display takes a while to show anything (about 10 seconds). with my regular install I don't see anything (even after a few minutes), and blindly typing my luks password doesn't seem to help
<thefloweringash> still doing science: given it fscked when I restored my old kpart, perhaps blindly entering my luks password did help. Is there something userland has to do before the display becomes visible, like turning on the backlight?
<urjaman> guessing from experience with the arch stock kernel on the c201: load a bunch of modules (including for the backlight PWM and the display subsystem etc etc)
<urjaman> one big reason why i started building my own kernels was to get instant display (even if something fails before the system gets to loading modules..)
<alyssa> urjaman: I don't use any modules on the kernels I build since I can never get them to load ;P
<thefloweringash> if I jam the contents of lsmod into my initrd everything works, thanks!
<alyssa> Pff
stikonas has quit [Remote host closed the connection]
anarsoul|2 has quit [Ping timeout: 245 seconds]
tgall_foo has quit [Quit: Textual IRC Client: www.textualapp.com]
<hanetzer> urjaman: yeah. gentoo is good for dat too :P
tgall_foo has joined #panfrost
<alyssa> I'm trying shotgun debugging :p
<alyssa> Not the "try random changes" approach but
<alyssa> "Go through my list of outstanding bugs that need fixing and fix them in the hopes that one of them is our bug"
<alyssa> I.e. actually productive :P
<alyssa> Just fixed a bunch, but nope, not our issue :(
<alyssa> Maybe it's time to implement the alpha test...?
afaerber has joined #panfrost
<alyssa> Does DEPTH_COMPONENT24 just not work? :/
<HdkR> ?
<alyssa> HdkR: Can't get it to work
<HdkR> Trying to use it with the blob?
<HdkR> With glTexImage2D?
<HdkR> Or trying to glReadPixels?
<alyssa> Tex
chewitt has quit [Quit: Zzz..]
<alyssa> HdkR: Reading back all black
<alyssa> And from the panwrap output, of course it is :P
<alyssa> Oh wait lol
<alyssa> Swizzles
<alyssa> I'm Good At This
<alyssa> Wait uh
<alyssa> It's getting swizzled to all one
<alyssa> Is that better? :P
chewitt has joined #panfrost
<alyssa> Ugh whatever
anarsoul has quit [Remote host closed the connection]
<alyssa> Tomorrow's task: alpha test lowering
<alyssa> Code is all there in NIR, just need to do some bookkeeping to get it to work
anarsoul has joined #panfrost
anarsoul has quit [Read error: Connection reset by peer]
belgin has joined #panfrost
belgin has quit [Client Quit]
<chewitt> today's task .. let's see what happens with an LE image for RK3399 (rockpro64)
belgin has joined #panfrost
belgin has quit [Client Quit]
anarsoul has joined #panfrost
BenG83 has quit [Ping timeout: 252 seconds]
<tomeu> raster, Lyude: sorry, completely forgot that I had to enable the gpu node and set a supply :/
<tomeu> I did it in the DT for my board, and I guess we need to send patches to do the same for the other rk3399 boards
<tomeu> ezequielg: ^
<tomeu> alyssa: ezequielg is starting to look at upstreaming AFBC support to rockchip drm, I will tryo to help him from the mesa side of things
<tomeu> Lyude, hanetzer: I'm looking forward to hacking on our kernel driver :)
davidlt has quit [Quit: ZNC - https://znc.in]
<raster> tomeu: hmmm i can decompile the "working" drtb i have for 4.4 and compare
<tomeu> raster: oh, you don't have panfrost working yet with 4.20?
<raster> nope
<tomeu> raster: what was your board again?
<raster> rockpro64
<tomeu> raster: and what output you get in the console when you insmod mali_kbase?
<raster> thats the dt section on the mali
<tomeu> raster: ok, I think we can focus on getting panfrost working on 4.20
<tomeu> being rk3399, it shouldn't be that hard
<tomeu> raster: can you boot with 4.20 and paste the whole decompiled DT?
<raster> hmm
<raster> the 4.4 dts has a lot more
<raster> already booted with 4.20 :)
<raster> hmm
<raster> interesting
<raster> theres separate voltage lines in i2c it seems for the gpu.. but bothe drtb's are the same there
<raster> oh wait
<raster> never mind
<raster> my bad
<tomeu> ok, mine is booting as well
<raster> i was looking at the same file twice
<tomeu> I have a different board, but the same soc
<tomeu> so i think we should have basically all the same
<tomeu> maybe only the supply should be different
<raster> the 4.4 has a nice fat symbols section...
<raster> 4.20 doesnt
<raster> well __symbols__ { ... }
<raster> that one
<tomeu> damn, dtc segfaults here
<raster> hmm thermal is much more filled out on 4.20
<raster> hahaha
<tomeu> raster: can you put the output of dtc somewhere for me to see?
<raster> tyring to decode /proc/device_tree ?
<raster> yeah - it does that for everyone... on x86 too
<raster> try the binary
<raster> dtc -I dtb -O dts /path/to/dtb -o output.dts
<raster> /sys/firmward/... somewhere there is a binary dtb file
<tomeu> thanks, sudo dtc -I dtb -O dts /sys/firmware/fdt did it
<raster> the first is the 4.20 i'm now using
<raster> i need to hunt everything gpu related and compare the 2 i think. the 4.4 has a working mali driver with the closed binary drivers
<raster> so at least the kernel side seems to work
<raster> so i guess i'll take that as my "known good one"
<tomeu> raster: ok, you are missing mali-supply
<tomeu> what changes have you made to your 4.20 tree?
<raster> and as the whole dtree thing is new to me... going to have to learn it. it reminds me a bit of acpi dsdt's
<raster> all i did was change the mali t860 section from disabled to okay
<raster> status = "okay";
<raster> that line i updated
<tomeu> ok, we need to also add a mali-supply property
<raster> the mali kernel module loads, but rockchip dri init fails in userspace
<tomeu> which in your board, from the 4.4 DT, I think should be syr828@41 {
<tomeu> compatible = "silergy,syr828";
<tomeu> I mean, should point to that node
<tomeu> raster: can you check in the 4.4 sources what value has the mali-supply property?
<raster> 0xa0
<tomeu> raster: oh, in the sources
<raster> i'm thinkling i should just copy over the whole block.
<raster> yeah
<raster> thats in the src
<raster> mali-supply = < 0xa0 >;
yann has joined #panfrost
<tomeu> wtf
* raster shrugs
<raster> so said the decompile :)
<tomeu> ok, let me check my 4.20 sources
<tomeu> yeah, the decompile doesn't have info about the mnemonics used in the sources
<raster> methinks i cant just copy the block across
<raster> the values i suspect are referenes to some other section
pH5 has quit [Quit: bye]
<tomeu> raster: ok, you should just need this change to whatever is in 4.20: http://paste.debian.net/1059519/
<raster> everything that has power-domains for example is 0x15 somethingelse on 4.4 but 4.2 has 0x19 something
<tomeu> ping me when you have rebooted with this change and we can look at the userspace problem if it's still not working
<raster> shouldnt i also have a power model and other things?
<raster> or is this going to be the "1 thing at a time so we don't break too much stuff at once" method ? :)
<tomeu> raster: it's more of a "if it works in my rk3399, it should also work on yours" thing :)
<raster> oh
<raster> heheh
davidlt has joined #panfrost
<tomeu> I currently plan to start caring about power management, etc only once we have our own kernel driver
<tomeu> for now I'm focusing on enabling others to join the fun
<raster> well yeah
<raster> compiled.dtb: ERROR (phandle_references): /gpu@ff9a0000: Reference to non-existent node or label "vdd_gpu"
<raster> what is fdd_gpu in your dts there you patched?
<raster> i have something named that
<raster> regulator@41 in i2c@ff3c0000 {}
<raster> regulator-name = "vdd_gpu";
<raster> but that doesnt seem to work
<raster> oooh it got named
<raster> there we go
<raster> i wish the serial console wouldnt output junk ....
<tomeu> the serial in the nanopc-t4 is also very flaky, but I'm not sure if it's the cable or what
<raster> (well it works once you are at a login prompt but the rest of the serial tty output before that is garbage - probably baud rate related)
<tomeu> after replugging a few times, it sometimes work
<raster> works totally reliably... once it gets to the login prompt :)
<raster> (for me)
<tomeu> that's what I will need once we start work on the kernel module :/
<raster> yeah...
<raster> this is what has stoppe dme doing my own kernel build
<raster> i did do one... i re-used the same config...
<raster> it didnt boot - nothing came up and i had no way to see
<raster> i didnt have serial set up at the time... so i set it up and now i see it's junk and that's making me not a very happy camper
<raster> same failure
<raster> failed to load driver: rockchip
<raster> then falls back to hunting to kms_swrast etc.
<raster> dmesg is similar
<tomeu> what, you don't have this line?
<tomeu> [ 50.346796] mali ff9a0000.gpu: Linked as a consumer to regulator.11
<tomeu> raster: ^
<raster> yeah
<tomeu> ah, ok
<raster> 25 for me instead of 11
<raster> thats all thats new
<tomeu> so kernel is fine, let's deal with userspace :)
<tomeu> what are you running there?
<raster> glmark2-es2-drm
<raster> yes - permissions are fine
<raster> /dev/mali0 is there
<raster> so it does get that far...
<raster> but nothing ever even bothers to try open it...
<raster> so not sure thats the problem
<raster> something in the rockchip_dri.so is not succeeding...
<tomeu> raster: yeah, can you paste a strace somewhere?
<raster> cant find any env vars to enable to get more info it seems...
<tomeu> ok, I'm rebuilding glmark to get the drm backend
<raster> it'd be the same regardless of app as this is early in the egl init attempt
<tomeu> raster: I run stuff from the command line like this: MESA_DEBUG=1 LIBGL_DEBUG=verbose LIBGL_ALWAYS_SOFTWARE=false EGL_LOG_LEVEL=debug LIBGL_DRIVERS_PATH=/usr/local/lib/aarch64-linux-gnu/dri/ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
<raster> other thgins all do the same thng for me
<raster> yeah
<raster> i tried those already - no extra info telling me whats up with rockchip_dri.so
<raster> beyond me now adding my own printfs :)
<tomeu> yeah, I had to do that, but nothing that happened to me rings a bell in this case
<raster> yup
<raster> no open of /dev.mali
<raster> err /dev/mali0
<tomeu> failed to bind extensions
<tomeu> that sounds familiar
<raster> what's the first entry point?
<raster> binding extensions is related?
<tomeu> yeah, there should be a symbol in the rockchip dri so that is run to find out extensions
<raster> oh
<tomeu> raster: I'm afraid you will have to add some printfs around when that string is output :/
<tomeu> if you are running the right panfrost branch, you should have that now
<tomeu> it's basically the first thing I had to do in the proper winsys
<raster> yeah ok - that'll have to wait a bit... need to get to work (delaying going in to poke this rock a bit this morning after i woke up)
<tomeu> the only thing I can think of is that it's failing to load the .so because of a missing library, but I don't see that happening in the strace
<raster> well master branch from the panfrost git...
<tomeu> that should be fine
<tomeu> raster: how have you built mesa?
<raster> master
<raster> if i messed something up there.. let me know.
<raster> :)
<tomeu> looks about right
<raster> well printf land it shall have to be
<raster> but the extensions thing will be first
<tomeu> well, it's the same thing
<raster> need to move first. will try a bit later
maciejjo has quit [Quit: Lost terminal]
<raster> ok
<raster> will look at see
<raster> but first....
<raster> pants on.
<raster> :)
pH5 has joined #panfrost
<raster> i'll be back
raster has quit [Read error: Connection reset by peer]
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
afaerber has quit [Quit: Leaving]
maciejjo has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
raster has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
raster has quit [Ping timeout: 258 seconds]
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
afaerber has joined #panfrost
chewitt has quit [Ping timeout: 272 seconds]
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
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
raster has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
gcl has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
gcl has quit [Quit: leaving]
gcl has joined #panfrost
BenG83 has joined #panfrost
<alyssa> tomeu: ezequielg: Alright, awesome :)
<alyssa> tomeu: panfrost_enable_afbc / panfrost_set_fragment_afbc are where the magic happens, so
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
<alyssa> Whaaaa?
<alyssa> The 0xa88 in the framebuffer format code _ought_ to be a 12-bit swizzle (RGB1)
<alyssa> But the enable bits for AFBC and MSAA are right in the middle of that. What gives?!
raster has quit [Remote host closed the connection]
pH5 has quit [Quit: bye]
yann has quit [Ping timeout: 268 seconds]
pH5 has joined #panfrost
stikonas has joined #panfrost
BenG83 has quit [Quit: Leaving]
anarsoul|2 has joined #panfrost
BenG83 has joined #panfrost
pH5 has quit [Quit: Lost terminal]
afaerber has quit [Quit: Leaving]
AntonioND has joined #panfrost
<ezequielg> thefloweringash: fwiw, yeah you need to turn on the backlight on kevin.
<ezequielg> i haven't booted a debian rootfs in a long time on my kevin.
<ezequielg> i could try that i guess.
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
shadeslayer[m] has joined #panfrost
adjtm_ has joined #panfrost
adjtm has quit [Ping timeout: 250 seconds]
ezequielg has quit [Quit: leaving]
AntonioND has quit [Quit: Quit]
<stikonas> is this a known error: src/gallium/targets/dri/src@gallium@targets@dri@@gallium_dri@sha/target.c.o: In function `pipe_panfrost_create_screen':
<stikonas> target.c:(.text+0x2b4): undefined reference to `panfrost_drm_screen_create'
stikonas has quit [Remote host closed the connection]
stikonas has joined #panfrost
stikonas has quit [Remote host closed the connection]
stikonas has joined #panfrost
urjaman has quit [Ping timeout: 272 seconds]
ezequielg has joined #panfrost
<ezequielg> alyssa: hm, so if scanout is linear then there's some compressed-to-linear somewhere?
<ezequielg> i mean, how do you display afbc objects?
<Lyude> scanout isn't nessecarily linear i'd imagine
<Lyude> I know at least on meson there's support in the display hw for scanning out from AFBC directly
<Lyude> ( narmstrong ^ correct me if I'm wrong here)
<ezequielg> doesn't that need special enablement on the DRM driver?
<Lyude> I would imagine so yes
<Lyude> iirc they've already got patches for that for meson
<ezequielg> right, well. I want to do the same thing for rockchip
<ezequielg> I can do the kernel side, and I'm trying to figure out what's needed on the mesa side.
<Lyude> tomeu: ^ any idea on that?
<ezequielg> I can ask tomeu tomorrow as well :] he's probably sleeping now
<Lyude> mm
<ezequielg> I work with him :-)
<Lyude> oh cool!
<Lyude> yall are helping out a ton, thank you <3
<ezequielg> I was just lurking around here (waiting for long builds) and staring at panfrost code
<HdkR> :D
<ezequielg> fwiw, https://panfrost.freedesktop.org/building-panfrost-mesa.html worked out of the box on a ROCK960 board.
<ezequielg> well, pretty much almost out of the box.
<ezequielg> glmark2 and kmscube ran fine
<Lyude> oh heck yeah!
<ezequielg> jellyfish not.
stikonas has quit [Remote host closed the connection]
<alyssa> ezequielg: Good to hear!
<alyssa> As for AFBC: scanout is currently linear. As I mentioned (to maybe it was tomeu?) this morning, the bits are there in the fragment_afbc functions; those would need to be enabled for not only FBOs but also scanout and then mesa side should Just Work
<alyssa> I have some homework to attend to, but I could probably whip up some example code for that
urjaman has joined #panfrost
<ezequielg> you mentioned it to me -- but i'm a sad mesa donkey
<alyssa> Oink
<ezequielg> i will keep staring at code. any example welcome, but don't stop doing your homework.
<ezequielg> at least not because of this ;)
<alyssa> Havne't started homework yet, lemme try something quick
<alyssa> If I'm not staring at differential equations in 20 minutes, then you can yell at me :P
* ezequielg misses school now
<ezequielg> i hope it's the fun dif equation type
<alyssa> There's a fun diff eq type?
<alyssa> :P
<alyssa> "Job invalid" ugh
* alyssa blinsk
<alyssa> What do you _mean_ job invalid?!
stikonas has joined #panfrost
<alyssa> Oh right, forgot AFBC has to be enabled as a core req too
<alyssa> ...Job still invalid?!
<alyssa> Oh, now that might be making progress, how to debug tho
* alyssa sprinkles prints
<alyssa> ezequielg: Hope you have the kernel under control :P
<ezequielg> course
<alyssa> I think I have an example patch which uses AFBC on scanout
<alyssa> Obviously doesn't actually, you know, display anything, tho :P
<ezequielg> shoot - and i'll stare at it