5 ms·

Yikes, a GL-inspired graphics library... let's see, how many sins do I count: * Still using global enable/disable flags for all the state bits (e.g. depth test

Yikes, a GL-inspired graphics library... let's see, how many sins do I count: * Still using global enable/disable flags for all the state bits (e.g. depth test, face culling) rather than packing them into a PSO struct. Why? * Uniforms are bound manually and kept statefully rather than being provided as a UBO interface. * No support for draw call buffering or sorting, and what appears like limited support for multiple framebuffers. * Ooh, "SceneGraph", is that where the pass manager is? Oh, no, it's an object layer that seems to resemble circa OGRE around 2011. Doesn't seem to do any transparency sorting or pass management either. I'd really recommend something like bgfx, sokol, or wgpu instead, which have reduced their dependence on global state, and provide a much better foundation for modern graphics.

gameswithgabe 4y ago
Are we looking at the same code? I'm not an OpenGL or Vulkan expert, but: > ...rather than packing them into a PSO struct. Why? * You can clearly read on the front page of the repository that this supports OpenGL 2 through 4.6. I think you're just not looking hard enough. He has Vulkan support in here with a clearly marked file named Pipeline.cpp. The guy knows what a pipeline is... > ...rather than being provided as a UBO interface. * Is this not a UBO interface? > layout(std140) uniform material { vec4 diffuse; vec4 specular; }; It's in his documentation for AbstractShaderProgram. He has explicit binding for stuff pre OpenGL 3.3 or whenever OpenGL added UBOs. > ...appears like limited support for multiple framebuffers. * I don't see why you think there's limited support for multiple framebuffers...? From his docs: > @section GL-Framebuffer-usage-multiple-outputs Multiple fragment shader outputs And then it goes on to explain how to use multiple framebuffer outputs for something like deferred rendering. Moreover, his docs have snippets like this: > @deprecated_gl Prefer to use @ref AbstractFramebuffer::clearDepth() @ref AbstractFramebuffer::clearDepthStencil() instead of @ref setClearDepth() and @ref AbstractFramebuffer::clear() as it leads to less state changes Which clearly shows this guy knows what global state is and why it's bad. I think you're making very broad assumptions based on a very cursory glance at this project. I've only looked at it for about 30 minutes and it looks like a well developed library by somebody who knows what they're doing. I'm sure I could find code that counters the rest of your argument, but I don't feel like looking anymore. None of your criticism seem well intentioned. It might behoove you to give people the benefit of the doubt and realize that you may be able to learn something from them, even if they're so clearly inferior to you. P.S. Don't start off a criticism by saying "how many sins do I count". I don't know your experience, but that's just such an incredibly pretentious statement that's begging to be countered by somebody way more knowledgeable than you about this stuff.
- Jasper_ 4y ago
  > He has Vulkan support in here with a clearly marked file named Pipeline.cpp. The guy knows what a pipeline is... There is a Vulkan API wrapper. However, there is no "Vk Renderer" -- no code seems to use the Vulkan parts of the code system, and the two projects seem unrelated. > * Is this not a UBO interface? There are ways of making a uniform buffer, however the examples don't cover them and the API doesn't adapt automatically. See how all of the setters assert if UBOs are enabled. https://github.com/mosra/magnum/blob/cfc02599e54e02337dd56bb61f70b2e61eb9ce8d/src/Magnum/Shaders/DistanceFieldVectorGL.cpp#L221-L239 https://github.com/mosra/magnum/blob/cfc02599e54e02337dd56bb... > * I don't see why you think there's limited support for multiple framebuffers...? The code I do see is about binding/unbinding framebuffers in a stateful manner, e.g. AbstractFramebuffer::bind(), rather than supporting passes. > None of your criticism seem well intentioned. It might behoove you to give people the benefit of the doubt and realize that you may be able to learn something from them, even if they're so clearly inferior to you. To put it simply, I've taught enough graphics to know first-hand the kinds of misconceptions that OpenGL-styled APIs can cause, and I'm just a bit tired to see it continue. Admittedly I was a bit harsh, I don't mean any harm towards the author. There are just graphics APIs with interfaces I consider to be much better designed.
- lpapez 4y ago
  The dismissive, know-it-all, didnt-read-but-holds-opinion attitude is the norm on HN, it is best to simply ignore such comments.
johndough 4y ago
Does OpenGL even support PSOs? I thought that was a Vulkan thing.
deleted 4y ago
[deleted]
- deleted 4y ago
  [deleted]
