Results 1 to 8 of 8

Thread: Scheduler Code Merged For AMD R600 LLVM Back-End

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    15,199

    Default Scheduler Code Merged For AMD R600 LLVM Back-End

    Phoronix: Scheduler Code Merged For AMD R600 LLVM Back-End

    The initial scheduler code has been merged into AMD's R600 GPU LLVM back-end...

    http://www.phoronix.com/vr.php?view=MTMxOTE

  2. #2
    Join Date
    Mar 2011
    Posts
    27

    Default

    This commit only concerns r600 gpu, not radeonsi. I'm still working on scheduling though and this commit isn't likely to give the best from the gpu at the moment, however it makes performance more consistent (by gathering fetch instructions and thus using built-in hardware fetch latency hiding). In fact it fixes some situation where llvm generated code performance was worse than the ones of classic generated code.

  3. #3
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    532

    Default

    Quote Originally Posted by vljn View Post
    This commit only concerns r600 gpu, not radeonsi. I'm still working on scheduling though and this commit isn't likely to give the best from the gpu at the moment, however it makes performance more consistent (by gathering fetch instructions and thus using built-in hardware fetch latency hiding). In fact it fixes some situation where llvm generated code performance was worse than the ones of classic generated code.
    Is Vadim's work on shader optimization is in good use for you?

  4. #4
    Join Date
    Nov 2008
    Location
    Madison, WI, USA
    Posts
    877

    Default

    Quote Originally Posted by Drago View Post
    Is Vadim's work on shader optimization is in good use for you?
    If I understood the mailing list conversations correctly, Vadim's shader optimization work is currently only useful for the TGSI back-end, not the LLVM back-end... Although there's chances to take the lessons learned to guide future LLVM back-end developments.

  5. #5
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    532

    Default

    Quote Originally Posted by Veerappan View Post
    If I understood the mailing list conversations correctly, Vadim's shader optimization work is currently only useful for the TGSI back-end, not the LLVM back-end... Although there's chances to take the lessons learned to guide future LLVM back-end developments.
    Yes, that is exactly what I meant. To use ideas from it, not code porting.

  6. #6
    Join Date
    Mar 2011
    Posts
    27

    Default

    Quote Originally Posted by Veerappan View Post
    If I understood the mailing list conversations correctly, Vadim's shader optimization work is currently only useful for the TGSI back-end, not the LLVM back-end... Although there's chances to take the lessons learned to guide future LLVM back-end developments.
    sb600 actually postprocess the bytecode emitted by either tgsi or llvm so it can be used with both backend. However sb600 applies optimisations also applied internally by llvm so it makes more sense to use it with tgsi.

    Quote Originally Posted by Drago View Post
    Yes, that is exactly what I meant. To use ideas from it, not code porting.
    Indeed I compared code emitted by sb600 to find where llvm is not optimal when it comes to scheduling, but most of the design idea came with discussions on irc with vadimg. For instance future patches will bring bottom-up scheduling instead of top-bottom scheduling because work on sb600 showed it to be better in most situation. Vadimg has also better knowledge of the hw than I do and I figured out some constraints llvm puts on instructions that were not mandatory (on dot4 instructions mainly) ; his experience is really helpful.

Posting Permissions

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