Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ARB_gl_spirv implementation in Mesa: status update (XDC 2018)


Published on

By Alejandro Piñeiro.

Since OpenGL 2.0, released more than 10 years ago, OpenGL has been using OpenGL Shading Language (GLSL) as a shading language. When Khronos published the first release of Vulkan, almost 2 years ago, shaders used a binary format, called SPIR-V, originally developed for use with OpenCL.

That means that the two major public 3D graphics API were using different shading languages, making porting from one to the other more complicated. Since then there were efforts to allow making this easier.

On July 2016, the extension ARB_gl_spirv was approved by Khronos, that allows a SPIR-V module to be specified as containing a programmable shader stage, rather than using GLSL, whatever the source language was used to create the SPIR-V module. This extension is now part of OpenGL 4.6 core, making it mandatory for any driver that wants to support this version.

The implementation of this extension for the Mesa driver, focused on the i965 intel driver, was started at the end of 2017. A first talk about the status of such implementation was done this year on FOSDEM. This talk on XDC would present all the updates, and in general it will explain the extension, what advantages provides, how is being implemented for the Mesa driver, and how much is pending to get it enabled.

X.Org Developer's Conference (XDC) 2018
26th, 27th and 28th of September
A Coruña, Spain

Published in: Technology
  • Be the first to comment

  • Be the first to like this

