Comment by gpm | Hacker News Reader

Comment by gpm | Hacker News Reader

Parent Full thread

My first at all substantial graphics program (a ray traced 3d pong game with reflections, refraction, etc) was in Vulkan, not OpenGL. I don't have the most experience in this area, but I probably have a fairly unique viewpoint on this.

Vulkan is lowering the barrier for entry to graphics programming. It's doing this by not having hidden state. I don't have to remember what is stored where when I'm programming, I can follow the very fine spec as a pretty much step by step guide and get a working program. Practically every operation is simple, and only really cares about the arguments you pass it not some global state. This is very friendly to someone learning how it works.

It is raising the bar for implementing the "get a triangle onto the screen" part of the program, but that's not the hard part and never will be. It's also only raising that bar for crazy people like me who use Vulkan directly. In the future by the time Vulkan really takes over I expect it will lower the bar for that, since there will be nice libraries on top of it which deal with the "allocate everything" step for you (and maybe now, I don't know of any but I haven't searched... AMD has something I think).

Have you done anything with OpenCL? Because what a lot of people describe kinda sounds like OpenCL where there isn't really much global state or a predefined pipeline. On a high level you're just sending kernels to be executed on the GPU and you're free to organize things any way you like

I haven't done anything with OpenCL, it's been on my "find an excuse to use this" list for awhile now.

I think you might be getting a false impression of Vulkan though. All the vertex shader, fragment shader, submit a buffer filled with geometry primitives, set depth clamping and filter triangles based on winding order, etc pipeline is still there, it's just much more explicit about how you are using it. There is also support for compute shaders that are more what I imagine OpenCL to be like. If you're doing traditional polygon rendering that's going to be slow. Even in my ray tracing project (that does most of the rendering in a compute shader), I imagine using OpenCL would have made it a bit of a pain to display the results realtime to the screen so people can actually play.

Thanks for clearing it up for me. So the pipeline is there but it's stateless... that sounds cool and I guess I really need to try it out. Using OGL a bit it definitely has this weird archaic feeling with all its state. I found it kind of fun and I didn't really shoot myself in the foot with it, but it definitely felt like "this is not how we write software now a days" haha

> Vulkan is lowering the barrier for entry to graphics programming. It's doing this by not having hidden state.

This is OpenGL specific, there isn't an hidden state on other 3D APIs.

That's not true. Direct3Ds up to and including 11 are the same way.

Not really, COM instances for each 3D concept are created and passed around.

There isn't this thing of binding/copying stuff into global state.

What about this (only one example)

ID3D11DeviceContext::IASetVertexBuffers https://msdn.microsoft.com/en-us/library/windows/desktop/ff4...

It's no different from manipulating the opengl context..

Also google bindless opengl

It's very different in practice.

D3D11 contexts are explicit, real objects that you create, manipulate, and pass around. They can be properly and realistically handled in multi-threaded code. OpenGL contexts are opaque and global, and properly handling them in multiple threads is a nightmare. Multiple OpenGL contexts is also very different in functionality from multiple D3D11 device contexts.

Is there another viable free & open source 3D API that I've not heard about?

Reply on news.ycombinator.com