Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question about motivations and goals for IGL #2

Open
birbe opened this issue Jul 7, 2023 · 22 comments
Open

Question about motivations and goals for IGL #2

birbe opened this issue Jul 7, 2023 · 22 comments
Labels
documentation Improvements or additions to documentation

Comments

@birbe
Copy link

birbe commented Jul 7, 2023

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?

@birbe birbe changed the title why does this exist when bgfx and wgpu already exist Question about motivations and goals for IGL Jul 7, 2023
@rudybear
Copy link
Contributor

rudybear commented Jul 7, 2023

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 rudybear closed this as completed Jul 7, 2023
@rudybear
Copy link
Contributor

rudybear commented Jul 7, 2023

Thanks for the great question!

@m-hugo
Copy link

m-hugo commented Jul 7, 2023

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

@GunpowderGuy
Copy link

GunpowderGuy commented Jul 8, 2023

This question wasnt answered and its a very important one

@rudybear rudybear reopened this Jul 8, 2023
@rudybear
Copy link
Contributor

rudybear commented Jul 8, 2023

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
Copy link

GunpowderGuy commented Jul 8, 2023

-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
Copy link

smumriak commented Jul 8, 2023

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
Copy link

ghost commented Jul 8, 2023

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
Copy link

smumriak commented Jul 9, 2023

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
Copy link

Snowapril commented Jul 9, 2023

@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
Copy link
Contributor

rudybear commented Jul 9, 2023

@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
Copy link

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
Copy link

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
Copy link

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"

@corporateshark corporateshark added the documentation Improvements or additions to documentation label Jul 12, 2023
@ghost
Copy link

ghost commented Jul 14, 2023

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
Copy link

ghost commented Jul 14, 2023

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
Copy link

houmanm commented Jul 15, 2023

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
Copy link

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

@jayrulez
Copy link

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.

facebook-github-bot pushed a commit that referenced this issue Sep 19, 2023
Summary:
State of "shared contexts" before this diff:
* The only way to create a shared context is via the platform specific headers in igl/opengl/<platform>/. If that's not enough friction, the macos header is ObjC++ and can't be used from C++ code.
* Of all platforms, only `egl` and `macos` provide API for creating shared contexts.

This new API allows us to create a shared context from an IContext instance. This new generic method might not allow full customization across all implementations since that sometimes requires platform specific objects/information, so the assumptions here are (1) the new context is part of the same sharegroup, and (2) it's as similar to the existing context as possible.

Note #1: this diff does not implement the new API for all platforms because I don't have the means to test them all. IMO, it's fine for people to have to implement it as needed, since they'll clearly be able to test it.

Note #2: don't be fooled by `IDevice::getSharedContext`, it has nothing to do with multiple contexts in the same sharegroup.

Differential Revision: D49297661

fbshipit-source-id: cfc39b10d9310df9a8e854ae31e852c1e895720d
@crjenkins
Copy link

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
Copy link

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

@BattleAxeVR
Copy link
Contributor

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.

facebook-github-bot pushed a commit that referenced this issue Jun 26, 2024
Summary:
- refactoring making attachment interface
- moving common logic for buffer desc validation check to interface class

Reviewed By: EricGriffith, corporateshark

Differential Revision: D58441164

fbshipit-source-id: bea00bf33725c9685dd9fc6bb25f5e528c33cee2
vinsentli added a commit to vinsentli/igl that referenced this issue Jun 27, 2024
* main: (69 commits)
  The DeviceFeatureLimits::BufferAlignment is not always equals 16 byte on OpenGL backend. (facebook#113)
  Suppress swiftshader's TSAN false-positives
  Remove OpenGL dependency from Vulkan tests
  Disable debug names on Android due to emulator crash
  igl | vulkan - scope guard for locked hw buffer
  igl | vulkan - external hw buffer support facebook#2
  igl | vulkan - external hw buffer support facebook#1
  igl - native hw buffer desc helper
  igl | vulkan - native hw buffer
  igl | vulkan - hw native buffer external memory support
  igl - native hw buffer interface
  add multiviewmultisample devicefeature check
  Assert even if we don't terminate to allow debug break on validation error
  Fixed shell tests compilation
  igl | shell | Demonstrate both YUV formats `NV12` and `420p`.
  igl | shell | Enqueue key events on Windows
  igl | Add helper function `SamplerStateDesc::newYUV()`
  Bump the `apk` modes to NDK 26, API 31 and update Hyperspace
  igl | Add YUV 420p test data file
  igl | Add new texture format `YUV_420p`
  ...

# Conflicts:
#	src/igl/opengl/egl/PlatformDevice.cpp
vinsentli added a commit to vinsentli/igl that referenced this issue Jul 2, 2024
* main: (91 commits)
  igl | opengl | fix glPushDebugGroup() & glDebugMessageInsert() miss the last letter in the label. (facebook#142)
  Fix shell/windows/opengles:appWindows build
  Fix inconsistent formats between VkImageView and VkImage
  igl | vulkan - fix usage of createWithExportMemory
  igl - fix cmake for hw buffers support
  The DeviceFeatureLimits::BufferAlignment is not always equals 16 byte on OpenGL backend. (facebook#113)
  Suppress swiftshader's TSAN false-positives
  Remove OpenGL dependency from Vulkan tests
  Disable debug names on Android due to emulator crash
  igl | vulkan - scope guard for locked hw buffer
  igl | vulkan - external hw buffer support facebook#2
  igl | vulkan - external hw buffer support facebook#1
  igl - native hw buffer desc helper
  igl | vulkan - native hw buffer
  igl | vulkan - hw native buffer external memory support
  igl - native hw buffer interface
  add multiviewmultisample devicefeature check
  Assert even if we don't terminate to allow debug break on validation error
  Fixed shell tests compilation
  igl | shell | Demonstrate both YUV formats `NV12` and `420p`.
  ...
facebook-github-bot pushed a commit that referenced this issue Jul 23, 2024
…or set

Summary:
The interface of `IRenderCommandEncoder::bindBuffer()` does not allow simultaneous binding of uniform and storage buffers into one same buffer binding slot.

Right now, `IGL/Vulkan` maintains two separate descriptor sets for uniform and storage buffers, `#1` and `#2` respectively.

This diff combines both descriptor sets into a single descriptor set `#1`. The bindless descriptor set `#3` is adjusted to remove the gap.

**Old descriptor sets:**
```
0 - combined image samplers
1 - uniform buffers
2 - storage buffers
3 - bindless textures/samplers  <--  optional
```

**New descriptor sets:**
```
0 - combined image samplers
1 - uniform/storage buffers
2 - bindless textures/samplers  <--  optional
```

This will save us a lot of redundant bookkeeping in `IGL/Vulkan` and some memory bandwidth. Besides that, one extra descriptor set becomes available for custom use.

Reviewed By: pixelperfect3, syeh1, mmaurer

Differential Revision: D59788213

fbshipit-source-id: 6fd98015e8ee05bf0af18582f18fc26664117f66
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests