Question about motivations and goals for IGL #2
Comments
birbe
changed the title
|
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 |
|
Thanks for the great question! |
|
soo... why use it over bgfx/wgpu? |
|
This question wasnt answered and its a very important one |
|
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). |
|
-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 -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 |
|
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 |
|
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 :) |
|
@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? |
|
@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. |
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
added
the
documentation
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. |
|
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. |
|
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. |
|
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. |
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
|
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... |
|
Idea is good. IGL is something you have better control to your product, not stuck in a ton of unused features. |
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. |
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
* 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
* 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`. ...
…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
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?
The text was updated successfully, but these errors were encountered: