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

51–55 of 55 posts

Re: Let's Fix OpenGL [pdf]

#51

Post by zvrba »

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…

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: [...]"

Re: Let's Fix OpenGL [pdf]

#52

Post by pandaman »

fulafel wrote: post #49
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.

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

People do program GPU natively on game consoles. However, with so many GPUs in use (at least three major manufacturers each with multiple architectures just for desktop) it's impractical to write native graphics code. It's exactly the same concern as people have for CPU programming - it would be the best to write ISA code but given the variety of available CPUs the C/C++ is the best compromise between performance and usability. All attempts to push "better" language with forced run-time costs have failed to displace it.

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

Good news. GPUs do bounds checking in hardware already. The errors people want OpenGL to find are not about out-of-bounds but mostly of "I want to draw this but instead it's drawing that, what to do?" kind, caused by the complex state and its dynamic nature.

Re: Let's Fix OpenGL [pdf]

#53

Post by dom0 »

slavik81 wrote: post #34
dom0 wrote: post #28

Earlier quoted context omitted.

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?

CodeXL can do that (at least on Windows)

I think VTune can do OpenCL analyses, I don't know whether it has any graphics debugging capability (quite a lot of features are Windows-only or annoying to set up on Linux [because who needs a kernel with a stable ABI?], including managed analyses [1] :(

The simple truth here is that most development happens on Windows and thus most development tools are developed for Windows. This is almost universally true, with some notable exceptions (e.g. Valgrind can be a killer app; nodejs is so unportable that it requires a new Windows subsystem to run).

[1] That is, VTune detects whether and which invasive runtime you are using and is able to descend into and analyse what the runtime is doing. E.g. with a Python managed analysis VTune replaces all these recursive gibberish calls like PyEval_EvalFrameEx with the Python traces that it's executing. When I first used that mind=blown. Sadly, Windows only. But even then VTune is, without consciously trying to make this comment an advert, one of the best (if not the best) performance analysis tools I've ever used.

Re: Let's Fix OpenGL [pdf]

#55

Post by TazeTSchnitzel »

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.

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?

Post reply on HN