<alyssa>
I finished basic RA support... theoretically it should handle mixed types and such but that's untested atm
<alyssa>
Anyway, since we have a dummy scheduler, next step will be actual code emit/packing/etc
<alyssa>
which I've heard is "intense" ;)
<alyssa>
Lyude: Reading through the assembler is enlightening. This will be quite useful :-)
indy has joined #panfrost
buzzmarshall has joined #panfrost
* alyssa
staring
<alyssa>
this isn't ~~kansas~~ midgard
TheKit has quit [Remote host closed the connection]
rhyskidd has joined #panfrost
TheKit has joined #panfrost
nerdboy has joined #panfrost
davidlt has joined #panfrost
davidlt has quit [Ping timeout: 258 seconds]
rhyskidd has quit [Ping timeout: 240 seconds]
rhyskidd has joined #panfrost
guillaume_g has quit [Quit: Konversation terminated!]
yann has quit [Ping timeout: 255 seconds]
chewitt has joined #panfrost
pH5 has quit [Quit: bye]
pH5 has joined #panfrost
sravn has quit [Quit: WeeChat 2.6]
marcodiego has joined #panfrost
<tlwoerner>
nhp: use openembedded, we cross compile images for tinker and rock-pi-4 daily (with mesa,panfrost,etc)
<nhp>
Huh, interesting
<nhp>
I was trying to cross-compile it with makepkg to create packages for my pinebook pro, but I guess if there are binaries I can just make a package that contains those
<tlwoerner>
i'd be more than happy to help you set up a build (or anyone else)
<tlwoerner>
my "big" images include mpv and chromium (accelerated)
<tlwoerner>
those take about 2 hours
<tlwoerner>
hmm, we don't target the pinebook yet, but could look into adding it. anything with upstream support is quite easy to add. the vendor stuff gets ugly
<HdkR>
please tell me it is Chromium that takes the majority of those two hours rather than mpv :P
<tlwoerner>
HdkR: yes, absolutely
* tlwoerner
is actually surprised mpv doesn't take long to compile at all
<tlwoerner>
i think mpv is just a minute or two
<robmur01>
FWIW building mesa natively on RK3399 is perfectly bearable, around 5-10 minutes at a guess
<robmur01>
(quick enough that I don't get entirely sidetracked while waiting for it to finish, at any rate...)
<tlwoerner>
with a small (usually oneline) change in a config file we can switch the target, or switch from sysvinit to systemd, or from xorg to wayland...
<tlwoerner>
so it lets us build images however
<anarsoul|2>
robmur01: building it on 2 rk3399 (with distcc) is even better :)
<tlwoerner>
making code changes/patches is easy, applying patches or switching source code trees is easy ("hey, can you try a build with my branch?", "try adding these patches...")
<anarsoul|2>
a64 + rk3399 is also OK
<tlwoerner>
you can generate an SDK based on your image contents (i.e. the libraries and header files) including cross-gdbs with an on-target gdb stub
<anarsoul|2>
tlwoerner: OE is OKish for distro-makers, but it's just terrible for developers
<tlwoerner>
anarsoul|2: sorry, i'd have to politely disagree :-)
<tlwoerner>
you can generate a cross-SDK based on your image contents which includes a cross-debugger, so no hunting around trying to get your cross compile to find the "right" headers
<robmur01>
anarsoul|2: heh, in fact I also build natively on RK3328 for lima, since waiting a bit longer is less bother than messing around with makepkg and scp :)
<tlwoerner>
all the "-nostdinc" switches are already setup; no host contamination
<anarsoul|2>
robmur01: distcc!
<anarsoul|2>
you've got rk3399, use it :)
<anarsoul|2>
tlwoerner: OK how long does it take for you to test a change?
<tlwoerner>
anarsoul|2: you update the SRC_URI to either point to a new source tree, or add the patches (one line at a time) and start a new build
<anarsoul|2>
and then?
<anarsoul|2>
how do you get new binaries to the target?
<alyssa>
robmur01: I straight up do all my dev on RK3399 since dogfooding
<tlwoerner>
then you use "devtool deploy-target" and it updates the binaries on your target
<alyssa>
admittedly I'd prefer to keep doing dev on RK3399 for bifrost so I guess I'll get into scp stuff for that :2
<tlwoerner>
(and "devtool deploy-target" is smart enough to remote the old ones first, it does it all as packages)
<anarsoul|2>
tlwoerner: now compare it to hack-hack-hack, ninja -C build install, deqp-gles2 (or whatever else you're debugging)
<tlwoerner>
s/remote/remove
<tlwoerner>
anarsoul|2: right, until you meet a device where you can't build on-target
<tlwoerner>
can you build chromium on any SBC?
<tlwoerner>
you certainly can't on any 32-bit ones
<anarsoul|2>
I don't need to
<tlwoerner>
then you're lucky
<tlwoerner>
and tomorrow when a new board comes out...
<tlwoerner>
or you need to switch to testing PowerVR on some i.MX-based board...
<alyssa>
Lyude: this is intense
<anarsoul|2>
tlwoerner: no, thanks :)
<tlwoerner>
lol
<anarsoul|2>
what? I'm doing it as a hobby, I can choose what I'm working on
<alyssa>
anarsoul|2: is right
<tlwoerner>
some companies purposefully want to know that their product will work on multiple boards, specifically with multiple architectures, and be accelerated on all of them :-(
<alyssa>
tlwoerner: please direct all angst at me and spare anarsoul|2 the pain ;)
<anarsoul|2>
tlwoerner: let's hope that we'll see opensource powervr driver some day :)
<anarsoul|2>
tlwoerner: out of curiosity, why do you need chromium on sbc?
<tlwoerner>
anarsoul|2: kiosk-like things
<tlwoerner>
it's really hard to find young people who know C, everyone wants to write apps in node.js
<anarsoul|2>
yeah, and that's sad
<tlwoerner>
it's a lot easier (unfortuantely) for a company to get developers to write "web apps"
<anarsoul|2>
however
<anarsoul|2>
I'm not that old
<anarsoul|2>
yet
<anarsoul|2>
:)
<tlwoerner>
so we have to run web apps on embedded devices
<tlwoerner>
:-)
<tlwoerner>
alyssa: no angst, just trying to help
stikonas has joined #panfrost
<anarsoul|2>
tlwoerner: does it work OK though? linux is still not first class citizen in browser world
<tlwoerner>
most companies i know of want to use linux (because it's "free") lol
<HdkR>
Hard to find a $35 device that runs Windows :P
<tlwoerner>
it works well enough
<anarsoul|2>
yeah, but neither firefox nor chromium support accelerated video decoding on linux
<anarsoul|2>
well, firefox got it recently
<tlwoerner>
chromium claims it is accelerated under panfrost (it uses some bridge lirbary...)
<anarsoul|2>
tlwoerner: rendering - yes
<anarsoul|2>
but not video decoding
<HdkR>
Accelerated rendering, video decoding no. You need to apply a patch manually for video decode
<anarsoul|2>
HdkR: you also need working driver for video decoding
<tlwoerner>
HdkR: ooh... location of said patch?
Elpaulo has quit [Remote host closed the connection]
<anarsoul|2>
tlwoerner: patch alone is not enough, you need working libva
<HdkR>
That too, patch just lets you use va-api :P
Elpaulo has joined #panfrost
<anarsoul|2>
I couldn't get cedrus working on my board with libva-v4l2-request
<HdkR>
Ah, looks like arch ships the patch with their version of chromium, nice
<anarsoul|2>
haven't tried it with hantro but I expect it to be the same