mosra 4y ago
Project author here. Hello :) Let me just clarify a few bits. The GL wrapper is deliberately this low-level, because the library provides a baseline for a much broader range of uses than just games themselves. For an application that performs real-time image / video processing on a GPU, draw call or transparency sorting would be extra overhead. An _actual game engine_ that implements its own custom draw batching would have to work around the implicit batching, if it was there. The wrapper is just lower-level than you expected, that's all, and same is for the currently unadvertised in-progress Vulkan wrapper. Regarding uniforms, other people already pointed out there is a UBO interface [1]. But there are also users who _rely_ on WebGL 1.0 or GL 2.1 compatibility (imagine that!), so I can't just drop the classic uniform path (and other related suffering). On the other hand, not all hardware and drivers have the UBO path faster in all cases, so providing an UBO iterface and failing back to classic uniforms only if UBOs are not available doesn't make sense either. In my measurements, the only case where UBOs actually improved performance across all platforms was in a multi-draw scenario, with UBOs being split by frequency of update, containing data for 100+ draws and being uploaded at most once per frame. The engine supports such use case [2], but doing that efficiently means having your data and logic ready upfront. If the library would try to attempt that automagically implicitly, it wouldn't end well and the gains would be minimal. That being said, I don't rule out a possibility for an opt-in high-level "render graph" or "pass management" API that does fancy things on its own, but it needs a lower-level layer built upon. Not all or nothing, layers. Layers so projects with specific needs can ignore that and use the layer below directly. There's no global state anymore except for the Renderer, and I'm painfully aware of that last piece, yes. It's getting fixed, but because on certain targets (WebGL) every call matters, it's not as simple as packing all that state into a single struct and then resetting it in a bulk before a draw call. "SceneGraph"? Yes, that part is in a maintenance mode, and I recommend new users to use entt, flecs or other ECS frameworks instead, until I build a replacement for this ancient technology that's there since 2010 (yes). But a lot of projects still want to use it because it's _damn convenient_, so I can't really remove it yet either to save the project from immediately raising a "red flag" to certain people ;) Finally, the project has been under frantic development since its last version annoucement in 2020. Not everything is done and documented yet, the website shows slightly outdated info and the examples don't really use the fresh APIs yet. The Vulkan parts you saw as "unrelated" or "unused", those are still getting finished. Plus there's of course a roadmap to satisfy the needs of long-running Magnum-based projects, so the focus is often in different areas than the "yikes"-triggering ones. Such as asset management and conversion [3]. Have a nice day. [1] https://doc.magnum.graphics/magnum/shaders.html#shaders-usage-ubo https://doc.magnum.graphics/magnum/shaders.html#shaders-usag... [2] https://doc.magnum.graphics/magnum/shaders.html#shaders-usage-multidraw https://doc.magnum.graphics/magnum/shaders.html#shaders-usag... [3] https://blog.magnum.graphics/announcements/new-geometry-pipeline/ https://blog.magnum.graphics/announcements/new-geometry-pipe...

gameswithgabe 4y ago

Are we looking at the same code? I'm not an OpenGL or Vulkan expert, but: > ...rather than packing them into a PSO struct. Why? * You can clearly read on the front page of the repository that this supports OpenGL 2 through 4.6. I think you're just not looking hard enough. He has Vulkan support in here with a clearly marked file named Pipeline.cpp. The guy knows what a pipeline is... > ...rather than being provided as a UBO interface. * Is this not a UBO interface? > layout(std140) uniform material { vec4 diffuse; vec4 specular; }; It's in his documentation for AbstractShaderProgram. He has explicit binding for stuff pre OpenGL 3.3 or whenever OpenGL added UBOs. > ...appears like limited support for multiple framebuffers. * I don't see why you think there's limited support for multiple framebuffers...? From his docs: > @section GL-Framebuffer-usage-multiple-outputs Multiple fragment shader outputs And then it goes on to explain how to use multiple framebuffer outputs for something like deferred rendering. Moreover, his docs have snippets like this: > @deprecated_gl Prefer to use @ref AbstractFramebuffer::clearDepth() @ref AbstractFramebuffer::clearDepthStencil() instead of @ref setClearDepth() and @ref AbstractFramebuffer::clear() as it leads to less state changes Which clearly shows this guy knows what global state is and why it's bad. I think you're making very broad assumptions based on a very cursory glance at this project. I've only looked at it for about 30 minutes and it looks like a well developed library by somebody who knows what they're doing. I'm sure I could find code that counters the rest of your argument, but I don't feel like looking anymore. None of your criticism seem well intentioned. It might behoove you to give people the benefit of the doubt and realize that you may be able to learn something from them, even if they're so clearly inferior to you. P.S. Don't start off a criticism by saying "how many sins do I count". I don't know your experience, but that's just such an incredibly pretentious statement that's begging to be countered by somebody way more knowledgeable than you about this stuff.

