Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Meta releases Intermediate Graphics Library

khronos.org

Post reply on HN
Print view View original

61–70 of 221 posts

Re: Meta releases Intermediate Graphics Library

#61

Post by zokier »

pavlov wrote: post #36

For an intermediate library, it doesn't actually seem to be very much backend-independent. At least the desktop sample [1] has a disappointing amount of code paths with parallel implementations for OpenGL and Vulkan, switched at compile time using "#if USE_OPENGL_BACKEND". I guess this means that this sample will use OpenGL rather than Metal on macOS? They claim there's a Metal backend, but how would one enable that…

There is ios/Metal sample here that seems to support opengl: https://github.com/facebook/igl/blob/main/samples/ios/snapsh...

Thr shaders are backend specific but rest is mostly generic?

Re: Meta releases Intermediate Graphics Library

#62

Post by Narishma »

KRAKRISMOTT wrote: post #47
joeld42 wrote: post #43

If you're looking for something like this, Sokol is a much simpler alternative: https://github.com/floooh/sokol It doesn't support vulkan though, but if that's important to you you're probably much better off just using vulkan directly since it's supported on all the major platforms.

What about https://github.com/gfx-rs/wgpu It is written in Rust

It seems to not support as many back-ends as IGL, for example GL ES 2.0 and OpenGL 2.x.

Re: Meta releases Intermediate Graphics Library

#64

Post by n42 »

Animats wrote: post #53
n42 wrote: post #16

Earlier quoted context omitted.

the screenshot could/should probably be better, but that doesn't mean the library is incapable of producing higher quality renders. I haven't dug in, but I am assuming this is basically Meta's WGPU. if so, these sorts of libraries are low level libraries abstracting different platforms that can be used to build high quality render pipelines on top of that can run anywhere. you could build an N64 quality rendering pip…

It does seem to be Meta's answer to WGPU. The picture looks like they didn't have automatic tonemapping, the rendering equivalent of auto exposure control. So the picture is too dim. I brought it into a photo editor, saw that the top third of the intensity space was empty, used "Levels", and it looked much better. That's a standard glTF test scene, called "bistro". Here's the same scene, rendered with Rend3/WGPU.[1]…

hi John! you know a lot more about this stuff than I do. is it possible they just haven't implemented a full PBR pipeline for this demo/screenshot, or do you think this (the differences in the two screenshots) is more an indication of what would likely be areas for future development?

Re: Meta releases Intermediate Graphics Library

#65

Post by Jasper_ »

bogwog wrote: post #56
pavlov wrote: post #36

For an intermediate library, it doesn't actually seem to be very much backend-independent. At least the desktop sample [1] has a disappointing amount of code paths with parallel implementations for OpenGL and Vulkan, switched at compile time using "#if USE_OPENGL_BACKEND". I guess this means that this sample will use OpenGL rather than Metal on macOS? They claim there's a Metal backend, but how would one enable that…

Those seem to be mainly platform-specific initialization things, like creating a window and rendering context. That's pretty normal for these types of rendering libraries which don't include a full blown portable windowing API. If you use something like SDL, you'll probably be able to minimize the platform-specific stuff.

Even outside of platform-specific stuff, I'm seeing it all over the core rendering code. I'm not impressed. https://github.com/facebook/igl/blob/main/samples/desktop/Ti...

Re: Meta releases Intermediate Graphics Library

#66

Post by hgs3 »

I understand why WebGPU defined a new API since it's primarily intended for web browsers, however, in this case why create a new API? Why not implement the OpenGL API? Essentially this could have been an OpenGL wrapper over the lower-level API's, e.g. over Vulkan, Metal, and Direct3D 12.

OpenGL has the advantage of being an open standard. Did Meta need custom behavior? If so, OpenGL already has a well-defined extension mechanism.

Re: Meta releases Intermediate Graphics Library

#67

Post by fidotron »

pavlov wrote: post #36

For an intermediate library, it doesn't actually seem to be very much backend-independent. At least the desktop sample [1] has a disappointing amount of code paths with parallel implementations for OpenGL and Vulkan, switched at compile time using "#if USE_OPENGL_BACKEND". I guess this means that this sample will use OpenGL rather than Metal on macOS? They claim there's a Metal backend, but how would one enable that…

This looks like what happens when the "All abstractions are leaky" crowd go too far. It's an absence of abstraction to the point that the intermediary layer is not helpful enough, and will simply end up hidden behind another layer of obfuscatory gunk.

Graphics people need to face the fact that writing optimised cross platform renderers is not something that can be solved by divide/conquer into layers in this bottom up way anymore, instead you need to architect the data flow of the renderer and implement platform specific/optimal approaches for each sub part of that, which are so specific that this sort of wrapper would not help. This isn't exactly far removed from the pyramids -> gothic cathedral comparison.

Re: Meta releases Intermediate Graphics Library

#68

Post by CuriouslyC »

failuser wrote: post #10
genmud wrote: post #3

Not trying to shit on anyone, but that screenshot reminds me of 1990s/early 2000's games. I'm sure there has been a ton of work that went into it, but having some better textures or highlighting the usability would go a long way. Just based on the screenshot, I am not sure that I would even bother to dig too deeply into the library.

Now look at real 1990s/early 2000’s screenshots. You memory is deceiving you. This screenshot is far from current AAA games, but there is no way to render such a scene in a game made for 2000 hardware.

Half life 2 had better looking cityscapes, so early 2000s is accurate.

Re: Meta releases Intermediate Graphics Library

#69

Post by bogwog »

joeld42 wrote: post #43

If you're looking for something like this, Sokol is a much simpler alternative: https://github.com/floooh/sokol It doesn't support vulkan though, but if that's important to you you're probably much better off just using vulkan directly since it's supported on all the major platforms.

Sokol also provides a solution for shader cross-compilation (https://github.com/floooh/sokol-tools/blob/master/docs/sokol...), so you only need to write your shaders once no matter if you're targeting OpenGL, Metal, or DirectX.

There are other tools you could use out there with IGL, but Sokol's solution streamlines the whole process.

Re: Meta releases Intermediate Graphics Library

#70

Post by n42 »

Animats wrote: post #60
fsloth wrote: post #20

Earlier quoted context omitted.

"Just based on the screenshot, I am not sure that I would even bother to dig too deeply into the library." Adding any PBR materials as samples would have been the wrong choice, since those are not hardware or graphics api dependent, and are always for the implementor to implment by themselves. You don't want a graphics api to look nice at this abstraction level. You get access to device resources, shader API etc. Onc…

> Adding any PBR materials as samples would have been the wrong choice, since those are not hardware or graphics api dependent, and are always for the implementor to implment by themselves. That "bistro" image is all PBR materials, represented in glTF. It's supposed to look the same for all standards-compliant glTF renderers, and it pretty much does. I posted the same scene in another renderer above. It's a brightly…

the bistro: https://developer.nvidia.com/orca/amazon-lumberyard-bistro
Post reply on HN