Announcement

Collapse
No announcement yet.

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

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

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

    Connor Abbott, the open-source developer that began contributing to the Lima Linux graphics driver while a high school student, was interning at Intel this summer even before starting college. Over the summer the focus of his Intel Linux internship was focusing on developing a new intermediate representation for Mesa graphics drivers...

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

  • #2
    So it is intel's fault that the Lima driver is not yet finished!

    Comment


    • #3
      That's kind of fun. Once I saw this announcement first time the MIR just came into my mind. After reading the description of this patch set and earlier discussion I confirmed my first impression that it is NIH syndrome. More interesting is that this kid suffered from the same problem as all young unexperienced people: he really underestimated the complexity of the problem. In February he wrote that the initial work would take him at most 2 months while other developers mentioned a half of year time frame. And you know what, it took him exactly 6 months to make this first patchset.
      As a side note. What I also do not understand is why does Intel ignore LLVM. Ian mentioned that they tried a couple of time and they did not succeed. Meantime Tom from AMD and a couple of other folks already achieved speed parity of radeonSI hardware compared to catalyst in a number of workloads. So does it mean that intel developers are so weak? Or am I missing very important point here?
      Also how does this patchset overlap with Vadim's sb work?

      Comment


      • #4
        Originally posted by Rakot View Post
        That's kind of fun. Once I saw this announcement first time the MIR just came into my mind. After reading the description of this patch set and earlier discussion I confirmed my first impression that it is NIH syndrome. More interesting is that this kid suffered from the same problem as all young unexperienced people: he really underestimated the complexity of the problem. In February he wrote that the initial work would take him at most 2 months while other developers mentioned a half of year time frame. And you know what, it took him exactly 6 months to make this first patchset.
        As a side note. What I also do not understand is why does Intel ignore LLVM. Ian mentioned that they tried a couple of time and they did not succeed. Meantime Tom from AMD and a couple of other folks already achieved speed parity of radeonSI hardware compared to catalyst in a number of workloads. So does it mean that intel developers are so weak? Or am I missing very important point here?
        Also how does this patchset overlap with Vadim's sb work?
        Where does he give a time frame for said project?
        Also, he didn't ignore LLVM: http://lists.freedesktop.org/archive...st/066026.html
        Not sure about about Vadim's work so I won't comment.
        EDIT: It's not NIH whenever you believe the new technology is superior in various ways, not just in a different style.

        Comment


        • #5
          Originally posted by computerquip View Post
          Where does he give a time frame for said project?.
          Here is a link:
          http://lists.freedesktop.org/archive...ry/053526.html

          I was talking about intel not him. See Ian's respons to Tom:
          http://lists.freedesktop.org/archive...ry/053522.html

          EDIT: It's not NIH whenever you believe the new technology is superior in various ways, not just in a different style.
          I would agree with this statement if there will not be LLVM.

          Comment


          • #6
            Originally posted by Rakot View Post
            Here is a link:
            http://lists.freedesktop.org/archive...ry/053526.html


            I was talking about intel not him. See Ian's respons to Tom:
            http://lists.freedesktop.org/archive...ry/053522.html


            I would agree with this statement if there will not be LLVM.
            The discussion I saw on the mailing lists centered around the LLVM API.

            The short version: the C API is somewhat limited, the C++ API is unstable, and neither API is sufficient in itself, they'd also have to create an LLVM backend in order to make it work, and in all cases bending LLVM to this task is rage-inducing.

            The my experience matches their's pretty well on the first two. On the matter of API insufficiency and needing to write a new backend, I have no relevant experience but no one seemed to be disputing that point on the list.

            Comment


            • #7
              Originally posted by Rakot View Post
              Here is a link:
              http://lists.freedesktop.org/archive...ry/053526.html


              I was talking about intel not him. See Ian's respons to Tom:
              http://lists.freedesktop.org/archive...ry/053522.html


              I would agree with this statement if there will not be LLVM.
              Try to see it from Intel pov. To switch to LLVM would mean rewrite a lot of code for no reason, there is no guarantee that LLVM will be faster than current code. They also would be dependent on LLVM, which can be seen as a handicap, as you are less flexible compared to using your own code.

              Comment


              • #8
                Originally posted by computerquip View Post
                Where does he give a time frame for said project?
                While I started thinking about this around February, I did most of the work at Intel for the ~2 months I was at Portland.

                Comment


                • #9
                  Originally posted by cwabbott View Post
                  While I started thinking about this around February, I did most of the work at Intel for the ~2 months I was at Portland.
                  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.

                  Comment


                  • #10
                    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.
                    Well, I don't think there's much to learn in a compilers course that I would already know TBH... college will be pretty boring

                    Comment


                    • #11
                      Originally posted by log0 View Post
                      Try to see it from Intel pov. To switch to LLVM would mean rewrite a lot of code for no reason, there is no guarantee that LLVM will be faster than current code. They also would be dependent on LLVM, which can be seen as a handicap, as you are less flexible compared to using your own code.
                      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.

                      Comment


                      • #12
                        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.
                        None of the three vendors are perfect when it comes to graphics drivers on Linux. It seems we can't have nice things.

                        Comment


                        • #13
                          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.
                          Maybe they thought it would be an interesting task for an intern? Also an IR doesn't make a compiler...

                          And the points I've named in my reply are not technical reasons? I see.

                          Comment


                          • #14
                            Originally posted by log0 View Post
                            Maybe they thought it would be an interesting task for an intern? Also an IR doesn't make a compiler...

                            And the points I've named in my reply are not technical reasons? I see.
                            For me not really. It's just a bunch of assumptions. For me the example of the technical reasons are Vadim's posts about why LLVM is not good when he introduced his SB backend (you can check mesa-mailing list somewhere in november, 2013).
                            As for this particular work the same argument applies to NIR (just for reference check Ian's posts in February).
                            To be clear, I'm not against new technologies. I'm for wider communication and unification between different vendors in Linux world. I appreciate the amount of effort intel put into linux graphics stack but when it comes to incompatible solutions it is not good at all (and i don't mean NIR here).

                            Comment


                            • #15
                              Didn't Khronos announce that the "next generation" OpenGL will come with its own new IR? If that's true, there's little point reinventing new placeholder IRs at this time.

                              Comment

                              Working...
                              X