<cphealy>
danboid: Cool, thanks! As we discussed, you had to change the devfreq governor for the GPU from ondemand to performance as with ondemand it would stay locked at the minimum frequency.
<macc24>
cphealy: for me it worked
<cphealy>
macc24: Do you mean on the S905X3?
<macc24>
ChanServ: on rk3326, rk3288, rk3399 and on mt8183(somewhat) it worked for me
<cphealy>
ack This was with S905X3 with 5.11 kernel so possibly some diff there.
<cphealy>
Good to hear devfreq is working correctly on these other platforms though.
<narmstrong>
I wrote the ge2d for amlogic based of rga and g2d, no way these can pass v4l2 compliance... anyway I totally managed to use it to rotate a buffer in conjunction with DRM with dma-buf because amlogic doesn’t have an IOMMU for display, this is the main issue with RGA
warpme_ has quit [Quit: Connection closed for inactivity]
tlwoerner has quit [Ping timeout: 240 seconds]
tlwoerner has joined #panfrost
WoC has quit [Remote host closed the connection]
WoC has joined #panfrost
* alyssa
is testing code before landing it
<alyssa>
This is new :'o
warpme_ has joined #panfrost
davidlt has quit [Ping timeout: 252 seconds]
raster has quit [Quit: Gettin' stinky!]
<macc24>
does devfreq frequency scaling work on malis on exynoses?
<alyssa>
..exynos?
<macc24>
exynos
<alyssa>
.......exynos?
<macc24>
yes
<alyssa>
por que
<macc24>
can i just plug some frequencies into /sys/class/devfreq/whatever/max_freq and min_freq and expect it to work perfectly fine excluding mali t628 weirdness?
<alyssa>
shruggie
<alyssa>
thanks for volunteering to debug devfreq on snow
<alyssa>
;)
<macc24>
i promise that i didn't get an exynos device
stikonas has quit [Remote host closed the connection]
stikonas has joined #panfrost
raster has joined #panfrost
ckeepax has quit [*.net *.split]
ckeepax has joined #panfrost
<robmur01>
macc24: there are OPP tables defined in the SoC DTs, so I see no reason why it shouldn't work
<icecream95>
Also... C99 gives the return value (as always) as the number of characters that would have been written in case the output string has been large enough
<urjaman>
yeah and IIRC it is characters not counting the terminating nul (both size and the return value)
* urjaman
skimmed through some snprintf code today...
robmur01 has quit [Read error: Connection reset by peer]
robmur01 has joined #panfrost
<icecream95>
alyssa: Note my "overhead" branch has a bunch of commits which speed up BO cache lookup, but maybe they don't matter so much after "Fix major flaw in BO cache"
<alyssa>
nod
<alyssa>
I'm mad about that one
<anarsoul|2>
what's "major flaw"?
<anarsoul|2>
or rather what major flaw?
<alyssa>
anarsoul|2: !10794 dumb typo adding huge amounts of overhead
<alyssa>
lima handles this correctly
<anarsoul|2>
I see, thanks
tlwoerner has joined #panfrost
<alyssa>
Aside -- did GALLIUM_HUD break recently?
<anarsoul|2>
nice catch :)
<alyssa>
anarsoul|2: I should've caught it a year ago.
<robmur01>
aww man, I spend a couple of days not looking at gitlab and you go sneaking in commits in about the one area I can usefully review :P
<alyssa>
robmur01: hmm?
<alyssa>
which commits would those be?
<robmur01>
the "G52 R1p0 looks different from G52 r0px" shenanigans
<alyssa>
robmur01: If you have post-merge comments uh lmk? :P
<alyssa>
oh
<alyssa>
I see.
<alyssa>
robmur01: So, does the IP revision matter for anything in software (user or kernel)..?
<robmur01>
nothing specific that I'm aware of - I don't know what significance the minor arch version bump has
<alyssa>
alright
* alyssa
bisects GALLIUM_HUD
<alyssa>
Bisecting: 2427 revisions left to test after this (roughly 11 steps)
<alyssa>
....sigh.
<alyssa>
Me, at the beginning of the week: "let's get oustanding MRs to zero"
<alyssa>
Me when 3 MRs are opened today
<alyssa>
f
<robmur01>
let's hope they're merely average MRs, then it's cool right? :P
<HdkR>
I personally enjoy when I'm working on a feature, but it requires fixing seventeen other things. Then those can't be PR'd until all the work is done so you get a wackload of PRs dropped in one day :)
<HdkR>
and then my CI cries when I open 13 PRs in an hour
<alyssa>
enjoy?!
<alyssa>
icecream95: Anything !10197 is pending on besides Midgard testing?
<alyssa>
I can test and land if you're happy with it.
<HdkR>
It's a therapeutic wind down doing the break-up of changes at the end
raster has quit [Quit: Gettin' stinky!]
warpme_ has quit [Quit: Connection closed for inactivity]
<alyssa>
bbrezillon: I notice v3d doesn't have *any* implicit dep tracking for BO access
<alyssa>
and instead manually inserts all the flush reader, flush writer calls
<alyssa>
I don't know if that's better or not.
<alyssa>
Although surely, explicit BO access flags for anything marked PRIVATE is just noise.
<alyssa>
I guess adding unneeded BOs to the { vertex, fragment } job adds a bit of overhead in kernel space, but I suspect it'd be neglible..
<alyssa>
and as it is most of the users require both
<alyssa>
Bisect blames packed uniforms. Again.
<alyssa>
Reverting fixes the HUD. Let's dig into this one. Sigh.
stikonas has quit [Remote host closed the connection]
raster has joined #panfrost
camus has joined #panfrost
kaspter has quit [Ping timeout: 268 seconds]
camus is now known as kaspter
<alyssa>
also, debating s/ / /g'ing panfrost to match mesa
<alyssa>
Wanted to test perf of my series on top of bbrezillon's, but then I found bbrezillon's had a perf regression, but then I found the fix to that is actually a longstanding regression, but while trying to benchmark that I noticed GALLIUM_HUD=fps wasn't working, so then I found there's a backend bug breaking nir_to_tgsi that I had to go fix... sigh
<alyssa>
Did I ever get back to my series in the first place? Of course not
<cphealy>
Regarding GALLIUM_HUD breakage, is this something CI could catch?
<alyssa>
In theory? I'm not entirely sure how that would work.
<alyssa>
With all the fixes, piglit drawoverhead is much less angry at me