Radeon Gallium3D Moved Closer To Performance Parity With AMD's Catalyst In 2014

[duby229]

Well point is i am good citizen to inform people, might he does not being aware of that and now he is . even that is more of a Tom's thing i think.

And one much more worsened example for radeon, under Wine 3DMark 2001 Car benchmark is spilling stutter festival - that is the best example i have for those spilling stutters

I'm sorry for misunderstanding you. Are you saying that the open source driver for radeon cards is causing the stuttering?

[dungeon]

I'm sorry for misunderstanding you. Are you saying that the open source driver for radeon cards is causing the stuttering?

Yes and no, spilling stutters are i guess llvm only... so basically radeonsi is affected, but r600 dunno probably not

It is about this bug, which is workarounded for games to work, but that cause stutter:

https://bugs.freedesktop.org/show_bug.cgi?id=75276

What i saying up there, issues is present in all drivers... it was stuttering whatever that happens on all GCN radeons, with radeon and flgrx, but also on windows... well Omega changed this but only on Windows, etc...

[duby229]

Yes and no, spilling stutters are i guess llvm only... so basically radeonsi is affected, but r600 dunno probably not

So then it's the shader compiler... From your description of the problem it seems like the game tries to compile shaders at a bad time, then once they're cached the symptoms lesson. I would try contacting the game author, they would have much better understanding of what is going on.

EDIT: reading bug report now.

[dungeon]

So then it's the shader compiler... From your description of the problem it seems like the game tries to compile shaders at a bad time, then once they're cached the symptoms lesson. I would try contacting the game author, they would have much better understanding of what is going on.

I don't think so, at least in case of Unigine Valley i watched ~/.AMD/GLCache/ it does compile shaders in the beginning while loading demo... but not where those stuttering usually happens, so it is not that i think .

radeonsi driver have same stutter in Valley as fglrx on linux, but yeah thing is only and windows only with omega driver that is changed... omega on windows instead of making that micro stutter first time, those frames where i expected stutter behave now quite opposite - it is fastened up somehow and everthing feels more smooth.

Basically that is about it, it is fast there whatever you will see stutter you will see speed up ... well on Windows opengl only If you like vsynced gaming or have crossfire on Windows, well that is probably even better scenario - you will not notice any stutter .

What to say - simple it is stutter free on Windows, there is not anmyore those: "first time it is slower (vgpr will stutter a little that was OK), second time it is better"... nope, now with omega on windows it is always fine .

[duby229]

Compiling shaders at loading time seems like a bad idea to me. Do you know where the game keeps the cache that those pre-compiled shaders are stored in? If the cache is on the hard drive, then it is probably an IO latency problem. Anything over like 10ms to 15ms would be noticeable, and that is right about where hard drive latency is.

[duby229]

EDIT: My guess is, this is just a guess I don't really know, the windows catalyst driver is able to prefetch those pre-compiled shaders into a buffer or cache in ram right before they are needed. That's probably something the OSS driver doesn't do as well or at all.

[dungeon]

EDIT: My guess is, this is just a guess I don't really know, the windows catalyst driver is able to prefetch those pre-compiled shaders into a buffer or cache in ram right before they are needed. That's probably something the OSS driver doesn't do as well or at all.

Yeah radeon, but also nor catalyst omega for linux also does not do this, only windows catalyst and only omega driver . Well i am not sure what is it, but at least is quite reproducable tesseract one case in complex map and unigine valley two cases on 7 and 10 scene, those are just examples probably that helps and remove vgpr stutter in other opengl games.

[Kraut]

We could try that, but like I said, it would make Wine a lot worse with the way Mesa works. It is not just one shader per application shader we would have to compile. In fact, for every application shader, we would have to compile hundreds of shaders in the driver that are slightly different variants of the same shader that may be needed due to a state change, etc. For a vertex shader, it would be even worse - more than 2^512 variants would need to be compiled to cover all cases. Yes, you could do that at loading time, but I am sure the loading would not end before the end of the universe, assuming you had enough memory. That is the reason why other drivers compile shaders on demand too or have to invent things like a shader cache. There is a lot of work needed before we can compile shaders at loading time on radeonsi at least, but other hardware drivers will not be so lucky, because the OpenGL design simply does not allow it there.

For the cases where you get the shader code in time:
Can you not make a basic "not perfectly fast" version of the shader that runs everything? And then compile a decent version in the background on demand?
Or is this the kind of thing that is limited by manpower right now?

[marek]

For the cases where you get the shader code in time:
Can you not make a basic "not perfectly fast" version of the shader that runs everything? And then compile a decent version in the background on demand?
Or is this the kind of thing that is limited by manpower right now?

Yes, it is limited by manpower. I was thinking about that too, but somebody would have to write a simple & dumb compiler and we would have to maintain 2 compilers for the same hardware.