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

Thread: NIR: A New IR Developed For Mesa That's Better Than GLSL IR

  1. #21
    Join Date
    Jul 2010
    Posts
    492

    Default

    Quote Originally Posted by rohcQaH View Post
    don't forget that work on this IR started before opengl next was announced.

    I haven't seen any actual technical arguments against LLVM, except that it causes tables to flip. If there was an actual discussion about the shortcomings of LLVM-IR, I think that'd be more productive than a single vendor creating a new IR from scratch without input from the others. Right now, to an outside observer, it looks like intel was unable to get LLVM to work and thus decided to pull a NIH instead.
    From mailing list:
    NIR supports structured control flow, swizzles and writemasks, modifiers
    (abs, negate, saturate), etc. natively in the IR instead of something
    that's tacked on or something that drivers have to do themselves. So
    no, I'm not re-inventing LLVM.
    I guess they want something that better matches their hw?

    From http://www.freedesktop.org/wiki/Soft...ured_branches/
    Transforming the LLVM IR code into structured code results in basically reverse-engineering the LLVM code into the original C code.
    Although it seems to be a solved issue, at least for Beignet.

  2. #22
    Join Date
    Jun 2012
    Posts
    5

    Default

    Quote Originally Posted by log0 View Post
    From mailing list:

    I guess they want something that better matches their hw?

    From http://www.freedesktop.org/wiki/Soft...ured_branches/

    Although it seems to be a solved issue, at least for Beignet.
    Control flow in SIMD program is an interesting topic. Beignet developpers quite improved the initial implementation described here. They first used if/endif to mask out block. This allows much better codegen. And they added some structural analysis to match if/else/endif, if/endif, ifnot/endif and ifnot/else/endif. This allows recursive mixing of simple (hardware supported) structured branches and software emulated unstructured branches as I did initially.

    Other stuffs should be considered then like interaction with loops, divergence analysis to ensure proper reconvergence of control flow. For example, structured control flow may be not that good regarding SIMD occupancy. break instructions (as in HLSL IR or glsl IR or even in HW) are an example of a poorly designed approach regarding SIMD occupancy. Even HW implementers poorly designed some of their branches regarding SIMD occupancy.

    Anyway, this is a cool topic :-)

  3. #23
    Join Date
    Sep 2011
    Posts
    260

    Default

    Quote Originally Posted by amehaye View Post
    Have you already take the compilers course in the university ?
    Joking aside, if you hadn't yet you should before finalizing the language. It would save a lot of grief in the future.
    s/take/teach/ :-P

    I really doubt an undergrad level compiler course would teach cwabbot anything new at this point.

    re: LLVM.. I'm not really sure it is worth the headache. It sounds very attractive in concept. It would be nice if it wasn't written in C++, or at least restricted itself to a subset of C++ to make it a bit more sane to use as a library. I am at least pretty happy not to have to frequently rebuild whatever private version of LLVM that mesa needs that week on a little arm device. It would be nice if somehow (at the gallium level) I could get an SSA (or use-def) type IR (rather than TGSI) with a concept of basic-blocks, which would save me from having to turn TGSI back into use-def graph. I guess if there was a way to re-use passes for CSE and perhaps rematerialization that could be nice. OTOH, instruction scheduling and that sort of thing really aren't too hard to implement once you have SSA/use-def.

  4. #24
    Join Date
    Sep 2011
    Posts
    260

    Default

    Quote Originally Posted by Rakot View Post
    And why the heck they decided to implement this new IR?
    To me these decisions are made mostly due to political rather than technical reasons. Exactly the same thing as intel did with mir. You may like or hate Canonical for this decision but why to remove support from the driver? Intel is known for making its own in-home solutions incompatible with other drivers (keeping classic mesa driver, ignoring clover by introducing new technology, ignoring LLVM etc).
    If someone could clarify their decisions with only technical arguments I'll be more than happy to change my pov.
    I see very little in common between mir vs. wayland, and LLVM vs. NIR. At least the latter does not have impact on application writers, toolkit writers, etc. It is merely an implementation detail within mesa.

  5. #25
    Join Date
    Sep 2011
    Posts
    260

    Default

    Quote Originally Posted by Daktyl198 View Post
    Why didn't Intel and this developer just take the Gallium TGSI IR and maybe tweak that a bit here and there to suit their needs? That seems like less work, for sure, with very similar results in the end. Plus, then we wouldn't have what? 4 different freaking IRs? 2 of which we either don't use, or use as an intermediary step for literally no reason other than nobody wants to do the work to remove that step.
    TGSI is not a real IR. Every gallium driver that needs to do any sort of optimization, instruction scheduling, etc, turns TGSI into it's own private internal IR.

    I'd be curious if they make the same mistake w/ the NewGL (is there a name for it yet?) IR.. if so, then we'll be back to turning it into something suitable for a compiler.

  6. #26
    Join Date
    Oct 2013
    Posts
    3

    Default

    Quote Originally Posted by Rakot View Post
    And why the heck they decided to implement this new IR?
    Intel is known for making its own in-home solutions incompatible with other drivers (keeping classic mesa driver, ignoring clover by introducing new technology, ignoring LLVM etc).
    If someone could clarify their decisions with only technical arguments I'll be more than happy to change my pov.
    IMO, so that others (competition) would not benefit so much(directly) from their work.

  7. #27
    Join Date
    Sep 2011
    Posts
    260

    Default

    Quote Originally Posted by xxmitsu View Post
    IMO, so that others (competition) would not benefit so much(directly) from their work.
    I don't expect LLVM vs NIR makes any difference to re-use from other mesa drivers, so much so as figuring out how to plumb it through gallium..

    The non-mesa drivers, we don't care about one way or another.

Posting Permissions

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