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

[phoronix]

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?page=news_item&px=Intel-IBC-New-Back-End

[tildearrow]

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?

[skeevy420]

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

[boxie]

Forty-six and two

just a head of me? <3 Tool!

[boxie]

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

[Kayden]

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.

[zxy_thf]

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

[tildearrow]

Forty-six and two

What does this mean? 46/2?
I'm talking about how many drivers.

[tildearrow]

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)

[tildearrow]

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.