Hacker News new | ask | show | jobs
by badsectoracula 3088 days ago
> or even OpenGLs immediate mode (which does one syscall per emitted vertex, in worst case)

Perhaps with drivers written in the 90s for hardware from the 90s. Any OpenGL implementation worth its salt will buffer those requests on the client side until they need to be observed. Indeed this was a big feature in the heyday of DirectX 9 where D3D programmers had to count the drawcalls whereas with OpenGL you have way more leeway with calls since the driver tends to be smarter and caches that stuff.

In theory with a modern driver using OpenGL's immediate mode API shouldn't need any more syscalls than building the vertex buffers in your program, setting up the necessary state and issuing a buffer draw command.

The only time where you'd need a syscall per emitted vertex would be if the GPU had OpenGL-like commands and your OpenGL implementation was a thin wrapper over that. I think one of ATI's very early GPUs worked like that (although the commands were per primitive, not per vertex).

1 comments

That's why I said in absolute worst case scenario. I know that in the past I actually wrote some program in high school that did use that.

Nowadays, thanks to vulkan and AZDO with glMultiDrawElementsIndirect, you're right, of course — you might even use a single syscall per frame.

That's why I said, in absolute worst case.

No i meant explicitly about the part i quoted: the immediate mode. Stuff like glBegin, glVertex3f, glEnd, etc. Those will not get you a syscall per vertex, they will be buffered by the OpenGL implementation. Modern OpenGL implementations, at least those by Nvidia and AMD (and i also suspect Mesa too) do a lot of optimizations on the client side.