Page 2 of 2 FirstFirst 12
Results 11 to 18 of 18

Thread: AMD R600g LLVM Back-End Is Working A Bit Better

  1. #11
    Join Date
    Dec 2007
    Posts
    2,279

    Default

    Quote Originally Posted by ChrisXY View Post
    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:
    Code:
    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.

  2. #12
    Join Date
    Dec 2007
    Posts
    2,279

    Default

    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.

  3. #13
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    969

    Default

    Quote Originally Posted by agd5f View Post
    The 32bit mesa build can sometimes pick up the 64 bit version of llvm depending on how you've configured things.
    With
    Code:
    export LLVM_CONFIG=/usr/bin/llvm-config32
    Which is:
    Code:
     ~ % llvm-config32 --libdir
    /usr/lib32/llvm
    A sane fallback is really good.
    Was the fallback active in the phoronix benchmarks?

  4. #14
    Join Date
    Feb 2008
    Posts
    88

    Default

    Quote Originally Posted by Veerappan View Post
    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.

  5. #15
    Join Date
    Dec 2007
    Posts
    2,279

    Default

    Quote Originally Posted by ChrisXY View Post
    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.

  6. #16
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,752

    Default

    Quote Originally Posted by SavageX View Post
    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?

  7. #17
    Join Date
    Oct 2011
    Location
    Rural Alberta, Canada
    Posts
    981

    Default

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

  8. #18
    Join Date
    Feb 2008
    Posts
    88

    Default

    Quote Originally Posted by curaga View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •