<agrisis>
agreed, it will be intersting to try out nonetheless
<HdkR>
That's not even the worst I've seen out of the blob
<agrisis>
s/intersting/interesting/ (sorry can't type today)
<agrisis>
are you aware of any kernel or dts or system level tweaks to help the GPU along?
<agrisis>
so far, I just set the governor to 'performance' and ensure it's clocked at the max
<HdkR>
The Mali blob the best thing you can do is just set the GPU clocks to the max
<HdkR>
Since it usually stalls waiting for GPU work to complete
<agrisis>
and regarding panfrost, I reckon using kms/drm (gbm?) should be faster than using retroarch or some emu in wayland?
<HdkR>
I don't believe it has significant performance differences
italov has quit [Ping timeout: 246 seconds]
<HdkR>
Mali blob had massive performance differences between X11, fbdev, and wayland APIs because of problems in their driver more than anything else
camus has joined #panfrost
<agrisis>
we're still stuck on r6, I updated to a later one I think r16 but performance didn't seem to have changed
icecream95 has joined #panfrost
<HdkR>
Can't say that panfrost will be faster atm, but at least you'll be able to see where the CPU time goes
kaspter has quit [Ping timeout: 240 seconds]
camus is now known as kaspter
<agrisis>
at least with void's rolling updates we'll auto-get future improvements
<agrisis>
sorry I don't know anything about graphics programming except for 2D stuff, otherwise I'd love to help
camus has joined #panfrost
kaspter has quit [Ping timeout: 246 seconds]
camus is now known as kaspter
<chewitt>
agrisis, which distro/app platform are you working on?
<agrisis>
chewitt: void linux on odroid go advance
urjaman has quit [Ping timeout: 240 seconds]
<chewitt>
ahh, okay
<chewitt>
I'm hoping there's an uptick in structured emulator testing to shake out the bugs or create repeatable test cases
davidlt has joined #panfrost
<agrisis>
I'm happy to test it out, I maintain one of the main OS distributions for the odroid go advance. I'm also the main contributor to retroarch for this platform.
<agrisis>
thankfully I don't play any 3D games so my personal OGA I don't even install the mali blobs but there is a lot of interest in getting ppsspp, dreamcast performance reigned in on this platform as it looks like we may be stuck on the rk3266 for a while
<chewitt>
I'm encouraging the Lakka folks to rebase against the newer LibreELEC codebase
<chewitt>
(which I work on)
<agrisis>
also the duckstation developer Stenzek has tried to make his psx emu faster on the OGA but complains that in his measurements too much time is spent in the mali library
<agrisis>
also the void ports tree is quite amenable to cross compilation
<agrisis>
haha I love that one
<agrisis>
yeah it's unfortunate that the oga ecosystem is also quite fragmented with over 5-7 different images most of them overlapping to a great extent
urjaman has joined #panfrost
<agrisis>
now we have to contend with clones and so these initial images are being forked further
<agrisis>
my goal is to move from kernel 4.4.x to 5.10+ w/ panfrost
<HdkR>
If you have a 5.10+ kernel image to flash to my GoA then I'd be happy :P
<icecream95>
agrisis: Can confirm that runit is way faster than systemd, especially once I ripped out the stuff I didn't need from /etc/runit
<agrisis>
icecream95: runit is light years faster and easier to manage than systemd I feel on this platform (not a systemd hater as I run it on my desktop)
<agrisis>
HdkR: I'll have to rebase and probably do some more fixups. From my notes, suspend was broken, sound control was broken but sound worked, and I didn't have a working wifi driver
<icecream95>
So they replaced Natt with Odin? Hopefully that's an upgrade, not a downgrade…
<chewitt>
I've been told that it's a bifrost design to reduce time-to-market (avoiding software bring-up delays) but the source is not anyone official so that's firmly in the "unfounded rumour" category
<icecream95>
chewitt: In kbase, tODx doesn't have IDVS_GROUP_SIZE, which the other Valhall GPUs (including tNAx) do have, so it seems possibile it's bifrost
icecream95 has quit [Ping timeout: 240 seconds]
raster has joined #panfrost
_whitelogger has joined #panfrost
davidlt has quit [Ping timeout: 240 seconds]
stikonas has joined #panfrost
rando25892 has joined #panfrost
randohplistenrs has quit [Read error: Connection reset by peer]
* macc24
spotted a regression(?), https://bpa.st/Y3KQ it has happened between 2 days ago and today, no idea what can be the cause. i git pulled mesa, compiled it and installed it, there was no change in kernel
<macc24>
i opened sway and 2 terminal windows
<macc24>
it happens when opengl happens
<macc24>
there are also display issues, ranging from flickering part of window, extra-low framerate and freezes
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #panfrost
<robmur01>
chewitt: All Bifrost GPUs have been released and have actual product names... go figure ;)
<chewitt>
it's on my "something to worry about if/when it actually ships" list :)
<bbrezillon>
macc24: mind bisecting the issue?
<macc24>
bbrezillon: i will try
<macc24>
kmscube works fine hmm
davidlt has joined #panfrost
clementp[m] has quit [Quit: Bridge terminating on SIGTERM]
wiizzard has quit [Quit: Bridge terminating on SIGTERM]
exit70[m] has quit [Quit: Bridge terminating on SIGTERM]
l-as has quit [Quit: Bridge terminating on SIGTERM]
<alyssa>
chewitt: icecream95: Odin is Valhall, to my knowledge.
<alyssa>
(Based on kbase.)
<alyssa>
tODx listed as GPU model 10.2
<alyssa>
As far as I know, Bifrost only covers v6 and v7, and then v8 was Valhall but I don't see any evidence in kbase of v8 actually existing, so v9 is the first valhall
<alyssa>
Note G77 was v9
<macc24>
v-what?
<alyssa>
You know. Valhalla. For when the soul moves on.
<HdkR>
alyssa: Was it Natt that was Valhall as well?
<alyssa>
HdkR: Yes, I believe so.
<macc24>
alyssa: v6, b7, v9?
<macc24>
v7*
<robmur01>
HdkR: product-formerly-known-as-Natt has been shipping in silicon for a while ;)
<HdkR>
robmur01: I definitely have Valhall in my hands yes :P
<robmur01>
Huh? No, there was a bunch of rework in the panfrost driver itself to connect the supply regulator(s) to the OPP table and make voltage scaling actually work again
<robher>
br: Those are copied from the Arm vendor driver, so we'd need to check within Arm. raster, something you could look into?
karolherbst has quit [Remote host closed the connection]
<alyssa>
br: neat :)
<raster>
robher: gah dang. yeah. gpl ...
<raster>
let me chase up what we can do about releasing these under a bsd license as well
<raster>
br: i think i'll need a list of what you need as this is going to have to go through a legal approval cycle - i know where to start with that but i know i'll need to know the exact list of files so they go through IP review for a license change.
<br>
panfrost_drm.h is already MIT which I think is fine
<raster>
:)
<raster>
i don't see any actual core issues with these being released BSD or MIT - they are really just a bunch of "bit x is this thing"
<br>
panfrost_regs.h would be good to re-license too, but not too critical since I can simply use mali_midg_regmap.h in replace of it (it is Apache)
<raster>
(with a name)
<br>
robher: so these three: panfrost_features.h, panfrost_issues.h, panfrost_regs.h
<alyssa>
br: Isn't the whole driver GPL? I'm confused.
<alyssa>
Or is it ok if the headers are MIT but the code itself is GPL? I don't know how things work in BSD land.
<raster>
br: well alyssa makes a good point. you will be basing your driver on the panfrost kernel driver code
<raster>
that could be considered a derivative work...
<raster>
(ie you read it and write code that is substantially similar and based on it)
<raster>
i am not a lawyer... but this is getting into a grey zone
<br>
alyssa: well we can't use the driver anyway even you re-license it under BSD, because drivers API and the interfaces to OS subsystems are all different, so we have to write a new driver
<br>
Also we don't have any bits for LPAE page tables management, so I will have to write them for freebsd/arm64 first (not a part of panfrost driver)
<alyssa>
br: Oh, I was under the impression BSD had some frankenstein mechanism for importing some types of Linux kernel drivers, assumed DRM was covered.
<robher>
We'd want the headers dual licensed GPL and BSD or MIT.
<alyssa>
(Maybe that was networking? Who knows.)
<alyssa>
("Who?" "Probably br knows.")
<br>
I heard such thing exists for network drivers, but I never saw anyone actually using it
<alyssa>
Ah.
<alyssa>
br: Anyways, if you're rewriting anyway, I don't think any of what you care about from those files is copyrightable.
<alyssa>
It's just data.
<alyssa>
And not the creative kind. Literally just a listing of bugs in chips. (Most of features.h isn't even used in either driver.)
<raster>
alyssa: indeed
<macc24>
br: isn't linuxkpi still a thing?
<raster>
but...
<raster>
we are talking lawyers here
<raster>
:)
<alyssa>
raster: Yes. But if br is writing a greenfield panfrost driver, and they happen to write their own issues.h file from scratch that happens to be functionally identical to ours, well, it's their copyright, they own it, right? ;)
<raster>
alyssa: they can and in fact that is exactly what i would do. i wouldnt want to use the same files
<br>
Yeah I don't want to re-implement features.h, it will be the same file (but without comments)
<raster>
i'd probably want to structure them around how i write my driver and my namespacing
<raster>
those originals tell me that "gpu variant g31 has warping"
karolherbst has joined #panfrost
<raster>
but the question stands... if you have a tinfoil legal hat - even looking at the panfrost gpl src taints your src as a possible derivative work.
<raster>
i personally do not have such a tinfoil hat. the panfrost src is a reference on facts - how does this hw function. if you copy the algorithms and solutions to that .. then you may have issues, but if you just use it as a source of facts... you are ok.
<raster>
but again - i am not a lawyer.
kherbst has joined #panfrost
<br>
it should be fine
karolherbst has quit [Ping timeout: 272 seconds]
<raster>
i'll look at the licensing of these files for you