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
<alyssa>
untested but that takes the evil test from 43fps to 74fps
<alyssa>
disabling resource shadowing altogether takes it to 76fps but that's not a good idea in general (it's usually a win, though might need a heuristic to tune)
JulianGro has quit [Remote host closed the connection]
<cphealy>
alyssa: I just re-ran glmark2-es2 with !13502. It significantly improves performance with all three buffer benchmarks:
<cphealy>
The three values are Mali DDK, Mesa latest git, Mesa latest git with !13502
<macc24>
o/ cphealy
<cphealy>
So, with your change, we've undone the regression with the buffer tests.
<macc24>
can you test this on a A35 device?
<cphealy>
Now for the bad news. The overall glmark2-es2 score dropped by ~8% due to other benchmarks getting slower.
<cphealy>
So, this change by itself results in lower overall performance but does show the possibility of being able to increase the buffer test performance significantly.
<alyssa>
cphealy: that is..... bizarre.
<alyssa>
that change should not drop the results of any test
<alyssa>
smells like there's another bug that was being masked
<alyssa>
could you send the full set of scores?
<cphealy>
alyssa: yep, will do in a few.
<alyssa>
thanks
<robclark>
you might want to pin cpu and gpu freq when you compare.. just to make sure what you are measuring is actually mesa perf and not cpufreq/gpufreq
<cphealy>
robclark: Good idea. For all future glmark benchmark runs I'll set CPU and GPU governors to performance.
<robclark>
if there is possibility of thermal throttling (either CPU or if there is a cooling device setup for GPU), pinning at some mid-range freq might be a good idea.. you may just need to play with it a bit to make sure you are getting consistent/sensible #s
<cphealy>
ack
macc24 has quit [Ping timeout: 480 seconds]
macc24 has joined #panfrost
JulianGro has joined #panfrost
* alyssa
looks into IDVS
<alyssa>
...again
macc24_ has joined #panfrost
macc24 has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
<alyssa>
oddly, I'm seeing IDVS hurt perf on e.g. glmark2 -bshading
<alyssa>
from 744fps to 697fps in this experiment
<alyssa>
not a completely controlled one but still. I was expecting the other direction of change. :V
<alyssa>
glmark2 -bshading splits up nicely, so..
<alyssa>
er
<alyssa>
botched test, whoops
<alyssa>
or not?
<alyssa>
745fps, yeah..
<alyssa>
or 708fps, fluctuating wildly.
<alyssa>
pinning gpufreq uh
<alyssa>
nope still fluctuating like crazy. groan
<alyssa>
and consistently slowing down by 10%. what the heck!
<alyssa>
the bigger tests are more predictable
<alyssa>
glmark2 -brefract down 63fps->62fps predictably. mumble.
<alyssa>
Hopefully it's just something silly.
<alyssa>
Okay, -bbuild:model=bunny is the ideal case and that one is indeed helped by IDVS, 192->260. I think
<alyssa>
(or 198->269, something like that. Either way, a win)
<alyssa>
the same test on my rk3399 laptop gets 290fps. ugh
<alyssa>
effect of the job task split field is unclear