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

21–30 of 55 posts

Re: Let's Fix OpenGL [pdf]

#21

Post by withjive »

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 language like C difficult.

I think you need to familiar yourself with some shader programming at least, before you critique the author's domain.

Re: Let's Fix OpenGL [pdf]

#22

Post by nice_byte »

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. Unless a corresponding change is proposed at the level of shader bytecode (SPIR-V), which probably leads to opening a can of worms.

Re: Let's Fix OpenGL [pdf]

#23

Post by nice_byte »

While I agree with the points about type safety with uniforms/attributes, I've found that this class of bugs didn't happen to me all that often in practice. The bug that happens way more often is calculations in the wrong coordinate system (or using two values in different coordinate systems in the same calculation), which the author also points out.

Re: Let's Fix OpenGL [pdf]

#24

Post by nice_byte »

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

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

Re: Let's Fix OpenGL [pdf]

#25

Post by 33a »

This author seems pretty clueless about how things actually work and a lot of the assumptions are just plain wrong. For example, ubershaders are preferred instead of many small shaders because the overhead of switching shaders and recompiling them is expensive. It is not something that people build because it is convenient (rather it is quite the opposite!) and then specialize with fixed parameters.

Re: Let's Fix OpenGL [pdf]

#26

Post by greggman »

rwbt wrote: post #20
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…

> 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 is C++ there are a ton of things I'd expect to be able to do that I'm pretty sure don't translate to GPUs

maybe I want to declare a local static array and modify it. maybe I want to create static arrays of colors and search for the closest match. 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

Re: Let's Fix OpenGL [pdf]

#27

Post by cmrx64 »

nhaehnle wrote: post #13
cmrx64 wrote: post #5

Earlier quoted context omitted.

https://people.freedesktop.org/~nh/piglit/ is an extensive open conformance test suite for opengl. Khronos has their own ( https://github.com/KhronosGroup/VK-GL-CTS , used to be proprietary), but judging by the amount of bugs and piglit failures in drivers which supposedly pass it, I think it's probably not very useful.

Be aware that the open-source GL tests in vk-gl-cts still contain quite a lot of bugs from porting from the old framework that was used in proprietary test suite releases. Piglit isn't really a conformance test suite. It is a test suite, is usually extended when people add new features to Mesa, and collects regression tests over time. However, it actually started out in part as a way to modify glean tests that driver…

Fair enough, and good to hear from you :) piglit made my life better when I was doing mesa work.

Re: Let's Fix OpenGL [pdf]

#28

Post by dom0 »

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?

Re: Let's Fix OpenGL [pdf]

#29

Post by klodolph »

nice_byte wrote: post #24
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,…

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?

Re: Let's Fix OpenGL [pdf]

#30

Post by vvanders »

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.

Which already exists called SPIR-V.
Post reply on HN