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

41–50 of 55 posts

Re: Let's Fix OpenGL [pdf]

#41

Post by Recurecur »

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"

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

Re: Let's Fix OpenGL [pdf]

#42

Post by jwatte »

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…

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!

Re: Let's Fix OpenGL [pdf]

#43

Post by jwatte »

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

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

Re: Let's Fix OpenGL [pdf]

#44

Post by jonathanyc »

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…

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.

Re: Let's Fix OpenGL [pdf]

#45

Post by yeukhon »

vvanders wrote: post #33

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…

Safety checks can have performance penality but that isn't necessarily impossible to optimize. Perhaps a new language is required? Can't we have a langauage for GPU with the same promises Rust can solve above C and C++?

Re: Let's Fix OpenGL [pdf]

#46

Post by anderspitman »

As someone who recently start learning to program GPUs, I enjoyed this read. I particularly find the concept of a linear algebra-aware type system compelling. I love the idea of the type system statically checking that I'm performing operation in and between correct vector spaces. Is the fact that Vulkan uses SPIR-V sufficient to support creation of languages to allow this to be implemented?

Re: Let's Fix OpenGL [pdf]

#47

Post by nighthawk454 »

John Carmack weighed in on Twitter:

> ...some interesting thoughts, but the shading language is the least broken part of OpenGL.

> Lots of people consider automating the computation rate determination between fragment and vertex shaders, but it is a terrible idea.

https://twitter.com/ID_AA_Carmack/status/851258064909070336

Re: Let's Fix OpenGL [pdf]

#48

Post by johncolanduoni »

anderspitman wrote: post #46

As someone who recently start learning to program GPUs, I enjoyed this read. I particularly find the concept of a linear algebra-aware type system compelling. I love the idea of the type system statically checking that I'm performing operation in and between correct vector spaces. Is the fact that Vulkan uses SPIR-V sufficient to support creation of languages to allow this to be implemented?

If all you want is more static checking, it doesn't much matter if the graphics API consumes GLSL or SPIR-V. SPIR-V is mostly about factoring out part of the optimization phase from the driver to the compilation process. This speeds up the process of loading a shader, and more importantly lets developers control aspects of optimization they couldn't before.

Re: Let's Fix OpenGL [pdf]

#49

Post by fulafel »

vvanders wrote: post #33

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…

If performance was valued above all else in a narrow sense, OpenGL would not be used and people would program GPUs natively.

In a wide sense that includes programmer productivity and end product robustness in the equation, well, safety checks sell themselves.

Bounds checking is very cheap on CPUs, but even more so on GPUs because GPUs are more rarely bottlenecked on simple local arithmetic.

Re: Let's Fix OpenGL [pdf]

#50

Post by fulafel »

vvanders wrote: post #33

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…

If performance was valued above all else in a narrow sense, OpenGL would not be used and people would program GPUs natively.

In a wide sense that includes programmer productivity and end product robustness in the equation, well, safety checks sell themselves.

Post reply on HN