6 ms·

I suspect that implementing OpenGL ontop of Vulkan is the way of the future.

bitwize 8y ago
Eeeehhhh.... To me, OpenGL and Vulkan bear sort of the same relationship to one another that Xlib and XCB do: one is (relatively) easy to program for and lets you get good results right away. The other is much trickier to program for, but gives you much finer grained control over how the underlying layer is actually used, allowing you to get much more performance out of it. So there's room for both. And while basing OpenGL on an underlying Vulkan implementation is certainly feasible and may be logical -- as the Zink authors said, any optimization they can do can also be done by driver authors and then some, and there's still enough OpenGL stuff out there to where driver authors are going to want to make those optimizations.
- zamadatix 8y ago
  There is a reason most browsers on Windows run WebGL through OpenGL and it's not because the driver support has been amazing. Same with MacOS which has deprecated OpenGL in favor of Metal. Sometimes it's not a matter of what can be done rather who can actually do it so it does get done and these lower level APIs allow the general public to get it done instead of hoping vendors do.
  - tokyodude 8y ago
    Did you mean to write "not" though OpenGL? Most WebGL on Windows run through DirectX via OpenGL emulation using the ANGLE Project. Both Chrome and Firefox do this and I'm 99% sure Edge doesn't use OpenGL either so not sure why you thought browsers were using OpenGL on Windows. https://github.com/google/angle https://github.com/google/angle
    - zamadatix 8y ago
      Meant to put "through DirectX" where I put "through OpenGL". Thanks for catching it.
- swiftcoder 8y ago
  Or not, in the case of some vendors. MoltenGL claims their OpenGL-on-Metal implementation is faster than Apple's official OpenGL drivers. I'm guessing that as more and more high-performance applications (i.e. games) migrate to the low-level APIs, other vendors will start to adopt Apple's neglect of OpenGL drivers...
  - tokyodude 8y ago
    OpenGL has some really non-perf friendly design choices. You could optimize the driver. You could also just not support the edge cases that are needed for 100% spec compliance but not needed for 99% of apps and then either print a warning or let the user compile in the slow code that covers those edge cases.
thrower123 8y ago
Hopefully if so, without any of the old legacy crap, if it is intended to be actually used to write new code. If it is just a shim to let old OpenGL code run on Vulkan drivers, which appears to be more the point, then I expect that is unavoidable, as long as we do want to be able to keep running older software down the line. I do feel like there ought to be something for a higher level API that is not a full game engine, is not laden with the historical missteps and anachronisms of OpenGL, and doesn't require the masochism and verbosity of Vulkan. I rather liked DirectX 9, especially with all the built-in convenience utilities in D3DX that were later dropped.
- Jasper_ 8y ago
  Metal is very close to that "perfect layer" in my opinion. I would love to see a portable Metal built on top of Vulkan, rather than the MoltenVK we're getting (an insane idea, in my opinion). Perhaps the Dash/NXT thing that Google is building would be an OK substitute?
  - pjmlp 8y ago
    Not by Khronos given the C++ usage on Metal, as they still keep being too C focused.
    - Jasper_ 8y ago
      ? There's no C++ in Metal, it's Objective-C. You can build C or C++ bindings for Metal if you want ( as has been done by https://github.com/recp/cmt https://github.com/recp/cmt ), the binding language is not really a concern.
      - jcelerier 8y ago
        > There's no C++ in Metal, it's Objective-C. ... did you use Metal ? Metal shaders are written in ≈C++14. Says so right here in the first example: https://developer.apple.com/documentation/metal/hello_triangle https://developer.apple.com/documentation/metal/hello_triang...

Eeeehhhh.... To me, OpenGL and Vulkan bear sort of the same relationship to one another that Xlib and XCB do: one is (relatively) easy to program for and lets you get good results right away. The other is much trickier to program for, but gives you much finer grained control over how the underlying layer is actually used, allowing you to get much more performance out of it. So there's room for both. And while basing OpenGL on an underlying Vulkan implementation is certainly feasible and may be logical -- as the Zink authors said, any optimization they can do can also be done by driver authors and then some, and there's still enough OpenGL stuff out there to where driver authors are going to want to make those optimizations.

zamadatix 8y ago
There is a reason most browsers on Windows run WebGL through OpenGL and it's not because the driver support has been amazing. Same with MacOS which has deprecated OpenGL in favor of Metal. Sometimes it's not a matter of what can be done rather who can actually do it so it does get done and these lower level APIs allow the general public to get it done instead of hoping vendors do.
- tokyodude 8y ago
  Did you mean to write "not" though OpenGL? Most WebGL on Windows run through DirectX via OpenGL emulation using the ANGLE Project. Both Chrome and Firefox do this and I'm 99% sure Edge doesn't use OpenGL either so not sure why you thought browsers were using OpenGL on Windows. https://github.com/google/angle https://github.com/google/angle
  - zamadatix 8y ago
    Meant to put "through DirectX" where I put "through OpenGL". Thanks for catching it.
swiftcoder 8y ago
Or not, in the case of some vendors. MoltenGL claims their OpenGL-on-Metal implementation is faster than Apple's official OpenGL drivers. I'm guessing that as more and more high-performance applications (i.e. games) migrate to the low-level APIs, other vendors will start to adopt Apple's neglect of OpenGL drivers...
- tokyodude 8y ago
  OpenGL has some really non-perf friendly design choices. You could optimize the driver. You could also just not support the edge cases that are needed for 100% spec compliance but not needed for 99% of apps and then either print a warning or let the user compile in the slow code that covers those edge cases.

thrower123 8y ago

Hopefully if so, without any of the old legacy crap, if it is intended to be actually used to write new code. If it is just a shim to let old OpenGL code run on Vulkan drivers, which appears to be more the point, then I expect that is unavoidable, as long as we do want to be able to keep running older software down the line. I do feel like there ought to be something for a higher level API that is not a full game engine, is not laden with the historical missteps and anachronisms of OpenGL, and doesn't require the masochism and verbosity of Vulkan. I rather liked DirectX 9, especially with all the built-in convenience utilities in D3DX that were later dropped.

Jasper_ 8y ago
Metal is very close to that "perfect layer" in my opinion. I would love to see a portable Metal built on top of Vulkan, rather than the MoltenVK we're getting (an insane idea, in my opinion). Perhaps the Dash/NXT thing that Google is building would be an OK substitute?
- pjmlp 8y ago
  Not by Khronos given the C++ usage on Metal, as they still keep being too C focused.
  - Jasper_ 8y ago
    ? There's no C++ in Metal, it's Objective-C. You can build C or C++ bindings for Metal if you want ( as has been done by https://github.com/recp/cmt https://github.com/recp/cmt ), the binding language is not really a concern.
    - jcelerier 8y ago
      > There's no C++ in Metal, it's Objective-C. ... did you use Metal ? Metal shaders are written in ≈C++14. Says so right here in the first example: https://developer.apple.com/documentation/metal/hello_triangle https://developer.apple.com/documentation/metal/hello_triang...