ChanServ changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs https://oftc.irclog.whitequark.org/panfrost - <macc24> i have been here before it was popular
pak0 has joined #panfrost
pak0 has quit []
pak0 has joined #panfrost
pak0 has quit []
pak0st has joined #panfrost
pak0st has quit [Remote host closed the connection]
join_subline has joined #panfrost
cphealy has quit [Ping timeout: 480 seconds]
JulianGro has quit [Remote host closed the connection]
cphealy has joined #panfrost
bbrezillon has joined #panfrost
bbrezill1 has quit [Ping timeout: 480 seconds]
nlhowell is now known as Guest1195
nlhowell has joined #panfrost
Guest1195 has quit [Ping timeout: 480 seconds]
martian_spy has joined #panfrost
pinephoneprovk has quit [Remote host closed the connection]
martian_spy has left #panfrost [#panfrost]
evx256 has joined #panfrost
<evx256>
hello
<evx256>
i'm trying to run vulkan panfrost on a pinephonepro (mali t860), and was wondering if anyone had any experience with this/could help; specifically, i'm on manjaro-arm, which has a mesa 21.3.4 and vulkan_panfrost of same version installable; but if i try to run, e.g., vulkaninfo, i see some loading errors
<evx256>
if i install the git mesa, 22, i appear to get the llvm software rasterizer, lavapipe, if i run, e.g., vkcube: "Selected GPU 0: llvmpipe (LLVM 13.0.0, 128 bits), type: 4"
<evx256>
i'm open to building mesa and trying to use the latest upstream panvk driver to test this out, but i'm not super familiar with meson so if that's an option here, i'd appreciate the relevant meson command to build the relevant libraries, and i can try it out with i assume LD_PRELOAD and LD_LIBRARY_PATH before running e.g, vkcube, or some other test vulkan binaries i have on device
<HdkR>
environment variables aren't the way to go
<HdkR>
libVulkan is a loader which queries some json files for which vulkan driver to use
<evx256>
okie dokie, as i said, i'm open to doing whatever, might need some suggestions on how though :)
<HdkR>
libvulkan's default path should search `/usr/share/vulkan/icd.d/` for a json file that pertains to each "device library"
<evx256>
the main issue, as i see it, is that the mesa-git is using the software rasterizer
<HdkR>
If you don't have a panvk driver json file in that folder then libvulkan will never find a panfrost vulkan library :)
<evx256>
yup, seeing that now: cat /usr/share/vulkan/icd.d/panfrost_icd.aarch64.json
<evx256>
well it does not with mesa-git, it uninstalls it as it conflicts (probably because it's 22, but there's no 22 vulkan_panfrost-git
<evx256>
if i run with the mesa above, as i said, i get some loader errors, i'll paste them now
<HdkR>
That's the problem of trying to bring up non-production drivers :D
<evx256>
as i said, i'm ok to build this stuff from source and put it somewhere; it sounds like i could install the mesa-git, checkout that rev, build the panfrost vulkan, put it in /home/foo/libs and then edit that json to point to it?
<evx256>
here is the error message from mesa 21 with the vulkan_panfrost package installed: https://dpaste.com/2ANFE5SY8
<evx256>
as i said, i'm very happy to test upstream mesa/panfrost vulkan, mess around with it, etc.; very curious to look at what the perf difference could be in an app that runs either gles3.2 or vulkan
jkl has quit [Quit: Gone.]
jkl has joined #panfrost
<HdkR>
Looks like it's just a loader version mismatch
<HdkR>
This changed only two weeks ago to support version 5
<evx256>
nice find! so i can either downgrade the loader, or cherry-pick that patch and rebuild the vulkan panfrost driver against 21.3.4 mesa?
JulianGro has joined #panfrost
<HdkR>
Or if you're already rebuilding a version of mesa, just use the tip of main
<HdkR>
Not like a stable version of mesa is going to provide stable panvk today.
<evx256>
cool, i'm building it now with: `meson -Dvulkan-drivers=panfrost -Dllvm=disabled ..`; hopefully it doesn't fail; once it's done i just update my icd json to point to the artifacts in mesa/build/bin right?
<HdkR>
That would probably work
<evx256>
and just to be clear, since i don't do this very often, i don't need to do install other mesa tip of main artifacts/libraries, right? just point the icd loader json at this newly built `libvulkan_panfrost.so` and then cross fingers and try out with vkcube, etc.?
<evx256>
oof, build just failed... i've noticed tip of mesa main also fails on my x86, does mesa not have CI?
<evx256>
like how does this even get into the source tree? this isnt' a warning, but an actual error: "src/compiler/glsl/glsl_parser.h:185:3: error: conflicting declaration ‘typedef union YYSTYPE YYSTYPE’\n 185 | } YYSTYPE;"
<evx256>
<HdkR>
mesa does run CI on every single merge
<HdkR>
On multiple architectures of course :P
<evx256>
ok, so i just grepped ninja for the libvulkan_panfrost target, built that explicitly, was able to build; i changed the /usr/share/vulkan/icd.d/panfrost_icd.aarch64.json to point to /home/manjaro/git/mesa/build/src/panfrost/vulkan/libvulkan_panfrost.so, i ran the vkcube and i get no error message but it looks like display has frozen :]
<HdkR>
Sounds like panvk is working as expected then :)
<HdkR>
vulkaninfo might actually give some information
<evx256>
yea so i actually ran vulkaninfo, and i believe that's what first froze the display
<evx256>
i'm restarting, will try again, maybe it needed a warmup >:|
<HdkR>
Yes, a warmup to stall the display once more
<evx256>
just to make sure though, this is all i should need to do? i don't know mesa that well, i want to be sure it's not calling into some other mesa library which is not longer binary compatible?
<HdkR>
You could ldd the resulting library ot make sure
<evx256>
that won't tell if you it's binary incompatible though; i mean i'm worried/wondering if e.g., libvulkan_panfrost makes some function call foo() in libsome_mesa_lib.so, and passes arg Bar, but the previous versioned expected a Foo
<evx256>
so after reboot, vulkaninfo is still returning the llvm software rasterizer...
<HdkR>
that's what I mean, you could ldd the library to see what other libraries it is linked to. If it isn't linked to anything other than regular system libraries then it is fine
<evx256>
ahhh, right, of course, good point
<evx256>
so i now reinstalled the mesa, manually added the icd loader file, it appears to be recognized, and the loader interface mismatch error disappears, but it outputs this now: https://dpaste.com/5F8SXY4UW which is the same as the last, modulo the loader interface error missing... :( so it seems like the loader mismatch was benign?
<evx256>
well this seems like the end of my journey for now; not sure how to debug the last two, seems like the driver probably just needs more work? :/
<HdkR>
Yes, it's not production ready at all
<HdkR>
Just because it is in upstream doesn't mean it should be used :)
<evx256>
i wasn't expecting it to be "production ready", but i mean, i did expect to be able to load a triangle, or it's not even that ready? otherwise how are people even testing the driver for functionality; i'm assuming it's not just random bits of C code checked in that compiles
<evx256>
so someone asked me if need a kernel module enabled, would you happen to know if this might be true in my case (running on pinephone pro with manjaro-arm)
<HdkR>
You'll definitely need the panfrost kernel module. Dunno what the minimum version requirements of it is
frytaped has joined #panfrost
<evx256>
what does that mean exactly? i'm not seeing panfrost anywhere when grepping lsmod
<HdkR>
The panfrost kernel module is what is used to communicate with the GPU. It fulfills the same role as the kbase kernel module.
<HdkR>
kbase being the proprietary Mali kernel driver that most board sship
<evx256>
hmm, as i said, don't see this in `lsmod`; i'd have expected installing the pacman vulkan-panfrost package would install a required kernel module; do you have any suggestions how to investigate this more?
<HdkR>
You'd need to check the kernel config and maybe the logs for any reference to panfrost
<HdkR>
That looks like a real compiler limitation at this point
<evx256>
yea i'm reconfiguring in release (i assume asserts are compiled out in release) because yolo
<alyssa>
that sounds like a bad iea
<evx256>
to turn off asserts in release, yea, but you'll have to yell at the C ISO committee
<alyssa>
shrug
<alyssa>
you said you wanted a broken vulkan driver, now you have a broken vulkan driver :]
<evx256>
oh but you probably mean maybe nuking my device :P
<evx256>
i'm going on an adventure, that's all
<macc24>
now i need to write a userspace driver that would irrepairably break a device
<evx256>
alyssa: since you seem to be one of the devs on the panfrost stuff, is there anything i can help with re testing/etc.; i'm more than happy to mess around with broken/non so broken drivers, try out patches, etc.
<robmur01>
nah, loading/storing the wrong amount of data usually ends in smiles and kittens, I'm pretty sure :P
<evx256>
probably more like weird looking triangles
<alyssa>
probably more like random GPU faults and black screens
<evx256>
oh ok, so just like the gl driver running on the phone today :)
<evx256>
in any event, vulkaninfo now tells me i have a t860 vulkan device
<evx256>
do i dare run vkcube?
<HdkR>
Dare to be bold.
cphealy has quit [Ping timeout: 480 seconds]
<macc24>
evx256: what device are you running panvk on?
<evx256>
pinephonepro, which has the mali t860
<evx256>
so vkcube reports, with sadness, that the VK_KHR_xcb_surface extension is missing :(
<evx256>
> Dare to be bold. > "adventavit asinus, pulcher et fortissimus!"