The Open-Source Intel Vulkan Linux Driver's Anatomy

[phoronix]

Phoronix: The Open-Source Intel Vulkan Linux Driver's Anatomy

Intel Open-Source Technology Center developer Jason Ekstrand presented earlier today at XDC2016 with a presentation entitled "The Anatomy of a Vulkan Driver" where he covers how he and fellow Intel developers brought up the first open-source Vulkan driver and had it ready for launch-day when Khronos formally unveiled the specification earlier this year...

http://www.phoronix.com/scan.php?page=news_item&px=XDC2016-Intel-Vulkan

[shmerl]

Would it be better performance wise in the future to avoid translating SPIR-V into NIR as an intermediate step?

[Masush5]

Would it be better performance wise in the future to avoid translating SPIR-V into NIR as an intermediate step?

As far as i understand converting SPIR-V to NIR (or other IRs) can actually benefit performance, because NIR allows for optimization passes which can't (easily) be done in SPIR-V.
So IR conversion might make compilation take longer, but generate faster code.

[haagch]

I haven't watched it, so, does he talk about completeness? Still lacking tessellation shader support, Gen7, etc?

[Kayden]

Would it be better performance wise in the future to avoid translating SPIR-V into NIR as an intermediate step?

Nope. SPIR-V is an interchange format, it's not intended for optimization. NIR is well suited for optimization. That's what we designed it for.

Don't confuse runtime performance (higher FPS) with compiler speed (shorter load times). Generating more optimal code increases FPS. Making the compiler faster does not.

Plus, in Vulkan, shaders are included in the pipeline cache, so you only pay the compiler cost once anyway...

[geearf]

Don't confuse runtime performance (higher FPS) with compiler speed (shorter load times).

Isn't that only true for games that compile shaders during loading?

[mczak]

Isn't that only true for games that compile shaders during loading?

Of course if the game compiles new shaders during actual play these still need cpu time to compile - there's still benefits to faster compilers. But since it's all rather explicit and completely separate from any rendering it can easily be done in the background in another thread (apps should avoid immediately using pipeline objects) - unlike in GL the driver doesn't have to guess what the render state used together with a shader is going to be...
Besides though, in general transformations to other representations tend to be cheap compared to the cost paid for optimization.

[geearf]

Of course if the game compiles new shaders during actual play these still need cpu time to compile - there's still benefits to faster compilers. But since it's all rather explicit and completely separate from any rendering it can easily be done in the background in another thread (apps should avoid immediately using pipeline objects) - unlike in GL the driver doesn't have to guess what the render state used together with a shader is going to be...
Besides though, in general transformations to other representations tend to be cheap compared to the cost paid for optimization.

Thank you for the explanation!

[andrei_me]

Is the slides available now?