Better LLVM IR Generation Coming For RadeonSI

[phoronix]

Phoronix: Better LLVM IR Generation Coming For RadeonSI

Well known Mesa developer Marek Olš?k has published a new patch series that yields better LLVM IR generation with the RadeonSI Gallium3D driver...

http://www.phoronix.com/scan.php?page=news_item&px=RadeonSI-Better-LLVM-IR

[artivision]

I believe that Mesa needs GL_threaded_optimizations and DX_threaded_optimizations for Nine, there are many single threaded games ported from consoles that tthey need the last one. Then someone must clean Nine and reduce the Cpu overhead from an extra 20-40% that is today to Native.

[brent]

More importantly, there are also some change for radeonsi and Gallium to compile shaders early instead of on demand. Getting the lags due to shader compilation under control finally seems to be closer.

[andrei_me]

How does one read/interpret the shader-db result/statistics?

[przemoli]

How does one read/interpret the shader-db result/statistics?

Shader db to set of real world shaders. By mesa devs usually used as compiler benchmark.

Simply put as long as both versions produce correct output, less is better or faster is better, all depending on particular trade off pursued.

Here its size as in number of instructions for shader generated from opengl shader language source code.
So less is better.

[mannerov]

I believe that Mesa needs GL_threaded_optimizations and DX_threaded_optimizations for Nine, there are many single threaded games ported from consoles that tthey need the last one. Then someone must clean Nine and reduce the Cpu overhead from an extra 20-40% that is today to Native.

Nine is not CPU limited. The overhead is not big.

That with that in mind marek decided threading optimisation should be done at levels that won't benefit nine (if done at gallium api level, it would have benefited nine, but less ogl).

[Kemosabe]

More importantly, there are also some change for radeonsi and Gallium to compile shaders early instead of on demand. Getting the lags due to shader compilation under control finally seems to be closer.

This i never really got. When i program my OpenGL application i have to bind, link and compile the shader. This means the programmer controls when it is done?!

[log0]

This i never really got. When i program my OpenGL application i have to bind, link and compile the shader. This means the programmer controls when it is done?!

Nope. That is implementation detail. Depending on hardware the driver might have to emulate certain OpenGL functionality using shaders, generate shader variants.

[artivision]

Nine is not CPU limited. The overhead is not big.

That with that in mind marek decided threading optimisation should be done at levels that won't benefit nine (if done at gallium api level, it would have benefited nine, but less ogl).

Sorry but it is. In my FFXIII benchmarks i lose a 40% of the frame rate that i have on Windowz (i3mAVX@2,4ghz=15fps). The problem is that the Cpu is at max and the Gpu (RadeonGNC-384sp@975mhz) doesn't fill and works at 600mhz+, even if i force 975mhz the frame rate is the same and one core is full. Also FFXIII as a console port is a single thread game or at least uses only one thread on Nine. Nine always gives me 20-40% lower frame rate than Windowz and it isn't Gpu based.

Also i was speaking for extra DX_threaded_optimizations only for single threaded games (usually ported from consoles), all based on the todays GL_threaded_optimizations and not for lower level optimizations.

[geearf]

Nine is not CPU limited. The overhead is not big.

That with that in mind marek decided threading optimisation should be done at levels that won't benefit nine (if done at gallium api level, it would have benefited nine, but less ogl).

Where will these optimisations happen then?
Would nine not be able to somehow replicate these if they're happening within the OGL path?