Question about motivations and goals for IGL

[birbe]

Seeing as people are more familiar with the library bgfx for C++ and wgpu for Rust, what's the motivation for starting IGL? does it internally predate both of those libraries?

[rudybear]

The project was started some time ago, and we are committed to supporting a diverse range of backend APIs. Our vision for the abstraction layer is to keep it as lean as possible, with minimal logic built in. This will enable developers to build any type of rendering engine on top of it with minimal impact to performance

[rudybear]

Thanks for the great question!

[m-hugo]

soo... why use it over bgfx/wgpu?

[GunpowderGuy]

This question wasnt answered and its a very important one

[rudybear]

https://github.com/facebook/igl#readme

There are a lot of good options for abstracting GPU API's; each making different trade-offs. We designed IGL around the following priorities:

Low-level, forward-looking API. IGL embraces modern abstractions (command buffers, state containers, bindless, etc) and is designed to give more control than OpenGL's state machine API. As a result, IGL can have leaner backends for modern API's (e.g. Metal, Vulkan).
Minimal overhead for C++. IGL supports new or existing native rendering code without overhead of language interop or the need for other language runtimes.
Reach + scale in production. IGL has been globally battle-tested for broad device reliability (especially the long-tail of Android devices as well as Quest 2/3/Pro compatibility for OpenGL/Vulkan) and performance-tuned on our apps.

[GunpowderGuy]

-Webgpu can be used in c++ ( and rust among others ) without requiring interop with other languages

-It provides much of the same modern abstractions. Strictly speaking i dont think it currently supports a native bindless mode, but neither did direct x 12 and vulkan ( all 3 used a tecnique that simulated bindlessnes ) at launch so this was deferred from the mvp as it can be added later
( Btw, does igl require the vulkan and direct x 12 extensions that provide bindlessness properly speaking ?)

-Webgpu has also been battle tested. More so as its an standard, it precedes igl and it has been adopted by a variety of groups for different ends and using a variety of languages

[smumriak]

WebGPU is much younger compared to this project. The fact that it was published to opensource just now does not mean it was not used in production for a very long time. IGL is battle tested in this sense
Also, WebGPU is an API standard, not a library. This means iteration on changes in the API is much slower in WebGPU.
Compared to bgfx - IGL is a low level library, as close as possible to underlying API. Which is a great benefit for performance tuning.
Valid comparison would be to google's angle, not bgfx or WebGPU. And the difference there is even more prominent: angle provides dead opengl API, while IGL provides modern metal/vulkan/dx12 style API

[ghost]

To be completely honest with you, the probability of IGL being utilized in any significant way is quite low, particularly considering Facebook's reputation for lacking commitment with the Yoga layout engine. The community strongly desires and requires a high-level library with a C API, similar to BGFX but with the user-friendliness of SFML.

[smumriak]

To be completely honest with you, the probability of IGL being utilized in any significant way is quite low, particularly considering Facebook's reputation for lacking commitment with the Yoga layout engine. The community strongly desires and requires a high-level library with a C API, similar to BGFX but with the user-friendliness of SFML.

I can not give more details without breaching NDA :)

[Snowapril]

@rudybear is there any reason igl does not choose subpass-based rendering architecture in Vulkan for android tiling architecture? As image attachment for each pass in VR environment has large resolution there might be extensive GMEM load/store costs for each VkRenderPass draw. Is there any other alternative for it?

[rudybear]

@Snowapril We do have plans to support TB architecture more efficiently. Subpasses are only a part of missing features. Hopefully we will get there soon.

[Eeveelution]

WebGPU is much younger compared to this project. The fact that it was published to opensource just now does not mean it was not used in production for a very long time. IGL is battle tested in this sense Also, WebGPU is an API standard, not a library. This means iteration on changes in the API is much slower in WebGPU. Compared to bgfx - IGL is a low level library, as close as possible to underlying API. Which is a great benefit for performance tuning. Valid comparison would be to google's angle, not bgfx or WebGPU. And the difference there is even more prominent: angle provides dead opengl API, while IGL provides modern metal/vulkan/dx12 style API

age doesnt matter if nobody had the chance to use it in that lifespan except facebook employees

[jayrulez]

I don't get why people are being so critical of the existence of this library. There are literally 10s to 100s of similar libraries on Github (either standalone or part of another project). The most interesting thing about this one is that it is from Facebook/Meta.

It exists for a similar reason as the others. It makes different trade-offs from bgfx and others to satisfy the needs of the developers. If it doesn't meet your needs then use another (or create your own). It's not that big of a deal that they chose to create their own graphics abstraction layer instead of shoe-horning another in their products.

It is also not a standard like WebGPU, though it does fill a similar role as Dawn and wgpu. This library could implement WebGPU as a backend.

Here's just of a short list of similar libraries:
https://github.com/DiligentGraphics/DiligentCore
https://github.com/bkaradzic/bgfx
https://github.com/LukasBanana/LLGL
https://github.com/altseed/LLGI
https://github.com/NVIDIAGameWorks/nvrhi
https://github.com/NVIDIAGameWorks/NRI
https://github.com/qt/qtbase/tree/dev/src/gui/rhi
https://github.com/flutter/engine/tree/main/impeller/renderer
https://github.com/google/bigwheels
https://github.com/AndrewRichards-Code/MIRU
https://github.com/lun0522/lighter
https://github.com/domme/FANCY
https://github.com/NazaraEngine/NazaraEngine/tree/main/include/Nazara/Renderer
https://github.com/andrejnau/FlyCube
https://github.com/PanosK92/SpartanEngine/tree/master/runtime/RHI
https://github.com/o3de/o3de/tree/development/Gems/Atom/RHI
https://github.com/simul/Platform/tree/main/CrossPlatform
https://github.com/PCSX2/pcsx2/tree/master/pcsx2/GS/Renderers/Common
https://github.com/gopro/ngfx/tree/develop/src/ngfx
https://github.com/MethanePowered/MethaneKit
https://github.com/crud89/LiteFX
https://github.com/QSXW/Immortal/tree/main/Immortal/Render
https://github.com/SakuraEngine/SakuraEngine/tree/main/modules/runtime/include/cgpu
https://github.com/Try/Tempest/tree/master/Engine/gapi
https://github.com/shader-slang/slang/tree/master/tools/gfx

