[shurcooL]

> 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.

[flohofwoe]

Apple'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-spe...

Microsoft's HLSL is now also based on LLVM:

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

So things are converging, may be one day GPU extensions will end up in the C++ standard ;)

[nicwilson]

Sadly 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) 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.)

[nice_byte]

This 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]

You mean the GL_SHADER_BINARY_FORMAT_SPIR_V_ARB format, which is part of the GL_ARB_gl_spirv extension?

[nice_byte]

Huh, I didn't know that extension existed! :)

[tarpherder]

A nice illustration of half the issues with OpenGL.

[theparanoid]

Shaders are SIMT (single instruction multiple threads).

[jwatte]

The abstraction and data layout cost penalties are extremely different in a GPU than on a general purpose CPU.

[erikj]

I wonder how such properly-designed extensions would look like in Common Lisp or any other language with similar metaprogramming capabilities.