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

[yeukhon]

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++?

[fulafel]

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.

[pandaman]

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