AMD R600g LLVM Back-End Is Working A Bit Better

[agd5f]

Can I check which shader compiler is really used?

I (HD 6550M) have built mesa with --enable-r600-llvm-compiler and R600_LLVM set to 1. kwin with "opengl2 shaders" and xonotic work absolutely fine. By the way, xonotic on the "ultra" preset runs pretty good, so the radeon guys are doing something right.

edit: I guess I am using it. Portal 2 in wine with 32 bit crashes:

Backtrace:
=>0 0xf59deca4 in r600_dri.so (+0x14bca4) (0x0000027e)
  1 0xf5f95e10 in r600_dri.so (+0x702e0f) (0x7d6456ec)
  2 0xf5ee80ce _ZN4llvm19MachineFunctionPass13runOnFunctionERNS_8FunctionE+0x7d() in r600_dri.so (0xf696f0e8)
  3 0xf63a62b3 _ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE+0x272() in r600_dri.so (0x7d62e538)
  4 0xf63a630c _ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE+0x4b() in r600_dri.so (0x7d560068)
  5 0xf63a5f04 _ZN4llvm13MPPassManager11runOnModuleERNS_6ModuleE+0x1f3() in r600_dri.so (0x7d5c4038)
  6 0xf63a5fe9 _ZN4llvm15PassManagerImpl3runERNS_6ModuleE+0x78() in r600_dri.so (0x00000000)
  7 0xf63a6036 _ZN4llvm11PassManager3runERNS_6ModuleE+0x25() in r600_dri.so (0x00339a18)
  8 0xf59d21ef in r600_dri.so (+0x13f1ee) (0x00339a18)
  9 0xf59cfdfe in r600_dri.so (+0x13cdfd) (0x00339a90)
<snip>

The 32bit mesa build can sometimes pick up the 64 bit version of llvm depending on how you've configured things.

[agd5f]

The llvm backend does not support indirect addressing at the moment, so if a shader uses indirect addressing, it will always use the old backend so you will get the same results regardless of whether you enable the llvm backend or not in that case.

[ChrisXY]

The 32bit mesa build can sometimes pick up the 64 bit version of llvm depending on how you've configured things.

With

export LLVM_CONFIG=/usr/bin/llvm-config32

Which is:

 ~ % llvm-config32 --libdir
/usr/lib32/llvm

A sane fallback is really good.
Was the fallback active in the phoronix benchmarks?

[SavageX]

Wasn't Valve reportedly having issues with recompile times of dynamic/changing shaders during game run-time? /nitpick

Actually Xonotic/Nexuiz has problems with compile times. Whenever a new material/effect/whatever comination is encountered rendering will have to wait for a split second for the shader to compile. This is noticable especially in the first few seconds on a new map.

[agd5f]

A sane fallback is really good.
Was the fallback active in the phoronix benchmarks?

You'd have to check the shaders used by those applications.

[curaga]

Actually Xonotic/Nexuiz has problems with compile times. Whenever a new material/effect/whatever comination is encountered rendering will have to wait for a split second for the shader to compile. This is noticable especially in the first few seconds on a new map.

Why? Surely you could cache those at level load time?

[Hamish Wilson]

I did not know that Michael had started using Prey as a benchmark.

[SavageX]

Why? Surely you could cache those at level load time?

In theory yes, but the amount of possible shader combinations is surprisingly high and if done, e.g., on hard disk one needs to sure one does not try to stuff outdated shader compiles into the wrong card/driver/whatever.

It should be feasible to overcome these problems, but nobody made an attempt. It's a big more complicated than it sounds at first.