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

121–130 of 221 posts

Re: Meta releases Intermediate Graphics Library

#121

Post by Jasper_ »

fidotron wrote: post #67
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 u…

You can build far better abstractions than what we have here. A lot of games that support more than two platforms have graphics abstractions that leak less than this.

Re: Meta releases Intermediate Graphics Library

#122

Post by Waterluvian »

turtleyacht wrote: post #117
Waterluvian wrote: post #107

Earlier quoted context omitted.

Tangent you got me thinking about: HTML clicked for me one day when I mentally decoupled the hypertext from the actual browser rendering. So many of us think HTML and imagine the point is to render a webpage. But HTML describes the semantics, topology, and content of a document. It’s 100% valid to “render” HTML in some other format like a PDF or an mp3.

Is it kind of a compromise then to "tag" HTML with classes for CSS? CSS doing the "rendering," like laying out mobile-responsive versus desktop. I wonder how we would separate out explicit class names from HTML, unless the tags themselves are . (Micro frontends & web components?) Then it sort of works out nicely, I think.

It’s a purity question. You can assign any attributes you want to an element. And some of them are formalized in various ways.

Re: Meta releases Intermediate Graphics Library

#123

Post by n42 »

codelord wrote: post #88

385 lines for a triangle: https://github.com/facebook/igl/blob/main/samples/desktop/Ti... When you are trying to sell a wrapper you want your hello world example as small as possible not as comprehensive as possible.

if you just want to draw a triangle, there's higher level libraries for that purpose. this is a low level library built to abstract (but map as close as possible to) modern backends (Vulkan, DX12, etc). the idea with these backends is to give precise control over the pipeline - that kind of precise control does not lend itself to the higher level abstractions you are looking for.

that said, it's not like this scales linearly so that 1,000 triangles is 385,000 lines of code. there's a lot of plumbing to setup the pipeline for your application's specific use case.

again, if your use case does not require the flexibility, look elsewhere.

Re: Meta releases Intermediate Graphics Library

#124

Post by dagmx »

gjstein wrote: post #119

What sort of Docker support will this have? I have a very shaky setup right now to run Unity headless that requires OpenGL and VirtualGL. It feels like that pipeline won’t work forever and am looking for alternatives.

This wouldn’t help you since Unity wouldn’t target it.

Unless you were to switch to a homegrown solution that would make use of this

Re: Meta releases Intermediate Graphics Library

#125

Post by jchw »

Interesting. Since it does not include windowing integration at all, it looks like you pretty much have to do the glue for each platform you support. This isn't too bad, but it could be better with adapters for common choices for windowing and context management (SDL, GLFW, etc.) Speaking of which, it seems the Linux path assumes X11 for now. Wonder if EGL/Wayland works at all at the moment, but I'm not at a desktop computer to give it a shot.

That said, all of this is relatively mundane, at the end of the day. I'm curious to try it out and see how the ergonomics/performance is. It honestly doesn't look too bad and it's kind of a good sign that a large amount of the triangle example is just windowing, because the actual rendering is relatively simple and succinct for a modern graphics API. I'd like to have an adapter for SDL2/3 and support for Wayland on Linux but otherwise it looks promising. Compared to other abstraction layers (like bgfx) it appears a bit more forward-thinking in some superficial regards at the very least. (Seeing a command queue abstraction in hello world makes me hopeful, anyways.)

Re: Meta releases Intermediate Graphics Library

#127

Post by chmod775 »

That scene that says "Copyright ©Meta" is actually a CC-BY scene from Amazon Lumberyard.[1]

I'm not sure rendering it entitles you to slap your own copyright notice on it while disrespecting the CC-BY. Further, the interface shown is just plain ImGui. That'd be as if I made an image viewer using off-the-shelf parts, displayed some other artist's work in it, then pretended I own the copyright to what my software now displays.

Obviously I don't. The very purpose of this software and image viewers alike is to display other people's work. What Meta owns is software, not the output it may produce.

These corporations are way too eager to slap their copyright notices on everything. It's definitely not a harmless mistake when those same corporations own literal armies of lawyers who protect their employer's "interests" while not necessarily understanding processes happening in other parts of the company.

In general anyhow. In this case it's luckily just Goliath vs. Goliath and not some poor indie developer getting shafted and robbed of credit.

[1] https://developer.nvidia.com/orca/amazon-lumberyard-bistro

Re: Meta releases Intermediate Graphics Library

#128

Post by kevingadd »

hgs3 wrote: post #66

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 extensi…

Nobody wants to use OpenGL these days, it's a miserable API with 30 years of baggage and complex vendor-specific behavior

Re: Meta releases Intermediate Graphics Library

#129

Post by TOGoS »

hgs3 wrote: post #66

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 extensi…

Edit: I misread your question, so responded with a link to this article answering "why WebGPU": https://cohost.org/mcc/post/1406157-i-want-to-talk-about-web...

It does seem like kind of a mess. Unlike WebGPU, though, it doesn't sound like Meta's thing is much of an improvement.

Re: Meta releases Intermediate Graphics Library

#130

Post by pavlov »

seertaak wrote: post #113
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…

I disagree. Most of what's platform specific is stuff like shaders, and host window stuff. I definitely do NOT want a graphics layer owning that - I may want to control the type of os window (say, for an audio plugin). I already know gl shaders, and metal is really similar, a new 'common denominator' shading language would just be another language - with less docs, stackoverflow posts, etc. And on the other hand, you…

I think the documentation could be a lot clearer about this. I can understand if the goal is for the abstraction to be thin and unopinionated, and that means you have to be an expert in each backend. But they don’t seem to explain this very well.
Post reply on HN