nroberts changed the topic of #videocore to: Raspberry Pi Mesa drivers discussion - Logs http://freenode.irclog.whitequark.org/videocore
jcea has quit [Ping timeout: 276 seconds]
itoral has joined #videocore
apinheiro has joined #videocore
<itoral> apinheiro: it seems that v3d was getting loop unrolling from mesa_st, but for vulkan we need to add that if we want
<itoral> and I guess we do
<itoral> I'll check if that makes any difference
<apinheiro[m]> itoral: ok
<itoral> apinheiro: it seems to make a difference in some cases
<itoral> Shooter is very slightly improved
<itoral> the Bloom demo from sascha willems is up almost 20% :)
<itoral> from 41fps to 50fps
<itoral> well, that is more than 20% actually
<apinheiro[m]> oh nice (the bloom one)
jcea has joined #videocore
itoral has quit [Remote host closed the connection]
itoral has joined #videocore
<itoral> mmm... sometimes it causes perf to regress though, I guess I should try to figure out why
itoral has quit [Remote host closed the connection]
itoral has joined #videocore
itoral has quit [Remote host closed the connection]
itoral has joined #videocore
<itoral> well, unrolling can increase register pressure and we end up spilling, that's why
<itoral> I guess I could add another compiler strategy for this... or just try to play with the max unrolls or something like that
<itoral> he, with the offscreen demo from sascha:
<itoral> no unroll: 16fps
<itoral> max unroll 32 iterations: 9 fps (tons of spilling)
<itoral> max unroll 16 iterations: 33 fps (no spilling)
<itoral> so we get +50% or -50% performance depending on whether unroll without causing spills
<itoral> apinheiro ^
<apinheiro[m]> itoral: well, I guess that we could also start to add heuristics for the strategies
<apinheiro[m]> so far we assume that the first ones would have better performance
<apinheiro[m]> well, or something more simple
<apinheiro[m]> add more "discard reasons"
<itoral> that's what we are already doing
<apinheiro[m]> right now the discard-strategy reason is "no register allocation"
<itoral> we just need to decide if we want to add another one for this
<apinheiro[m]> we could try to add also "this strategy is spilling"
<apinheiro[m]> <itoral "we just need to decide if we wan"> well, yes, but what I mean is that if we add another strategy
<itoral> no
<apinheiro[m]> something like "no rolls"
<itoral> we avoid spills with strategies
<apinheiro[m]> perhaps we want to discard the "with rolls" strategies if we have spilling
<itoral> at least with most of them
<itoral> right, that was my point
<itoral> about adding a strategy
<itoral> we never allow spills with any strategy at the moment
<itoral> or at least that is what I recall
<itoral> but maybe it is not obvious
<itoral> because that is tied to the fact that we only allow spilling when we drop to 2 threads
<itoral> and all our strategies disallow that
<apinheiro[m]> oh, sorry then I misremembered
<apinheiro[m]> so then we only allow spilling on the last strategy?
<itoral> well, more precisely "all optimizations enabled" strategy won't spill
<itoral> in any case
<itoral> but the do others allow spilling
<itoral> because they are not supposed to increase register pressure significantly
<itoral> anyway, I have to do some testing and think what we want to do for loops
<itoral> the problem with adding more and more strategies is that we can end up with really long compilation times
<itoral> but I guess in this case it would only affect shaders with unrolled loops, which are not plentiful
<itoral> so maybe it is not that big of an issue
<itoral> if we do it right
<itoral> it seems that 16 iterations avoids all the problems while keeping the performance gains in all Sascha demos
<apinheiro[m]> <itoral "the problem with adding more and"> well, but just in the worse case, right?
<apinheiro[m]> in any case, it would be interesting to check
<itoral> so maybe we should go with that and add a fallback strategy just in case that only kicks in if the shader had any unrolled loops
<apinheiro[m]> perhaps doing a shader-db with some extra info
<apinheiro[m]> of how many shaders need to rely to the worse strategy
<itoral> yes, only on the worse case
<itoral> but those cases do exist
<itoral> it is not about how many
<itoral> if it is just one
<itoral> and it happens in a gameplay loop
<itoral> it is very noticeable
<itoral> you already know that :)
<itoral> I guess it is not something too critical, but it is not irrelevant either
<apinheiro[m]> yes, and although we could blame vulkan users if they don't use caches, for opengl users is more tricky
itoral has quit [Read error: Connection reset by peer]
itoral has joined #videocore
itoral has quit [Quit: Leaving]
luckyxxl has joined #videocore
luckyxxl has quit [Quit: bye]
apinheiro has quit [*.net *.split]
apinheiro has joined #videocore
nroberts has quit [Ping timeout: 240 seconds]
nroberts has joined #videocore
txenoo has quit [Quit: Leaving]
jcea has quit [Quit: jcea]
jcea1 has joined #videocore
jcea1 is now known as jcea
apinheiro has quit [Ping timeout: 252 seconds]