Results 1 to 4 of 4

Thread: Mesa GLSL IR Gets Single Static Assignment Support

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

    Default Mesa GLSL IR Gets Single Static Assignment Support

    Phoronix: Mesa GLSL IR Gets Single Static Assignment Support

    Connor Abbott, the high school student that has been working extensively on the Lima ARM reverse-engineered graphics driver, is now working on Single Static Assignment (SSA) support inside Mesa...

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

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

    Default

    If developers are writing the same set of optimizations across multiple driver back-ends, and this work is already done in other compilers (that may not get invoked within the context of compiling shaders for a back-end), it makes sense to do those optimizations at a higher level once for all architectures, instead of rewriting the same code for each driver (and forgetting to do them for some drivers).

    As long as the optimizations are safe and beneficial to run for all architectures, why wouldn't we. Now the question is how many optimizations can be added that aren't already performed at the same level, and how much code complexity could be reduced.

  3. #3
    Join Date
    Oct 2008
    Posts
    3,176

    Default

    Quote Originally Posted by Veerappan View Post
    If developers are writing the same set of optimizations across multiple driver back-ends, and this work is already done in other compilers (that may not get invoked within the context of compiling shaders for a back-end), it makes sense to do those optimizations at a higher level once for all architectures, instead of rewriting the same code for each driver (and forgetting to do them for some drivers).

    As long as the optimizations are safe and beneficial to run for all architectures, why wouldn't we. Now the question is how many optimizations can be added that aren't already performed at the same level, and how much code complexity could be reduced.
    The driver back-end optimizations will probably largely have to stay around, since things like OpenCL don't use GLSL IR. Unless someone does the SSA at the TGSI level, or eventually moves the state trackers to use GLSL IR directly instead of TGSI.

  4. #4
    Join Date
    Sep 2011
    Posts
    285

    Default

    Quote Originally Posted by Veerappan View Post
    If developers are writing the same set of optimizations across multiple driver back-ends, and this work is already done in other compilers (that may not get invoked within the context of compiling shaders for a back-end), it makes sense to do those optimizations at a higher level once for all architectures, instead of rewriting the same code for each driver (and forgetting to do them for some drivers).

    As long as the optimizations are safe and beneficial to run for all architectures, why wouldn't we. Now the question is how many optimizations can be added that aren't already performed at the same level, and how much code complexity could be reduced.
    getting the shader program into SSA form is something that is useful to everyone (or at least would be if this didn't get lost at the GLSL IR -> TGSI step)

Posting Permissions

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