5 ms·
Intermediate Graphics Library, a cross-platform GPU abstraction library by Meta
- adamnemecek 3y agoWhy not use webgpu?
- diggan 3y agoAt a glance, IGL (this submission) seems more similar to wgpu than WebGPU. But then the question just becomes "Why not use wgpu?" instead.
- foota 3y agoI'm guessing it predates webgpu internally.
- swatcoder 3y agoBecause projects have all sorts of requirements. Shipping and running an embedded browser engine, or running in a user's active browser session, is not going to fit the requirements for many many projects.
- sluijs 3y agoWebGPU is - despite the name - not designed to run in a browser per se. You can use wgpu and Dawn as native crates/libraries as well.
- MegaDeKay 3y agoThey gives these reasons at the Github link for its existence... --- Intermediate Graphics Library (IGL) is a cross-platform library that commands the GPU. It encapsulates common GPU functionality with a low-level cross-platform interface. IGL is designed to support multiple backends implemented on top of various graphics APIs (e.g. OpenGL, Metal and Vulkan) with a common interface. 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.
- skavi 3y agoThe first two points easily apply to WebGPU. Maybe not the last one yet.
- bmitc 3y agoHaving researched WebGPU a little, I'm not seeing anything there that explains why this over WebGPU. As far as I understand, those reasons are identical to those for WebGPU. Can anyone explain?
- jayd16 3y agoIs Android support solid for Dawn/webgpu? Seems like it's marked as work in progress compared to the confident support laid out here.
- adamnemecek 3y agoRight but if they needed that, they could have just contributed android support to wgpu.
- swatcoder 3y agoMeta has bet the farm on their VR/AR/XR platform and smartly wants control over the tooling that developers will use to target it. The last thing they want is for some Quest innovation to be hamstrung waiting for a standard body to approve support for some new feature or for a third-party open source maintainer to incorporate some fix/addition/compatibility PR. Owning a project like this, if they can get developers to use it, is a huge business security asset and competitive advantage for them. That's why this exists and why it's being promoted. Whether developers see it as worth using instead of other options is a different question. Meta would probably say the answer to "why" for developers is: "to make sure your project gets the most out of the Quest products (as well as other Android platforms), now and in the future"
- adamnemecek 3y agoThey can’t get users to use it as it provides little over webgpu.
- rossant 3y agoYes, it is weird that WebGPU is not even mentioned on the README. Maybe this project was initiated before WebGPU was mature enough (for the record, WebGPU is still mentioned as an "experimental technology" by MDN (https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API).
- shortrounddev2 3y agoThe samples are just hideous. Platform selection #if preprocessors every 5 lines. I would never want to maintain code like this
- deleted 3y ago[deleted]
- edvinbesic 3y agoThis was the first thing that stood out to me looking at the samples. How is it abstracted if you have to constantly do #if windows or #if opengl etc.
- bagels 3y agoSeems pretty disqualifying. https://github.com/facebook/igl/blob/main/samples/desktop/Tiny/Tiny.cpp https://github.com/facebook/igl/blob/main/samples/desktop/Ti...
- ReactiveJelly 3y agoThe GPU and ML libraries, frameworks, abstractions, and drivers have long since felt to me like the famed "Linux audio jungle" of old. At least I understand why ffmpeg, gstreamer, OSS, ALSA, PulseAudio, and PipeWire all exist. CUDA, OpenCL, Vulkan, Metal, PyTorch, TensorFlow, I don't understand. They all build on CUDA and AMD / Intel / CPUs are treated as 2nd-class citizens, right?
- kmeisthax 3y agoCUDA, OpenCL, Vulkan, and Metal are all different graphics APIs provided by GPU vendors. GPU vendors can implement all four of them if they like, but in practice, CUDA is an NVidia exclusive, Metal is a Apple exclusive and vice versa, and OpenCL is kind of old and unused (and also used to be an Apple technology as well). There's also other APIs provided by non-GPU hardware vendors. PyTorch and TensorFlow are training and inference libraries. In theory, PyTorch at least (probably also TF) is properly abstracted and can work with all APIs. In practice CUDA gets the most testing and has all the operator fusion kernels you need for good performance, so everyone trains on CUDA. Inference is less resource-intensive than training, and there's a lot of vendors that provide inference-only hardware (e.g. "Edge TPUs") that's better supported, so on the inference end there's more variety in API usage. You can of course train and inference on CPU but that means terrible performance.
- FireInsight 3y agoWell, you're basically correct that the ML GPU libraries basically all build on CUDA with non-Nvidia being a second class citizen, but then stuff like OpenGL, Vulkan, DirectX and Metal are more general "os-level" or low level GPU graphics and compute abstractions. This, and the popular rust project `wgpu` which is the base for Firefox's WebGPU implementation abstract over these lower-level abstractions that may or may not be available such that the same, often a bit simpler code is usable accross multiple types of devices. Basically the opposite of needing CUDA.
- a_e_k 3y agoPrevious discussion: https://news.ycombinator.com/item?id=36635526 https://news.ycombinator.com/item?id=36635526
- dang 3y agoThanks! Macroexpanded: Meta releases Intermediate Graphics Library - https://news.ycombinator.com/item?id=36635526 https://news.ycombinator.com/item?id=36635526 - July 2023 (209 comments)
- FireInsight 3y agoSo, like wgpu, but in C++ and by Meta?
- itissid 3y agoIs the idea here to also compile pytorch to this(other than CUDA) so they can leverage those APIs(Vulkan, OpenCL etc) for other platforms?
- adamnemecek 3y agoThis seems to be mostly for rendering not GPGPU.
- KRAKRISMOTT 3y agoAre there any translation layers for GPU? E.g. from Vulkan to WebGPU
- Const-me 3y agoThere are some. DXVK implements D3D 9 and 11 on top of Vulkan, it’s an essential software in SteamDeck and Wine. There’re rumors modern Windows GPU drivers for Intel Ark GPUs are using that thing as well, for the implementation of D3D. MoltenVK implements Vulkan on top of Metal, MoltenGL implements GLES 2.0 on top of Metal.
- KRAKRISMOTT 3y agoAre there any that targets WebGPU? Emscripten won't translate the GPU calls unfortunately :( ANGLE does the opposite.
- modeless 3y agoIGL doesn't translate shaders, so you still need a separate solution for that. Other options would be bgfx, or sokol_gfx, or WebGPU, or Vulkan+moltenVK, or even full game engines: Unreal or Unity or Godot.