ARB_gl_spirv implementation in Mesa: status update (XDC 2018)

  1. 1. static void _f_do_barnacle_install_properties(GObjectClass *gobject_class) { GParamSpec *pspec; /* Party code attribute */ pspec = g_param_spec_uint64 (F_DO_BARNACLE_CODE, "Barnacle code.", "Barnacle code", 0, G_MAXUINT64, G_MAXUINT64 /* default value */, G_PARAM_READABLE | G_PARAM_WRITABLE | G_PARAM_PRIVATE); g_object_class_install_property (gobject_class, F_DO_BARNACLE_PROP_CODE, ARB_gl_spirv implementation on Mesa: status update
  2. 2. Introduction
  3. 3. Topics ● What we are talking about: some specs ● Previous presentation, status then ● Evolution ● Testing ● Current status, future
  4. 4. GLSL ● OpenGL Shading Language. ● C-Like high-level language shading language ● ARB_vertex/fragment_program too low level. Several vendor alternatives. ● Introduced as an OpenGL 1.4 extension on 2003, part of the OpenGL 2.0 core on 2002 ● The original shader is included on your program.
  5. 5. SPIR-V ● Introduced as SPIR in 2011 ● Standard Portable Intermediate Representation ● Initially for OpenCL ● Binary format based on LLVM IR ● SPIR-V announced in 2015 ● Part of OpenCL 2.1 core and Vulkan core ● Not based on LLVM IR anymore
  6. 6. OpenGL and Vulkan: common ecosystem ● Some applications are porting from one to the other, or want to support both ● Some interoperability are desired ● But one use GLSL, other SPIR-V as shading language ● Fist step: GL_KHR_vulkan_glsl
  7. 7. GL_KHR_vulkan_glsl ● Modifies GLSL to be used for Vulkan ● Announced on Dec 2015 ● GLSL is compiled down to SPIR-V, which the Vulkan API consumes ● Not a driver extension, but frontend one. ● Removes several features, add others ● “Just GLSL” is not suitable for Vulkan consumption
  8. 8. GL_ARB_gl_spirv ● Allow SPIR-V modules to be loaded on OpenGL ● Modifies GLSL to be a source for creating SPIR-V modules for OpenGL consumption ● Based on the previous, but not exactly the same ● Also adds/removes features ● Driver + frontend extension ● “Just GLSL” (through SPIR-V) not suitable for OpenGL consumption either.
  9. 9. Previous presentation: FOSDEM 2018
  10. 10. FOSDEM status summary (I) ● Mesa already has a way to handle SPIR-V shaders, thanks to Vulkan ● SPIR-V to NIR pass ● NIR is one of the Intermediate Representations used at Mesa (IR, NIR, TGSI, etc) ● Problem: shader linking was based on IR
  11. 11. FOSDEM status summary (II) ● First workaround: partial conversion to IR ● “Shadow variables” ● Good for bootstrap, discarded soon ● First proof-of-concept was implemented, good enough to pass all the CTS tests ● Cleaned up version of this implementation was used on a downstream version of the Intel driver to pass the conformance ● Challenge: was decided a new linker for ARB_gl_spirv, based on NIR
  12. 12. FOSDEM status summary (III) ● Main reason: ARB_gl_spirv linking needs to work without names ● But current GLSL, so it’s linker, is based on names /* This hash table will track all of the uniform blocks that have been * encountered. Since blocks with the same block-name must be the same, * the hash is organized by block-name. */
  13. 13. Evolution: FAQ mode
  14. 14. The NIR linker is needing a lot of time, do you regret starting it? ● No.
  15. 15. The NIR linker is needing a lot of time, do you regret starting it? ● No. ● During this time even more difference between the GLSL linker and what an ARB_gl_spirv linker needs were found ● Specifically, even although the general rule is trying to behave as similar as possible as OpenGL, some things are done “in the Vulkan way”
  16. 16. Why not just extend the shadow variables idea? NIR to IR pass? ● We would still have the problem of not having a name ● GLSL linking rules, specially validations, are mostly based on names ● Bold statement: even if we had a SPIR-V to IR pass, separate code/linking for ARB_gl_spirv would make sense.
  17. 17. Why not just make-up a name and go with the IR linking? ● How do you make up the name? ● Sometimes you would need the binding, other the location, offset, etc ● You would mean the semantics of what you are using for linking at a given moment ● The spec itself encourages to “link the vulkan- way”: built-in decorations, locations, etc ● “Make-up a name” is not only hacky, sounds hacky too
  18. 18. Why a NIR linker so tailored to ARB_gl_spirv, why not for both? ● Again, GLSL linking are mostly based on the ubo/uniforms/etc names ● Initial stages tried to design a solution for both, and also share as much code as possible for existing linker. ● Outcome: block ● We still think that the differences on the spec justifies a different linker ● Still trying to share as much as possible
  19. 19. But why it is taking so long? Isn't SPIR-V more straight-forward? ● In the end, it is needed to feed up the same internal structures that with a GLSL linker ● Uniforms need to be enumerated from their block, among other things, to know how many we have ● Ditto for info related to them, like ubo/ssbo buffer size
  20. 20. Wait there! Number of uniforms? Buffer sizes? I thought that SPIRV din’t require introspection? ● That’s not inherent to SPIR-V ● It is just how Vulkan uses it, or requires from it
  21. 21. Wait, I have read the spec, I found several “no reflection required”. ● Yes, issue (8) says “First start without reflection” ● And then issue (12) says “No reflection required”
  22. 22. Wait, I have read the spec, I found several “no reflection required”. ● Yes, issue (8) says “First start without reflection” ● And then issue (12) says “No reflection required” ● But on those, it refers to “name reflection APIs”, not any introspection at all (yes can be confusing)
  23. 23. Wait, I have read the spec, I found several “no reflection required”. ● Yes, issue (8) says “First start without reflection” ● And then issue (12) says “No reflection required” ● But on those, it refers to “name reflection APIs”, not any introspection at all (yes can be confusing) ● From issue (19): “C) Allow as much as possible to work "naturally". You can query for the number of active resources, and for details about them. Anything that doesn't query by name will work as expected."
  24. 24. So this linker needs to re- implement all what GLSL does? ● No. The scope is really smaller. ● Mesa GLSL linker need to support different versions of GLSL, with several rules/features added for years. ● We can assume that the SPIR-V module has been validated. Undefined behaviour allowed for wrong SPIR-V ● Several features were removed, or become simpler (example: no specific memory layouts)
  25. 25. Testing
  26. 26. Testing ● Passing CTS is not enough to be considered production ready ● Were good to test the ARB_gl_spirv specifics, shallow for testing the full range of features allowed ● We use extensively Piglit
  27. 27. Piglit ● Open-source test suite for OpenGL implementations ● Heavily used by Mesa developers ● Several of their tests uses shader_runner ● Individual test uses a text format ● This includes the shader source, data values and expected values
  28. 28. shader_test example [require] GL >= 3.3 GLSL >= 4.50 [vertex shader passthrough] [fragment shader] #version 450 layout(location = 0) uniform vec4 color; layout(location = 0) out vec4 outcolor; void main() { outcolor = color; } [test] clear color 1.0 0.0 0.0 0.0 clear #color uniform vec4 0 0.0 1.0 0.0 1.0 verify program_query GL_ACTIVE_UNIFORMS 1 draw rect -1 -1 2 2 probe all rgba 0.0 1.0 0.0 1.0
  29. 29. Piglit (barebone tests) ● Nicolai added support for ARB_gl_spirv on shader_runner ● Also added a script that parses the shader_test, and call glslang to create the SPIR-V source ● This allowed to add tests for the extension ● We are adding them as we implement features, but even more is needed
  30. 30. Piglit (borrowed tests) ● The script tries to be able to reuse tests written originally for other specs ● In some cases, it does some fixing ● Like setting explicit location/binding etc ● Also automatic filtering of tests that are not compatible with ARB_gl_spirv ● We got a lot of tests this way. Allowed a test- based implementation since basically day 0.
  31. 31. Piglit (conversion numbers) ● From the 2174 hand-written tests: ● 926 skipped, 24 fail ● 1224 tests successfully generated ● From the 32386 generated tests: ● 1775 skipped ● 30611 tests successfully generated ● We got 31835 tests with SPIR-V shaders just borrowing tests from other specs
  32. 32. Piglit (pass rate) ● With our development branch: ● [34561] skip: 5928, pass:28508, fail:114, crash: 11 ● Most crashes come from lack of multi- dimensional ubo/ssbo ● Most failures come from missing more validation checks ● Several of them are likely to be skipped
  33. 33. Current status
  34. 34. What we already have on master? ● ~80 Mesa patches, and ~30 patches are already on their respective masters ● Thanks to all reviewers, specially Timothy Arceri and Jason Ekstrand ● Those cover ● Uniforms ● Atomic counters ● Transform feedback and geometry streams ● 64-bit and 64-bit vertex attribute ● etc
  35. 35. What’s happening now? ● Just this week we send a 26 patches series with the ubo/ssbo support, and some extras ● Minus multi-dimensional arrays ● Those extras are mostly in order to get all the ARB_gl_spirv CTS tests passing
  36. 36. What’s next? (mandatory) ● Improve interface query support ● A lot of work done on testing ● Multidimensional ubo/ssbo ● Validation ● Enable extension
  37. 37. What’s next? (long term) ● Shader cache support ● Right now we disable on the ARB_gl_spirv path ● Bring names if available ● Test with real applications
  38. 38. Personal thoughts
  39. 39. Two worlds ● The best of two worlds ● SPIR-V on OpenGL! ● But you can still use as much OpenGL API as possible! ●
  40. 40. Two worlds ● The best of two worlds ● SPIR-V on OpenGL! ● But you can still use as much OpenGL API as possible! ● The worst of two worlds: ● OpenGL driver need to do more linking with SPIR-V that the Vulkan driver ● Just to provide a subset of the OpenGL introspection
  41. 41. Shouldn’t it better to chose one? ● Depends on the main use case ● Transitional helper while people port to Vulkan? Or a way to help to reduce the cost of having two renderers? ● On the former, “OpenGL way of things” make more sense ● On the latter, “Vulkan way of things” make more sense
  42. 42. GLSL confusion ● Two different specs defining the GLSL valid for SPIR-V generation ● Too many feature switching/tweaking ● Although it is most a frontend problem, in the end the driver needs to support a set of features ● Sometimes not so clear what is needed to be supported ● Likely a issue for applications too
  43. 43. Closing
  44. 44. Who is working on this? ● Started by Nicolai Hänhle ● Continued by Igalia ● Supported by Intel
  45. 45. Questions?