Announcement

Collapse
No announcement yet.

Intel Has Been Quietly Developing A New Backend Compiler For Their OpenGL/Vulkan Drivers

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

  • Intel Has Been Quietly Developing A New Backend Compiler For Their OpenGL/Vulkan Drivers

    Phoronix: Intel Has Been Quietly Developing A New Backend Compiler For Their OpenGL/Vulkan Drivers

    One of the interesting reveals so far from this week's X.Org Developers' Conference in Montreal is that Intel has been developing a new back-end compiler for their OpenGL/Vulkan Linux drivers based upon their experiences so far with their NIR support and the less learned over the past number of years...

    http://www.phoronix.com/scan.php?pag...C-New-Back-End

  • #2
    So now we have:
    - Intel classic (NIR)
    - Intel Iris (Gallium3D -> NIR)
    - Intel Iris (Gallium3D -> IBC)

    How many more different code paths are left to write?
    Last edited by tildearrow; 10-03-2019, 11:57 PM.

    Comment


    • #3
      Originally posted by tildearrow View Post
      So now we have:
      - Intel classic (NIR)
      - Intel Iris (Gallium3D and then it somehow transforms into NIR)
      - IBC

      How many more different code paths are left to write?
      Forty-six and two

      Comment


      • #4
        Originally posted by skeevy420 View Post

        Forty-six and two
        just a head of me? <3 Tool!

        Comment


        • #5
          Originally posted by tildearrow View Post
          So now we have:
          - Intel classic (NIR)
          - Intel Iris (Gallium3D and then it somehow transforms into NIR)
          - IBC

          How many more different code paths are left to write?
          Lots, until they get it right

          Comment


          • #6
            I think you are mixing up a few things.

            Classic vs. Gallium is about the driver model. It's how OpenGL or DX API calls translate into hardware state and GPU commands that perform drawing. The driver model is about binding resources, setting up (e.g.) blending modes, supplying vertex data, and telling the GPU to draw polygons.

            Then there are shaders. Vertex shaders calculate the position the corners of your polygons. Pixel shaders calculate the color of each pixel in a polygon. These are written in programming languages like GLSL, HLSL, or SPIR-V (instead of C++, Java, or Python). The compiler is what takes these source languages and translates them into assembly code that can run on your GPU's shader processors (which are like another CPU, but instead of a 4-core x86 or ARM, they're like a several thousand core processor with a unique ISA). Typically this means turning a variety of source languages into a common intermediate form, performing architecture-independent optimizations, then passing it to a "backend" which does architecture-specific optimizations, instruction scheduling, register allocation, and produces actual assembly code.

            Gallium is our driver model. NIR is our shader intermediate form and optimizer; it's largely architecture-independent. (Intel, AMD, Broadcom, freedreno, and panfrost all use it.) IBC is the Intel backend compiler which turns NIR into Intel GPU assembly (and aims to replace our old one we started in 2011). The backend is one tiny piece of the system.

            The driver and compiler are largely orthogonal. You need one of each, and they need to work together, but they largely handle different aspects and you can replace them. For example, you can swap Radeon's LLVM system out with ACO. But radeonsi remains largely the same.

            And yes, we're going to keep improving things and replacing pieces with better ones. Graphics keeps changing, and what worked in 2011 may not cut it for today's games. Compiler theory is a huge research area in computer science and projects need to keep adapting. You even see new IRs introduced in GCC from time to time.

            That's way oversimplified but hopefully it helps people understand things a bit better.
            Free Software Developer .:. Mesa and Xorg
            Opinions expressed in these forum posts are my own.

            Comment


            • #7
              Maybe off topic, but the fonts in this picture look really ugly to me...

              Comment


              • #8
                Originally posted by skeevy420 View Post

                Forty-six and two
                What does this mean? 46/2?
                I'm talking about how many drivers.

                Comment


                • #9
                  Originally posted by zxy_thf View Post
                  Maybe off topic, but the fonts in this picture look really ugly to me...
                  I agree. What did they use to create that slide?
                  The char positions seem to be aligned by rounding.

                  (DejaVu Sans is worse though)

                  Comment


                  • #10
                    Originally posted by Kayden View Post
                    I think you are mixing up a few things.

                    Classic vs. Gallium is about the driver model. It's how OpenGL or DX API calls translate into hardware state and GPU commands that perform drawing. The driver model is about binding resources, setting up (e.g.) blending modes, supplying vertex data, and telling the GPU to draw polygons.

                    Then there are shaders. Vertex shaders calculate the position the corners of your polygons. Pixel shaders calculate the color of each pixel in a polygon. These are written in programming languages like GLSL, HLSL, or SPIR-V (instead of C++, Java, or Python). The compiler is what takes these source languages and translates them into assembly code that can run on your GPU's shader processors (which are like another CPU, but instead of a 4-core x86 or ARM, they're like a several thousand core processor with a unique ISA). Typically this means turning a variety of source languages into a common intermediate form, performing architecture-independent optimizations, then passing it to a "backend" which does architecture-specific optimizations, instruction scheduling, register allocation, and produces actual assembly code.

                    Gallium is our driver model. NIR is our shader intermediate form and optimizer; it's largely architecture-independent. (Intel, AMD, Broadcom, freedreno, and panfrost all use it.) IBC is the Intel backend compiler which turns NIR into Intel GPU assembly (and aims to replace our old one we started in 2011). The backend is one tiny piece of the system.

                    The driver and compiler are largely orthogonal. You need one of each, and they need to work together, but they largely handle different aspects and you can replace them. For example, you can swap Radeon's LLVM system out with ACO. But radeonsi remains largely the same.

                    And yes, we're going to keep improving things and replacing pieces with better ones. Graphics keeps changing, and what worked in 2011 may not cut it for today's games. Compiler theory is a huge research area in computer science and projects need to keep adapting. You even see new IRs introduced in GCC from time to time.

                    That's way oversimplified but hopefully it helps people understand things a bit better.
                    Thank you for the explanation. I have clarified my post.

                    Comment

                    Working...
                    X