Jasper_ 4y ago
> He has Vulkan support in here with a clearly marked file named Pipeline.cpp. The guy knows what a pipeline is... There is a Vulkan API wrapper. However, there is no "Vk Renderer" -- no code seems to use the Vulkan parts of the code system, and the two projects seem unrelated. > * Is this not a UBO interface? There are ways of making a uniform buffer, however the examples don't cover them and the API doesn't adapt automatically. See how all of the setters assert if UBOs are enabled. https://github.com/mosra/magnum/blob/cfc02599e54e02337dd56bb61f70b2e61eb9ce8d/src/Magnum/Shaders/DistanceFieldVectorGL.cpp#L221-L239 https://github.com/mosra/magnum/blob/cfc02599e54e02337dd56bb... > * I don't see why you think there's limited support for multiple framebuffers...? The code I do see is about binding/unbinding framebuffers in a stateful manner, e.g. AbstractFramebuffer::bind(), rather than supporting passes. > None of your criticism seem well intentioned. It might behoove you to give people the benefit of the doubt and realize that you may be able to learn something from them, even if they're so clearly inferior to you. To put it simply, I've taught enough graphics to know first-hand the kinds of misconceptions that OpenGL-styled APIs can cause, and I'm just a bit tired to see it continue. Admittedly I was a bit harsh, I don't mean any harm towards the author. There are just graphics APIs with interfaces I consider to be much better designed.
lpapez 4y ago
The dismissive, know-it-all, didnt-read-but-holds-opinion attitude is the norm on HN, it is best to simply ignore such comments.

johndough 4y ago

Does OpenGL even support PSOs? I thought that was a Vulkan thing.

deleted 4y ago

[deleted]

deleted 4y ago
[deleted]

mosra 4y ago

Project author here. Hello :) Let me just clarify a few bits. The GL wrapper is deliberately this low-level, because the library provides a baseline for a much broader range of uses than just games themselves. For an application that performs real-time image / video processing on a GPU, draw call or transparency sorting would be extra overhead. An _actual game engine_ that implements its own custom draw batching would have to work around the implicit batching, if it was there. The wrapper is just lower-level than you expected, that's all, and same is for the currently unadvertised in-progress Vulkan wrapper. Regarding uniforms, other people already pointed out there is a UBO interface [1]. But there are also users who _rely_ on WebGL 1.0 or GL 2.1 compatibility (imagine that!), so I can't just drop the classic uniform path (and other related suffering). On the other hand, not all hardware and drivers have the UBO path faster in all cases, so providing an UBO iterface and failing back to classic uniforms only if UBOs are not available doesn't make sense either. In my measurements, the only case where UBOs actually improved performance across all platforms was in a multi-draw scenario, with UBOs being split by frequency of update, containing data for 100+ draws and being uploaded at most once per frame. The engine supports such use case [2], but doing that efficiently means having your data and logic ready upfront. If the library would try to attempt that automagically implicitly, it wouldn't end well and the gains would be minimal. That being said, I don't rule out a possibility for an opt-in high-level "render graph" or "pass management" API that does fancy things on its own, but it needs a lower-level layer built upon. Not all or nothing, layers. Layers so projects with specific needs can ignore that and use the layer below directly. There's no global state anymore except for the Renderer, and I'm painfully aware of that last piece, yes. It's getting fixed, but because on certain targets (WebGL) every call matters, it's not as simple as packing all that state into a single struct and then resetting it in a bulk before a draw call. "SceneGraph"? Yes, that part is in a maintenance mode, and I recommend new users to use entt, flecs or other ECS frameworks instead, until I build a replacement for this ancient technology that's there since 2010 (yes). But a lot of projects still want to use it because it's _damn convenient_, so I can't really remove it yet either to save the project from immediately raising a "red flag" to certain people ;) Finally, the project has been under frantic development since its last version annoucement in 2020. Not everything is done and documented yet, the website shows slightly outdated info and the examples don't really use the fresh APIs yet. The Vulkan parts you saw as "unrelated" or "unused", those are still getting finished. Plus there's of course a roadmap to satisfy the needs of long-running Magnum-based projects, so the focus is often in different areas than the "yikes"-triggering ones. Such as asset management and conversion [3]. Have a nice day. [1] https://doc.magnum.graphics/magnum/shaders.html#shaders-usage-ubo https://doc.magnum.graphics/magnum/shaders.html#shaders-usag... [2] https://doc.magnum.graphics/magnum/shaders.html#shaders-usage-multidraw https://doc.magnum.graphics/magnum/shaders.html#shaders-usag... [3] https://blog.magnum.graphics/announcements/new-geometry-pipeline/ https://blog.magnum.graphics/announcements/new-geometry-pipe...