<HdkR>
I'll be using it for reference tomorrow as I continue on the journey of extracting shader binaries
kaspter has quit [Ping timeout: 265 seconds]
kaspter has joined #panfrost
l-as has quit [Quit: Idle for 30+ days]
stikonas has joined #panfrost
robmur01_ is now known as robmur01
karolherbst has joined #panfrost
kaspter has quit [Ping timeout: 256 seconds]
kaspter has joined #panfrost
<austriancoder>
alyssa: do you have cases where there is one render-only gpu and multiple kms devices?
icecream95 has quit [Ping timeout: 264 seconds]
<robmur01>
there are certainly SoCs with a Mali GPU and multiple display controllers, yes
<robmur01>
I have two in front of me right now :) (RK3288 and RK3399)
<urjaman>
huh?
<urjaman>
as in, how? (i guess RK3399 could get one plugged in with PCIe, but RK3288?)
<urjaman>
(and yeah they've got multiple _outputs_, but they're both on the same Rockchip KMS device...)
<robmur01>
Oh, maybe I've misunderstood what "KMS device" means then
<robmur01>
if it's multiple *different* display controllers, rather than just multiple instances of one type, then certainly some of our Juno FPGA setups look like that, but they don't really count
<urjaman>
yeah i was thinking like ... two controllers driven by different drivers and thus appearing as two different cards (vs. the two on the RK3288 are one DRI card)
<urjaman>
and now that i'm thinking about it, i don't think any PCIe cards would count either (unless it's some weird FPGA framebuffer proto device :P) since they're capable of rendering themselves too
<robmur01>
Hmm, IIRC the two HDLCDs on Juno do show up as separate cards - I was assuming that the Rockchip VOPs behaved the same way (I don't have the means to actually use a secondary display on either of my boards)
<daniels>
well, one KMS device can have multiple { planes, CRTCs, connectors }, so you can use a single /dev/dri/cardN to drive multiple heads, as on Rockchip
<daniels>
what Christian's talking about is having multiple totally distinct IP blocks
<daniels>
(NXP got very weird in some of the i.MX8 and have two totally distinct display controllers on the same SoC - by analogy, think of an SoC which has a Komeda for HDMI and HDLCD for internal panel, and both can be used simultaneously)
<robmur01>
OK, so I guess it's mostly an issue of semantics as to whether a driver considers multiple hardware blocks to be independent devices or just CRTCs for one overall logical "device"
<robmur01>
In which case I think Juno's HDLCDs fall into the former category even without extra tacked-on Mali-DPs in FPGA
<urjaman>
well the two CRTCs and outputs of the rockchip DRM device act similarly to eg. a PCIe graphics card with two CRTCs and connectors (except for the rendering) as in they can be used as one system by one driver
<robmur01>
yeah, I guess Rockchip couldn't do its intended trick of switching a single display between the "big" and "little" VOPs based on resolution if they were exposed as separate devices
<robmur01>
I'm too accustomed to looking at things from the hardware level :)
<alyssa>
HdkR: spill ;p
rak-zero has joined #panfrost
nlhowell has joined #panfrost
camus1 has joined #panfrost
kaspter has quit [Ping timeout: 256 seconds]
camus1 is now known as kaspter
nlhowell has quit [Ping timeout: 256 seconds]
camus1 has joined #panfrost
kaspter has quit [Ping timeout: 258 seconds]
camus1 is now known as kaspter
buzzmarshall has joined #panfrost
camus1 has joined #panfrost
kaspter has quit [Ping timeout: 258 seconds]
camus1 is now known as kaspter
kaspter has quit [Ping timeout: 258 seconds]
kaspter has joined #panfrost
<HdkR>
alyssa: 100% spilling?
raster has quit [Remote host closed the connection]
raster has joined #panfrost
raster has quit [Remote host closed the connection]
<HdkR>
I'll just go lie down on the floor for a few hours to feel better about life
<alyssa>
rip
<alyssa>
sorry :)(
<alyssa>
er that should be a :(
<daniels>
i suspect that cross-file is wrong in a few ways
<HdkR>
It was definitely just slammed together because meson and mesa both don't provide an Android cross-file template
<daniels>
I'd probably poke robclark for that, he's the last one I know of who was doing Android cross-compiles
<Lyude>
HdkR: I might have old meson cross files for android stuff laying around somewhere
<HdkR>
ic
<Lyude>
HdkR: here's the gcc one I had for android, should be able to make it use clang as well if you need that. also though these are old and may not work entirely, there might also be some tricks I used I forgot to mention
<robclark>
krh is probably the one who knows a bit about meson+android (or meson+xcompile in general)
<macc24>
have there been any fixes to chromium after 20.1.6?
kaspter has quit [Ping timeout: 265 seconds]
<HdkR>
Didn't the Android NDK drop gcc?
kaspter has joined #panfrost
<Lyude>
HdkR: I said it's old :P
<HdkR>
true
nlhowell has joined #panfrost
<krh>
you can't compile mesa against the NDK, you need to have the full android source tree
<alyssa>
maybe having pandecode depend on mesa was premature..
<HdkR>
Oh
<HdkR>
So I'll just yeet this code
<krh>
there's stuff like cutils and whatnot that we need to build in
<alyssa>
krh: fwiw the goal here isn't to build mesa for android, just need enough to build the panfrost genxml decoders etv
<krh>
it's something that we could conceivably pull into mesa so that we could build a working native android driver
<alyssa>
that used to depend on NIR, I fixed that :p
<krh>
oh
<krh>
that should be easier
<alyssa>
on linux, I just say "build mesa normal and then we'll snarf out what we need from your build dir", of course
<alyssa>
HdkR: let me tease this apart so you can throw away the mesa dep actually