5 ms·
> Potential solutions. Shader languages’ needs are not distinct enough from ordinary imperative programming languages to warrant ground-up domain-specific desig
by shurcooL 10y ago
> Potential solutions. Shader languages’ needs are not distinct enough from ordinary imperative
programming languages to warrant ground-up domain-specific designs. They should
should instead be implemented as extensions to general-purpose programming languages.
There is a rich literature on language extensibility [27, 36, 39] that could let implementations
add shader-specific functionality, such as vector operations, to ordinary languages.
I like this part.
- erikj 10y agoI wonder how such properly-designed extensions would look like in Common Lisp or any other language with similar metaprogramming capabilities.
- flohofwoe 10y agoApple's Metal shader language is C++14 with some restrictions, and extensions (such as native matrix and vector types), implemented with LLVM: https://developer.apple.com/metal/metal-shading-language-specification.pdf https://developer.apple.com/metal/metal-shading-language-spe... Microsoft's HLSL is now also based on LLVM: https://blogs.msdn.microsoft.com/directx/2017/01/23/new-directx-shader-compiler-based-on-clangllvm-now-available-as-open-source/ https://blogs.msdn.microsoft.com/directx/2017/01/23/new-dire... Khronos has an LLVM-based translator between LLVM bitcode and SPIR-V: https://github.com/KhronosGroup/SPIRV-LLVM https://github.com/KhronosGroup/SPIRV-LLVM So things are converging, may be one day GPU extensions will end up in the C++ standard ;)
- nicwilson 10y agoSadly Khronos' LLVM only supports OpenCL i.e. compute SPIRV code generation, is rather old (3.6.1) and is nowhere near in shape enough to be upstreamed, and MS's in only slightly newer at 3.7, the the repo also contains a custom clang and so would require some git surgery to get it upstream once stable. Apple's metal I don't think is even open source. However I have a an up to date fork of LLVM 5 (https://github.com/thewilsonator/llvm https://github.com/thewilsonator/llvm) that has Khronos' changes cleaned up a bit, i.e. the spirv triples are actually targets, but once I make the SPIRV OpenCL extension operations proper LLVM intrinsics instead of mangled C++ (and delete all the associated mangling code) then there is no reason that can't go upstream. I don't think SPIRV graphics support will be all that difficult to add once the intrinsics nonsense is fixed. > So things are converging, may be one day GPU extensions will end up in the C++ standard ;) Not before D gets them ;) (Shameless plug: I will be speaking at DConf about this.)
- theparanoid 10y agoShaders are SIMT (single instruction multiple threads).
- nice_byte 10y agoThis part is kind of addressed by having things like SPIR-V - shaders are defined with "bytecode", which itself is produced by a separate compiler. This makes things easier for language designers and driver developers. I don't see a reason why same approach couldn't be implemented in OpenGL. In fact, it would be awesome to have a GL extension for SPIR-V that just adds a corresponding "spirv" bninary format to glShaderBinary
- klodolph 10y agoYou mean the GL_SHADER_BINARY_FORMAT_SPIR_V_ARB format, which is part of the GL_ARB_gl_spirv extension?
- nice_byte 10y agoHuh, I didn't know that extension existed! :)
- tarpherder 10y agoA nice illustration of half the issues with OpenGL.
- jwatte 10y agoThe abstraction and data layout cost penalties are extremely different in a GPU than on a general purpose CPU.