3 ms·

I don't think glDrawElements() goes into the driver though (at least there is no sane reason for it I can imagine, you only need to go into the driver to kick a

I don't think glDrawElements() goes into the driver though (at least there is no sane reason for it I can imagine, you only need to go into the driver to kick a command buffer at the end of frame). Nevertheless, even if some implementations actually do call driver, the GP's point is that the whole point of Vulkan is getting rid of global state to allow parallel command buffer creation. JS is single threaded so, no matter how cheap or expensive the calls are, you won't be able to take advantage of Vulkan since you are running just one thread.

nhaehnle 9y ago
Of course glDrawElements() has to go into the driver, because it needs to do hardware-specific work. This is obviously true in OpenGL(ES), but even if you were to implement it via a translation layer to Vulkan, you still have to call the various Vulkan-equivalent commands, at the very least vkCmdDrawIndexed. Here's an implementation to make it painfully obvious why that has to involve the driver: https://github.com/mesa3d/mesa/blob/d819b1fcec02be5e0cfc87b6246833a2a2d5f034/src/amd/vulkan/radv_cmd_buffer.c#L2758 https://github.com/mesa3d/mesa/blob/d819b1fcec02be5e0cfc87b6...
- pandaman 9y ago
  No, you only need to go into the driver when you need to do work that cannot be done in the userland. What are you talking about is just a shared library in the address space of your app, and the code you are showing is literally just writing bytes into a buffer. Nobody forbids you from calling it "driver", of course but then the whole point of "going into the driver" does not make sense, since there is no syscall and it's just a regular function.
  - nhaehnle 9y ago
    You're thinking of kernel-mode drivers. What I've linked to is a driver. Everybody calls it that. When you go download a driver for graphics cards, whether on Linux or Windows, that driver actually consists of multiple components, some of them running in kernel-mode and some of them running in user-mode. It's basically the exo-kernel principle, but without feeling the need of giving it a fancy name :) There's a broader history of user-mode drivers not just for graphics, and not just in the obvious case of micro-kernels. User-mode USB drivers used to be a thing, for example (and I guess they still are for some more obscure hardware).
    - pandaman 9y ago
      As I said, you can call it whatever you want, "driver", "kernel" or "linux" even. The point of "going into the driver" being expensive only makes sense if it's a syscall, which it is not as we both seem to agree.
      - crzwdjk 9y ago
        Not really. OpenGL in particular has to do a surprising amount of work on every call, to make sure the state hasn't changed and to update all sorts of things if it has, to manage the various buffers and make sure they're mapped in the right place, and then to go down through all the abstraction layers until you end up in the code that actually writes stuff into the command buffer. It's not going to be a syscall level of overhead, though it may end up being that if stuff needs to get mapped into the GPU address space, but it's definitely going to be more than the dozen instruction overhead of going from JITed to native C++ code.
        pandaman 9y ago
        "Not really" what? There is syscall? Then you say yourself there is not... I only argue that there is no syscall in glDraw* as well as the vast majority of the APIs. Sure, driver/opengl do whatever and some calls are more expensive than others but adding more overhead is not going to make it any better and it's already pretty bad without overhead. That's why they developed Vulkan in the first place.
      - nhaehnle 9y ago
        You know, you're talking to somebody who writes graphics drivers for a living :) If you don't believe me or crzwdjk, just go ahead and actually profile a system running an OpenGL application. The syscall overhead -- as in, the overhead of transitioning between user and kernel mode -- is laughably negligible compared to everything else. Also, the vast majority of driver CPU time is spent in user space building up command submissions. The final command submission itself isn't free of course, but clearly more time is spent processing precisely those glDraw*() calls that you seem to think don't matter.
  - kllrnohj 9y ago
    The userspace part of the driver is still called the driver. A driver does not mean a kernel module. It's often that, but it does not exclusively mean that. Userspace drivers are still drivers. The library that gets loaded into the process is part of the driver. It's provided by the GPU vendor and it's specific to the hardware you're running. It maps API calls to hardware-specific commands. Aka, it's a driver. It just happens to be implemented as a userspace library for most of the work.

nhaehnle 9y ago

Of course glDrawElements() has to go into the driver, because it needs to do hardware-specific work. This is obviously true in OpenGL(ES), but even if you were to implement it via a translation layer to Vulkan, you still have to call the various Vulkan-equivalent commands, at the very least vkCmdDrawIndexed. Here's an implementation to make it painfully obvious why that has to involve the driver: https://github.com/mesa3d/mesa/blob/d819b1fcec02be5e0cfc87b6246833a2a2d5f034/src/amd/vulkan/radv_cmd_buffer.c#L2758 https://github.com/mesa3d/mesa/blob/d819b1fcec02be5e0cfc87b6...

pandaman 9y ago
No, you only need to go into the driver when you need to do work that cannot be done in the userland. What are you talking about is just a shared library in the address space of your app, and the code you are showing is literally just writing bytes into a buffer. Nobody forbids you from calling it "driver", of course but then the whole point of "going into the driver" does not make sense, since there is no syscall and it's just a regular function.
- nhaehnle 9y ago
  You're thinking of kernel-mode drivers. What I've linked to is a driver. Everybody calls it that. When you go download a driver for graphics cards, whether on Linux or Windows, that driver actually consists of multiple components, some of them running in kernel-mode and some of them running in user-mode. It's basically the exo-kernel principle, but without feeling the need of giving it a fancy name :) There's a broader history of user-mode drivers not just for graphics, and not just in the obvious case of micro-kernels. User-mode USB drivers used to be a thing, for example (and I guess they still are for some more obscure hardware).
  - pandaman 9y ago
    As I said, you can call it whatever you want, "driver", "kernel" or "linux" even. The point of "going into the driver" being expensive only makes sense if it's a syscall, which it is not as we both seem to agree.
    - crzwdjk 9y ago
      Not really. OpenGL in particular has to do a surprising amount of work on every call, to make sure the state hasn't changed and to update all sorts of things if it has, to manage the various buffers and make sure they're mapped in the right place, and then to go down through all the abstraction layers until you end up in the code that actually writes stuff into the command buffer. It's not going to be a syscall level of overhead, though it may end up being that if stuff needs to get mapped into the GPU address space, but it's definitely going to be more than the dozen instruction overhead of going from JITed to native C++ code.
      - pandaman 9y ago
        "Not really" what? There is syscall? Then you say yourself there is not... I only argue that there is no syscall in glDraw* as well as the vast majority of the APIs. Sure, driver/opengl do whatever and some calls are more expensive than others but adding more overhead is not going to make it any better and it's already pretty bad without overhead. That's why they developed Vulkan in the first place.
    - nhaehnle 9y ago
      You know, you're talking to somebody who writes graphics drivers for a living :) If you don't believe me or crzwdjk, just go ahead and actually profile a system running an OpenGL application. The syscall overhead -- as in, the overhead of transitioning between user and kernel mode -- is laughably negligible compared to everything else. Also, the vast majority of driver CPU time is spent in user space building up command submissions. The final command submission itself isn't free of course, but clearly more time is spent processing precisely those glDraw*() calls that you seem to think don't matter.
- kllrnohj 9y ago
  The userspace part of the driver is still called the driver. A driver does not mean a kernel module. It's often that, but it does not exclusively mean that. Userspace drivers are still drivers. The library that gets loaded into the process is part of the driver. It's provided by the GPU vendor and it's specific to the hardware you're running. It maps API calls to hardware-specific commands. Aka, it's a driver. It just happens to be implemented as a userspace library for most of the work.