<FLHerne>
It's trivial and reviewed, but the author can't
nchery has joined #dri-devel
<emersion>
done
mclasen has joined #dri-devel
sravn has joined #dri-devel
gawin has joined #dri-devel
<FLHerne>
:-)
mszyprow has joined #dri-devel
iive has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
gawin has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
gawin has joined #dri-devel
MajorBiscuit has joined #dri-devel
hch12907_ has joined #dri-devel
hch12907 has quit [Ping timeout: 480 seconds]
jewins has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: Lost terminal]
pcercuei has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
jljusten has joined #dri-devel
jljusten has quit [Remote host closed the connection]
jljusten has joined #dri-devel
ybogdano has quit [Read error: Connection reset by peer]
gawin has joined #dri-devel
zip100_ has joined #dri-devel
zip100 has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
JohnnyonFlame has joined #dri-devel
ybogdano has joined #dri-devel
camus1 has joined #dri-devel
Wallbraker[m] has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
sravn has quit [Ping timeout: 480 seconds]
sravn has joined #dri-devel
<gawin>
anholt: not sure if this is what you wanted, but removes "ping pong" from earlier version
<anholt>
I'll take a look and make sure the CTS fails get updated, but it looks plausible. Now that I see the reset of the src reg, the pingpong makes sense, and that version was fine too
ngcortes has joined #dri-devel
<ngcortes>
qq; we just got some tg-l nucs that seem to crash when running a git fetch... anybody else seen this crazy behavior on mainline kernel
nchery has quit [Remote host closed the connection]
tango_ is now known as Guest9488
tango_ has joined #dri-devel
Guest9488 has quit [Ping timeout: 480 seconds]
bylaws has joined #dri-devel
<bylaws>
Hi, I noticed that the non-lowering NIR algebraic opts take quite a while on freedreno (roughly 10% of total time in my dataset)
<bylaws>
I was wondering if toggling if only lowering opts should be done via a parameter is an okay solution?
gouchi has quit [Remote host closed the connection]
ifreund has quit [Read error: Connection reset by peer]
ifreund has joined #dri-devel
cphealy_ has joined #dri-devel
cphealy has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
x512 has joined #dri-devel
<x512>
Where flush_frontbuffer function table entry is supposed to be set in radeonsi? It is set by Zink.
<jekstrand>
bylaws: On vacation at the moment so this isn't a great time for this discussion...
<jekstrand>
bylaws: Short version is that I doubt restricting algebraic to lowering-only in that way is going to help much.
<bylaws>
I mean 10% is a fair bit
<jekstrand>
bylaws: by the time that particular flag makes a difference, we've already done most of the work to match. If disabling it at that point is helping then it's probably because you're making it faster by just doing less optimization.
<jekstrand>
THat's not going to be good for the quality of final code-gen
<bylaws>
Yeah I'm aware
<bylaws>
I'm meaning as having it for something like vulkans disable optimisation bit
gawin has quit [Read error: No route to host]
gawin has joined #dri-devel
<bylaws>
Definitely not by default
<jekstrand>
It also may increase compile time for some stuff it it causes RA to take longer
<jekstrand>
Though, now that freedreno does SSA-based RA, it's probably fast enough to not be a problem.
<bylaws>
Yeah I should probably test it on a larger dataset, just been doing it locally with dolphins precompile shader option
<jekstrand>
But even there, if we restrict instruction counts early on, it makes every later pass faster.
<bylaws>
If the gains I see in shader db or whatever match dolphin would it be okay then?
<jekstrand>
Maybe. I'm generally skeptical of the Vulkan no optimization flag
<bylaws>
Oh, why's that?
<jekstrand>
I'm also concerned that it might make the "normal" case slower.
<jekstrand>
Because it's horribly badly defined. Sure, we could do less optimization but there's no actual guarantee that it'd make compiles faster. Some drivers use it to disable cross-stage linking. ANV ignires it.
<jekstrand>
I'm not sure what all the other drivers out there do.
<jekstrand>
I mean, feel free to prove me wrong. :)
<jenatali>
D3D considered adding a similar skip-optimization flag, but ended up not doing it for the exact reasons you're describing. Some drivers would just ignore it, and it'd be poorly defined across the board
<jekstrand>
The original idea was that apps could get a fast version of the shader and then throw compiling the "real" version in a background thread. I've yet to see a case where an app has done that and gotten siginificant gains from it.
<bylaws>
Yeah I don't see it being significant, but even a 10% increase is pretty good when it's impossible to compile them anytime other than runtime
<jekstrand>
Except that it then needs to compile twice.
<jekstrand>
Because you really don't want to be running that shader for long.
<bylaws>
Yeah, but there's plenty of spare cores on mobile
<jekstrand>
Anyone who uses the optimization disable flag should assume the resulting shader is catestrophically slow.
<jekstrand>
Yeah, it might be better but I'd like to see data before I believe that it is.
<jekstrand>
Anyway, I'm pretty skeptical, but feel free to prove me wrong. :)
<jekstrand>
At the end of the day, making apps faster is good, as long as we can do it without sacrificing something important to get there.
<bylaws>
Okay :) I'll wait until we have it working on the app side and see results before proposing anything
<kisak>
don't be surprised if the time spent in the driver making the hardware sane is much longer than the optional optimizations.
<jekstrand>
Also, expect to get different results on different compilers/hardware.
<jekstrand>
Intel RA is complicated enough and the back-end compiler has enough O(n^2) right now that optimizing up-front first may save a lot of time later.
<jekstrand>
But, again, happy to be proven wrong with data. :)
<bylaws>
Yeah I would probably only hook it up for tu
lstrano_ has joined #dri-devel
heat has joined #dri-devel
lstrano has quit [Quit: leaving]
lstrano_ has left #dri-devel [#dri-devel]
lstrano has joined #dri-devel
Duke` has quit [Ping timeout: 480 seconds]
<robclark>
bylaws: there is also the question of, once you add shader-cache, does it matter that much? Shader cache hits are pretty fast (although for android, not sure if there is something equiv to egl blob cache extension that needs to be wired up.. or if for vk is it all up to the app to manage cache?)
MajorBiscuit has quit [Quit: WeeChat 3.3]
<airlied>
yeah the disabling opts and still creating a functioning shader is a tricky needle to thread
<bylaws>
robclark Even with shader cache it's still lots of constant stutters as new shaders are encountered
<airlied>
yeah I really dislike the valve workaround, but appreciate it was the best way
cworth has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
<HdkR>
airlied: So what you're saying is that Steam needs to be everywhere so the shader caching infrastructure is available everywhere :P
cworth has joined #dri-devel
<airlied>
HdkR: we should build steam independent shared caching infrastructure :-P, just a giant git tree of shader binaries