Hacker News Reader

Comment by geokon | Hacker News Reader

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 because you can't do everything C does on a low end cellphone GPU - so obviously you have to restrict the language. The "cognitive load" of knowing the restrictions is overblown but also unavoidable.

SPIRV isn't even mentioned. DSL's are dismissed.

I didn't really follow what he didn't like about the preset input/output variables that are predefined in the different shaders. It's a bit ugly.. but that's also pretty much a non issue.

View on HN

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

I think he is familiar. The "you can't do" comment really means "you can't do with good performance." Typical C code would not run fast on a GPU. Indirect data (pointer chasing) has /extreme/ latency penalty!

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.

This is the author's position: "This essay introduces OpenGL and its pitfalls for the PL-minded reader and advocates for more research that applies language ideas to this underserved domain. "

> He criticizes Metal for using a version of C++14 that doesn't allow recursion, but offers no alternate solutions

No, he criticizes GLSL and HLSL for extending C or C++ in an ad-hoc way which make them buggy and unreliable (myriad of small differences between implementations).

"The need for ad hoc language extension also complicates compiler implementations: current compilers either need to reinvent a complete C-like parser and compiler from scratch [28] or hack an existing frontend such as GCC or Clang. Both approaches are error prone: [...]"

Someone being a professor doesn't correspond with them necessarily being a good engineer or expert on an engineering subject. Indeed, as people have limited time to spend on things they are interested in, satisfying the criterion for becoming a professor seems to often mean that you would not satisfy the criterion for being a good engineer -- time that you could have spent getting your hands dirty or gaining experience was spent doing other things, like writing papers on very specific subjects.

This is just my observation after dealing with people in academia and industry, however, so my words should be taken with a huge amount of salt. I think it's unfortunate that it's in PL where this divide tends to be most harmful.

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.

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

> 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 which requires a custom fork of Clang (which is apparently buggy), not necessarily the choice of using C++14.

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

That may be true in the early days of OpenGL, but now that's probably no longer the case.

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

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

I completely disagree. The author is not really arguing for a "more common language" anyhow - he's arguing for a GPU language that avoids many of the inefficiencies and semantic problems with the current approach. To boot, he's arguing for an approach that allows better static error checking, which it's hard to argue against.

I have to say it's sad that Apple went with Metal rather than working to evolve Vulkan as an excellent standard. We'll see how that works out in the long run...

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

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

Yes, but why create another language that looks like C but behaves subtly differently? Could the compiler not simply reject usage of C features which are problematic for GPUs?

Reply on news.ycombinator.com