That's just from a quick Github search. There are many more.

[smumriak]

age doesnt matter if nobody had the chance to use it in that lifespan except facebook employees

The question was "Why not use WebGPU?". The answer is "WebGPU did not exist, it's very young"

[ghost]

I don't get why people are being so critical of the existence of this library. There are literally 10s to 100s of similar libraries on Github (either standalone or part of another project). The most interesting thing about this one is that it is from Facebook/Meta.

It exists for a similar reason as the others. It makes different trade-offs from bgfx and others to satisfy the needs of the developers. If it doesn't meet your needs then use another (or create your own). It's not that big of a deal that they chose to create their own graphics abstraction layer instead of shoe-horning another in their products.

It is also not a standard like WebGPU, though it does fill a similar role as Dawn and wgpu. This library could implement WebGPU as a backend.

Here's just of a short list of similar libraries: https://github.com/DiligentGraphics/DiligentCore https://github.com/bkaradzic/bgfx https://github.com/LukasBanana/LLGL https://github.com/altseed/LLGI https://github.com/NVIDIAGameWorks/nvrhi https://github.com/NVIDIAGameWorks/NRI https://github.com/qt/qtbase/tree/dev/src/gui/rhi https://github.com/flutter/engine/tree/main/impeller/renderer https://github.com/google/bigwheels https://github.com/AndrewRichards-Code/MIRU https://github.com/lun0522/lighter https://github.com/domme/FANCY https://github.com/NazaraEngine/NazaraEngine/tree/main/include/Nazara/Renderer https://github.com/andrejnau/FlyCube https://github.com/PanosK92/SpartanEngine/tree/master/runtime/RHI https://github.com/o3de/o3de/tree/development/Gems/Atom/RHI https://github.com/simul/Platform/tree/main/CrossPlatform https://github.com/PCSX2/pcsx2/tree/master/pcsx2/GS/Renderers/Common https://github.com/gopro/ngfx/tree/develop/src/ngfx https://github.com/MethanePowered/MethaneKit https://github.com/crud89/LiteFX https://github.com/QSXW/Immortal/tree/main/Immortal/Render https://github.com/SakuraEngine/SakuraEngine/tree/main/modules/runtime/include/cgpu https://github.com/Try/Tempest/tree/master/Engine/gapi https://github.com/shader-slang/slang/tree/master/tools/gfx

That's just from a quick Github search. There are many more.

Everything you listed either falls under the category of "Low-Level," of which we already have enough, or is "Not Relevant" because it pertains to a different language than "C or C++." Additionally, there are items that are part of an entire framework like "Qt," some that are "Not Functional," and others that are "Feature-Incomplete" due to being a hobby project.

And I think you may be mistaking "honesty" for being "critical."

And the IGL developers requested community feedback when they announced the existence of their project on numerous Linux news websites.

If you were to explore the discussions on some of those Linux news websites, you would discover that the community simply isn't interested in what this project has to offer. And some of us were simply trying to provide constructive criticism because it is evident that when Facebook/Meta develops a project, it is primarily for the purpose of generating profit, and their intention is for developers to utilize the said project.

[ghost]

To the IGL develpers if your serious about creating something the community wants to use. I think if you could provide the functionality of https://github.com/bkaradzic/bgfx with the ease of and cleanliness of https://www.sfml-dev.org/tutorials/2.6/ you will find that the community you are targeting will respond very differently. I am not saying to use these library's I am referancing the functionality. The community simply doesn't need another low-level library that takes significant time and effort to learn. If you thing that I am incorrect then I challenge you to poll your target audience and simple ask them if they think I am correct.

[houmanm]

IGL was started in early 2017, at which point there weren't many other options available that met all of our requirements of the time. It has served many of our needs over the years, as we've matured the library. We open sourced it to share our technology, and to get more developers improving and evolving it together with us. As fellow developers, we appreciate all such contributions, as well as any feedback to help us improve things together.

[lamweilun]

As compared to bgfx/LLGL/Diligent, wouldn't IGL be akin to Google's Filament?

[jayrulez]

As compared to bgfx/LLGL/Diligent, wouldn't IGL be akin to Google's Filament?

No, IGL is low level like Diligent/LLGL/bgfx. Filament is a high level renderer implementing a scene graph, PBR, and many other rendering features.

[crjenkins]

bgfx forces you to use their shitty build system. That's a start. Actually the majority of low-level api projects forces you into their own build system because they refuse to use industry standards. I don't know if it's an ego thing, but it's a thing...

[whatisor]

Idea is good. IGL is something you have better control to your product, not stuck in a ton of unused features.

[BattleAxeVR]

bgfx forces you to use their shitty build system. That's a start. Actually the majority of low-level api projects forces you into their own build system because they refuse to use industry standards. I don't know if it's an ego thing, but it's a thing...

bgfx, last I used it for a VR project, was using deferred, or it had some buffering that made VR work very poorly. Do not recommend using it for VR, at all. Not only that, but their views are done independently, so forget about single pass stereo which is a 30% performance delta. TL:DR: BGFX isn't suitable for VR projects.