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.
Let's Fix OpenGL [pdf]
11–20 of 55 posts
Re: Let's Fix OpenGL [pdf]
#12I 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.
As far as debugging goes, use KHR_debug extension, as well as RenderDoc or similar tools.
As far as (automated) testing goes, I don't really know any solutions there beyond a "fuzzy" comparison to a set of "known good" images. But the problem is, this only works for regression testing. When implementing something new (say, you want to add reflections to your engine), there isn't anything to compare to, you just have to actually look at it.
Re: Let's Fix OpenGL [pdf]
#13Flicking through the article made me wonder - would it be possible to have something like ACID tests for OpenGL?
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 drivers couldn't pass because the hardware was lacking, for example, hardware didn't have enough precision in the blender... those were the days. The p in piglit stands for your choice of pragmatic or practical. I'm not sure if that's actually documented anywhere, but as the original author, I should know ;-)
I'm sure piglit has bugs, but it's also well known that certain closed source drivers have less than conformant GLSL compilers, for example - so the fact that drivers passing the Khronos conformance tests fail piglit tests in itself doesn't mean anything other than shit needs investigating, and occasionally needs spec clarifications.
Re: Let's Fix OpenGL [pdf]
#14I'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.
Re: Let's Fix OpenGL [pdf]
#15I 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.
You would probably need to use a software renderer for that, I imagine.
Re: Let's Fix OpenGL [pdf]
#16A concrete problem that the author misses is the need for a better understanding of SPMD semantics. GLSL has the notion of "dynamically uniform" values, i.e. values that are the same across all shader threads that arise from one draw call, but this notion isn't really properly defined anywhere. It involves an unholy mixture of data flow and control flow that doesn't seem to appear anywhere else in PL theory.
Stuff kind of just works because GLSL doesn't have unstructured control-flow (i.e., there's no goto), and people have a mental model of what the hardware actually does and use that for the semantics.
But a proper study of those semantics, and how to carry it over to unstructured control-flow, or to what extent it is possible, would be awesome.
Re: Let's Fix OpenGL [pdf]
#17> 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,…
Shaders are SIMT (single instruction multiple threads).
Re: Let's Fix OpenGL [pdf]
#18Flicking through the article made me wonder - would it be possible to have something like ACID tests for OpenGL?
There was a pixel-accurate test suite for OpenGL 1,0 from Kronos,[1] but it predates programmable shaders. It tests the geometry and texture processing. It's not free.
Re: Let's Fix OpenGL [pdf]
#19I'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.
Re: Let's Fix OpenGL [pdf]
#20I'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 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.