Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's Fix OpenGL [pdf]

cs.cornell.edu

Post reply on HN
Print view View original

31–40 of 55 posts

Re: Let's Fix OpenGL [pdf]

#31

Post by nice_byte »

klodolph wrote: post #29
nice_byte wrote: post #24

Earlier quoted context omitted.

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 glShade…

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

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

Re: Let's Fix OpenGL [pdf]

#32

Post by rwbt »

greggman wrote: post #26
rwbt wrote: post #20

Earlier quoted context omitted.

> He seems to just hand-wave and says "well just use C you idiots". He criticizes Metal for using a version of C++14 that doesn't allow recursion, but offers no alternate solutions I don't think the author suggested anything like that. He recommended using C with some extensions, so it would be easy to write shaders in many different languages. Also, he criticized the poor implementation of Metal's shading language w…

it most definitely is still that case. plenty of GPUs can not run plain C. looking at the metal language I'm not sure I'd personally call that C++ given all the restrictions https://developer.apple.com/metal/metal-shading-language-spe... I'd be curious if you can create static arrays, strings or static strings, do string compares etc. not that I'd want to do any of that on a GPU but rather if you tell me the language…

> I feel like having a more common language would just lead people to bang their heads against the impossible or implement horribly inefficient algos not really understanding what's going on under the hood

Good point.

Re: Let's Fix OpenGL [pdf]

#33

Post by vvanders »

As someone who's a fan of PL languages(and spends a fair amount of time in the GPU space) I'm not sure I buy many of the arguments.

The reason that GPU drivers/APIs have few safety checks is that in graphics code, performance is valued above all else. Even simple calls can introduce overhead that's undesirable when you're making thousands of the same type of calls.

His example of baked shaders doesn't really seem to hold much value since interactive shader builders(ShaderToy, UE3/4, etc) are all content driven anyway so the extra code generation isn't a limiting constraint.

Nice effort but I don't see it solving actual pain points in production.

Re: Let's Fix OpenGL [pdf]

#34

Post by slavik81 »

dom0 wrote: post #28
HugoDaniel wrote: post #11

I find it hard to test opengl. That would be my first approach to fix it: provide a good way to debug and test the compiled programs.

Eh, you can already debug kernels on a line-stepping level. What exactly do you need more?

That sounds pretty awesome to me. What tool should I be using to do that for Intel Haswell on Linux?

Re: Let's Fix OpenGL [pdf]

#35

Post by AlphaSite »

nice_byte wrote: post #22

I don't think I fully understand the point about metaprogramming facilities. Sure, it would be nice to have compile-time ifs that get eliminated from the generated code if the condition isn't met. But I don't think this necessarily solves the problem of "combinatoric explosion" of different shader variants - you still have to generate a separate chunk of code for each possible combination of compile-time conditions.…

Im fairly certain shaders can and do eliminate compile time if statements, you can observer this by seeing which uniforms are defined (for example in WebGL).

Re: Let's Fix OpenGL [pdf]

#36

Post by AlphaSite »

withjive wrote: post #21
geokon wrote: post #14

I'm not an OpenGL expert or anything, but I get the impression the author doesn't really know what he's talking about and sounds a bit amateurish (I'm a bit hesitant to say that given it's a professor at Cornell..) He seems to just hand-wave and says "well just use C you idiots". He criticizes Metal for using a version of C++14 that doesn't allow recursion, but offers no alternate solutions The reason GLSL isn't C is…

> The reason GLSL isn't C is because you can't do everything C does on a low end cellphone GPU - so obviously you have to restrict the language. GLSL limitations has nothing to do with lowend devices and performance (which now is becoming irrelevant compared to desktops). But rather GLSL is executed on the GPU— typically across many stream processors— this type of parallelization makes using a general purpose languag…

As I understand it, GPU ISAs expose all of the functionality required to implement arbitrary programs, but the actual shaders compilers don't use it, due to performance concerns.

Re: Let's Fix OpenGL [pdf]

#37

Post by AlphaSite »

noelwelsh wrote: post #19
geokon wrote: post #14

I'm not an OpenGL expert or anything, but I get the impression the author doesn't really know what he's talking about and sounds a bit amateurish (I'm a bit hesitant to say that given it's a professor at Cornell..) He seems to just hand-wave and says "well just use C you idiots". He criticizes Metal for using a version of C++14 that doesn't allow recursion, but offers no alternate solutions The reason GLSL isn't C is…

I think you've misunderstood the author's position. I don't think he's arguing for C at all. Reading between the lines the author is arguing language agnostic APIs, which would allow modern languages to be used to write GPU code.

So SPIR-V or generating code for each ISA directly?

Re: Let's Fix OpenGL [pdf]

#38

Post by nicwilson »

flohofwoe wrote: post #10
shurcooL wrote: post #4

> 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,…

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/SPI…

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

Re: Let's Fix OpenGL [pdf]

#39

Post by nice_byte »

AlphaSite wrote: post #35
nice_byte wrote: post #22

I don't think I fully understand the point about metaprogramming facilities. Sure, it would be nice to have compile-time ifs that get eliminated from the generated code if the condition isn't met. But I don't think this necessarily solves the problem of "combinatoric explosion" of different shader variants - you still have to generate a separate chunk of code for each possible combination of compile-time conditions.…

Im fairly certain shaders can and do eliminate compile time if statements, you can observer this by seeing which uniforms are defined (for example in WebGL).

You mean if we write

if (some_constant_expression) { //...code... }

and some_constant_expression evaluates to false, the entire code block will be stripped from the result?

That may be true, but it's not standardized behavior, is it?

Re: Let's Fix OpenGL [pdf]

#40

Post by JoeAltmaier »

nice_byte wrote: post #39
AlphaSite wrote: post #35

Earlier quoted context omitted.

Im fairly certain shaders can and do eliminate compile time if statements, you can observer this by seeing which uniforms are defined (for example in WebGL).

You mean if we write if (some_constant_expression) { //...code... } and some_constant_expression evaluates to false, the entire code block will be stripped from the result? That may be true, but it's not standardized behavior, is it?

True for many compilers for many years. Its a way to integrate 'conditional compilation' into the normal program flow. It can make the code easier (or harder) to read. Use judiciously.
Post reply on HN