buzzmarshall has quit [Remote host closed the connection]
fysa has quit [Ping timeout: 272 seconds]
icecream95 has joined #panfrost
<icecream95>
tomeu, HdkR: It looks like GZDoom actually is fragment-shader bound.
<icecream95>
It renders to a intermediate framebuffer, so changing the window size isn't enough to change the resolution it renders at
<HdkR>
Makes sense
davidlt has joined #panfrost
<mixfix41>
Hey you guys!
vstehle has joined #panfrost
kaspter has quit [Remote host closed the connection]
kaspter has joined #panfrost
guillaume_g has joined #panfrost
guillaume_g has quit [Quit: Konversation terminated!]
guillaume_g has joined #panfrost
guillaume_g has quit [Ping timeout: 272 seconds]
Elpaulo has quit [Read error: Connection reset by peer]
mixfix41 has quit [Remote host closed the connection]
Elpaulo has joined #panfrost
austriancoder has quit [Ping timeout: 248 seconds]
lvrp16 has quit [Ping timeout: 248 seconds]
steev has quit [Ping timeout: 248 seconds]
ric96 has quit [Ping timeout: 248 seconds]
austriancoder has joined #panfrost
lvrp16 has joined #panfrost
ric96 has joined #panfrost
yann has joined #panfrost
steev has joined #panfrost
pH5 has joined #panfrost
<tomeu>
robmur01: robher: any ideas on why using the performance devfreq governor on the kevin causes a bunch of deqp tests to fail, but not on a nanopc-t4?
yann has quit [Ping timeout: 272 seconds]
guillaume_g has joined #panfrost
warpme_ has joined #panfrost
icecream95 has quit [Ping timeout: 240 seconds]
raster has joined #panfrost
raster has quit [Client Quit]
raster has joined #panfrost
megi has joined #panfrost
chewitt has joined #panfrost
nhp[m] has quit [*.net *.split]
nhp[m] has joined #panfrost
pH5 has quit [Ping timeout: 248 seconds]
guillaume_g has quit [Quit: Konversation terminated!]
guillaume_g has joined #panfrost
yann has joined #panfrost
guillaume_g has quit [Quit: Konversation terminated!]
guillaume_g has joined #panfrost
yann has quit [Ping timeout: 265 seconds]
<robmur01>
tomeu: fail reasonably consistently, or die randomly all over the place (i.e suggesting voltage/clock issues)?
<robmur01>
I suppose it's possible that the higher OPPs on "OP1" relative to stock 3399 might lead to subtle timing differences
<tomeu>
robmur01: randomly, I will check the opps in the chromeos downstream
<robmur01>
(I don't believe there are actual GPU differences like on the 3288 variants)
<robmur01>
I guess you could also try just dialling down scaling_max_freq to match and see if that makes any difference
<robmur01>
thermal difference *might* come into it too, although I did struggle to get nanopc hot enough to reach a trip point on GPU alone (running one of the more intensive glmark scenes offscreen for over a minute)
<alyssa>
over a *minute*?
* alyssa
faints
<robmur01>
something like that - bear in mind that's a bare board with an OK heatsink in a not-particularly-warm room. IIRC getting up to ~70 degrees was pretty quick, but then pushing it above 75 took a lot longer
<robmur01>
in hindsight I could have wrapped it in a jumper, given that I was merely trying to test that throttling worked :)
<tomeu>
IME, the kevin has much better thermal dissipation than the SBCs
<alyssa>
tomeu: I've been experimenting with index buffer heuristics
<alyssa>
Trying to guess some worst case estimates for min/max_index to see if we can skip computation, etc.
<alyssa>
Answer unfortunately seems to be "probably not"
<alyssa>
Hardware is picky... and it's hard to get a good estimate in practice.
* alyssa
wondering about doing an index buffer cache
yann has joined #panfrost
<bbrezillon>
alyssa: I don't see where we're freeing nir_shader objects cloned in panfrost_shader_compile()
<alyssa>
bbrezillon: Probably we're not, leaky leaks are leaky.
<alyssa>
The main problem with caching is that the bounds depend on start/count as well as the data itself
<alyssa>
There's probably a clever data structure of course
raster has quit [Quit: Gettin' stinky!]
<alyssa>
Worst case, we can use a 2D hash (with start/count as keys) but that seems questionable
<alyssa>
but I don't see any useful reduction here..
raster has joined #panfrost
<alyssa>
Ohhh, right, okay, that's a cute reduction
<alyssa>
(courtesy of staring at internet)
<alyssa>
Storing the min/max for buckets, and then potentially overlaying different sized buckets.
<alyssa>
Even without explicit caching that should take the cost to compute from O(n) to O(log n)
<alyssa>
at the expense of O(n log n) cost on initialization.... whether that'll become a useful tradeoff is tbd
<alyssa>
But even just a hashtable works pretty dang well.
<alyssa>
Unfortunately, hashtable_search is now a bottleneck... what goes around comes around.
<alyssa>
It might make sense to throw out the hashtable in favour of just an array, depending on the size characteristics.
<alyssa>
(which will also help managing the memory footprint
<alyssa>
)
<alyssa>
"hit with count: 1"
<alyssa>
Okay, yeah, the overhead of a hash table is the problem. Let's try something a lot lower overhead.
<alyssa>
This is better but still more overhead than I'd ideally like..
* alyssa
wondering if there's some clever trick she's missing
<alyssa>
There usually is
<alyssa>
One option of course is to approximate. I'm not convinced that's useful at this point, though.
pH5 has joined #panfrost
<bbrezillon>
alyssa: I'm working on this custom wallpaper logic and I wonder how MS textures are supposed to be reloaded. Looks like texelFetch() is passed a specific sample, but we want to reload all samples, right?