Page 3 of 3 FirstFirst 123
Results 21 to 28 of 28

Thread: AMD's R600 GPU LLVM Back-End To Be Renamed

  1. #21
    Join Date
    Aug 2009
    Posts
    89

    Default

    Quote Originally Posted by bridgman View Post
    Remember that there are essentially two different paths for a driver -- runtime calls and shader programs. The Gallium3D driver handles runtime calls, so the runtime path is essentially GL => Gallium3D => PM4 packets submitted to the hardware via the kernel driver.

    Assuming that nothing has changed recently :

    For GL shaders on VLIW hardware, the default path is GLSL (passed to GL) => GLSL IR (internal to Mesa driver**) => TGSI (passed to Gallium3D driver) => HW ISA (passed to hardware). The optional (for VLIW) LLVM path is GLSL => GLSL IR => TGSI => LLVM IR => HW ISA, where the r600 LLVM back end takes care of the last step.

    For GL shaders on GCN hardware the path is always GLSL => GLSL IR => TGSI => LLVM IR => HW ISA, and again the r600 LLVM back end takes care of the last step.

    For OpenCL kernels the path is CL C => LLVM IR => HW ISA, ie the Gallium3D driver has been modified to optionally accept LLVM IR directly rather than always receiving TGSI and converting it to LLVM IR. Again, the r600 LLVM back end takes care of converting LLVM IR to HW ISA.

    ** If I remember correctly the Intel GL driver converts GLSL IR directly to HW ISA, without going through TGSI or Mesa IR.
    Thanks for the explanation bridgman. So from a performance perspetive, on R600 HW it is better to not use LLVM for shaders since there's one step less in the pipeline ?

    I have not yet tested it since I expected LLVM to replace a step and not add one in the pipeline.

  2. #22
    Join Date
    Oct 2008
    Posts
    3,133

    Default

    Quote Originally Posted by haplo602 View Post
    Thanks for the explanation bridgman. So from a performance perspetive, on R600 HW it is better to not use LLVM for shaders since there's one step less in the pipeline ?

    I have not yet tested it since I expected LLVM to replace a step and not add one in the pipeline.
    Most likely, although if the LLVM compiler is able to optimize things better than the custom r600 backend in mesa it would probably far outweigh the minimal overhead of having an extra stage present.

    The real reason to not use LLVM on r600 hardware is simply that the existing backend is already fairly well tested and working, and rewriting it all in llvm is likely to be a long, frustrating task. No one seems to be quite sure exactly how well llvm could optimize for a VLIW architecture like r600 hardware uses, either, so there is no real compelling reason to even try right now other than getting compute running (on older, slower hardware where it's less interesting for most anyway). I'm sure someone could make an interesting doctorate project out of it.

    GCN hardware is a little more similar to the other hardware LLVM is used on, and the hardware also runs much more complex programs, which is why it was decided that a full-blown compiler stack like LLVM would be better suited there.
    Last edited by smitty3268; 08-05-2014 at 02:42 AM.

  3. #23
    Join Date
    Sep 2010
    Posts
    683

    Default

    While Intel do have new gen gpu architecture every few months. Those are mostly extensions to previous hw.

    Basic rules are same for whole i965. (And optimization techniques too)

    They yet to have to switch to something different.

    It may be coming (DX12/Mantle/OpenGL "AZDO"/whatever-new-fancy-stuff-conquer-world do change a bit the environment, and Intel may decide to switch to "superscalar" architecture. Such move would mean new driver, maybe even LLVM based)

    But for broadwell it will still be GEN.

    Nvidia switched to "superscalar" years ago, and now they only change "details" (like actual commands that need to be submitted to the GPU ).

    AMD switched to "superscalar" for good only with GCN.

  4. #24
    Join Date
    Jul 2010
    Posts
    490

    Default

    Quote Originally Posted by smitty3268 View Post
    Most likely, although if the LLVM compiler is able to optimize things better than the custom r600 backend in mesa it would probably far outweigh the minimal overhead of having an extra stage present.

    The real reason to not use LLVM on r600 hardware is simply that the existing backend is already fairly well tested and working, and rewriting it all in llvm is likely to be a long, frustrating task. No one seems to be quite sure exactly how well llvm could optimize for a VLIW architecture like r600 hardware uses, either, so there is no real compelling reason to even try right now other than getting compute running (on older, slower hardware where it's less interesting for most anyway). I'm sure someone could make an interesting doctorate project out of it.

    GCN hardware is a little more similar to the other hardware LLVM is used on, and the hardware also runs much more complex programs, which is why it was decided that a full-blown compiler stack like LLVM would be better suited there.
    I am pretty sure that the LLVM backend can handle VLIW. http://www.phoronix.com/scan.php?pag...tem&px=MTQxMDM

  5. #25
    Join Date
    Jan 2010
    Posts
    364

    Default

    Quote Originally Posted by log0 View Post
    I am pretty sure that the LLVM backend can handle VLIW. http://www.phoronix.com/scan.php?pag...tem&px=MTQxMDM
    It can generate code for R600-class hardware, yes. Whether it can really handle it properly is up for debate.

  6. #26
    Join Date
    Aug 2009
    Posts
    89

    Default

    Quote Originally Posted by smitty3268 View Post
    Most likely, although if the LLVM compiler is able to optimize things better than the custom r600 backend in mesa it would probably far outweigh the minimal overhead of having an extra stage present.

    The real reason to not use LLVM on r600 hardware is simply that the existing backend is already fairly well tested and working, and rewriting it all in llvm is likely to be a long, frustrating task. No one seems to be quite sure exactly how well llvm could optimize for a VLIW architecture like r600 hardware uses, either, so there is no real compelling reason to even try right now other than getting compute running (on older, slower hardware where it's less interesting for most anyway). I'm sure someone could make an interesting doctorate project out of it.

    GCN hardware is a little more similar to the other hardware LLVM is used on, and the hardware also runs much more complex programs, which is why it was decided that a full-blown compiler stack like LLVM would be better suited there.
    tested stock, r600_debug=sb and r600_llvm=1 in uniqine valley for a quick one. r600_debug=sb is fastest.

  7. #27
    Join Date
    Sep 2013
    Posts
    216

    Default

    Quote Originally Posted by haplo602 View Post
    tested stock, r600_debug=sb and r600_llvm=1 in uniqine valley for a quick one. r600_debug=sb is fastest.
    Interesting. What driver version you used?

    I wonder and only bumping this topic because there likely no R600_LLVM for many months and you need to use R600_DEBUG=llvm instead to actually make LLVM shader backend work. Also as far as I remember it's compatible with "sb" for even longer.

    Though it's sad that LLVM compiler isn't actually works on R600...

  8. #28
    Join Date
    Aug 2009
    Posts
    89

    Default

    Quote Originally Posted by _SXX_ View Post
    Interesting. What driver version you used?

    I wonder and only bumping this topic because there likely no R600_LLVM for many months and you need to use R600_DEBUG=llvm instead to actually make LLVM shader backend work. Also as far as I remember it's compatible with "sb" for even longer.

    Though it's sad that LLVM compiler isn't actually works on R600...
    hmm ... seems I have to retest :-) I got the infor from phoronix articles where Michael tested sb and llvm ...

Posting Permissions

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