[HN Gopher] Meta releases Intermediate Graphics Library
___________________________________________________________________
Meta releases Intermediate Graphics Library
Author : pjmlp
Score : 264 points
Date : 2023-07-07 17:49 UTC (5 hours ago)
(HTM) web link (www.khronos.org)
(TXT) w3m dump (www.khronos.org)
| Keyframe wrote:
| so is this C++ only, no C?
| Buttons840 wrote:
| Is this a 1.0 release? Can we expect API stability?
| ArtWomb wrote:
| Thnx Meta! This is so cool that it's like a high-level Khronos
| release. #1 priority is I believe getting USD / Hydra rendering
| to WASM targets for browser use. But in the meantime, ray tracing
| doom ii summer of fun! ;)
|
| Also, TIL the Meta Quest 2 is running Android 12L??
| jchw wrote:
| 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.)
| Buttons840 wrote:
| I love the initial commit message: (tsuVVV)tsu IGL [?](*. *[?])
| kvathupo wrote:
| Another cheeky comment from Meta devs: The location for
| pytorch's git repo is listed as "where the eigens are valued" :
| ^)
| tnecniv wrote:
| That raises the question of where they are vectored, though!
| [deleted]
| gjstein wrote:
| 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.
| dagmx wrote:
| 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
| stevebmark wrote:
| They claim to support WebGL as a compile target, it seems like a
| pretty big missed opportunity that all of their demos don't link
| to in-browser WebGL running examples!
| TheRealPomax wrote:
| To be fair, we don't want WebGL anymore, we want WebGPU now =P
| Waterluvian wrote:
| Speak for yourself. I'm preparing for WebGFX. Need to stay
| ahead of the curve.
| dqft wrote:
| I prefer the minimalist WebG approach.
| gAI wrote:
| I like HTML. Wait, what are we talking about?
| Waterluvian wrote:
| 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.
| turtleyacht wrote:
| 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 <custom-names
| />. (Micro frontends & web components?)
|
| Then it sort of works out nicely, I think.
| TheRealPomax wrote:
| HTML is the semantics, CSS is the styling, but you need
| both. Which is why browsers come with default CSS (which
| you can unset) for everything. You get the element tag to
| say "what it is", and you get the CSS classes to say
| "what visual rules to apply".
| abathur wrote:
| This is mostly true, but the asterisks cause a little
| chaos.
|
| > HTML is the semantics ... the element tag to say "what
| it is"
|
| Maybe this is best framed as a perspective thing.
|
| "Semantic HTML" is about HTML authors using HTML elements
| in a way that is consistent with the definitions laid out
| in the specs. These definitions try to specify element
| semantics because user agents want to be able to do less-
| dumb things (things that don't work as well if HTML
| authors are constantly abusing tags for some
| presentational effect even though the semantics are weird
| or wrong).
|
| The main consequence of this is that tag semantics (from
| the UA's perspective) won't always square with what the
| author assumes it means unless they go study the spec.
| For example, it's probably not hard to go find cases
| where the <address> tag is used for the obvious thing
| from the author's perspective: marking up addresses. The
| spec, however, explicitly contradicts this surface-level
| reading:
| https://html.spec.whatwg.org/multipage/sections.html#the-
| add... (i.e., it can be "correct" for pages to contain a
| mix of addresses that do and don't have the address tag.)
| abathur wrote:
| We also have a lot of tooling that invites semantic abuse
| for presentational effect (i.e., using markdown
| blockquotes as notes, and even the fancy behavior
| browsers attach to the <details> element).
| Waterluvian wrote:
| It's a purity question. You can assign any attributes you
| want to an element. And some of them are formalized in
| various ways.
| gAI wrote:
| I'm hoping we see a move to allow the rendering of the
| webpage to be entirely up to the users. Just provide the
| data, and let me decide how I want to interact with it.
| But that would ruin SEO and Ads, so we're gonna get in a
| buncha legal battles about web scrapers instead.
| joshspankit wrote:
| By then AI will have disrupted the ad-revenue model so
| fingers crossed we get the clean data!
| Waterluvian wrote:
| "Reader Mode" is a successful example. I'm actually
| shocked it exists because of how it impedes the things
| you mention.
| zokier wrote:
| But reader mode is mostly bunch of heuristics with tons
| of ad-hoc special cases and hacks instead of relying
| documents to be well-structured. So in many ways it is
| the opposite of successful example.
|
| https://github.com/mozilla/readability/blob/main/Readabil
| ity...
| Waterluvian wrote:
| Oh true. Which kind of demonstrates the penalty for
| abusing HTML so much that it's no-longer semantically
| reliable.
| zokier wrote:
| How long can it be called abuse if it is how html has
| been used like almost entirety of its lifetime.
| WrtCdEvrydy wrote:
| WebRTX by Nvidia?
| nwoli wrote:
| WebGPU will take ages and ages to be fully usable across all
| platforms (eg old androids)
| smolder wrote:
| Taking your comment too seriously... Webgl is the more
| ubiquitous target, so I'd still prefer that when it's
| sufficient.
| astlouis44 wrote:
| Any game/3D developers here be interested in
| WebGPU/WebAssembly support for Unreal Engine 5? Along with an
| asynchronous asset loading system, for dynamic fetching of
| assets at runtime.
| omeze wrote:
| The asset stuff is the bottleneck here isnt it? We need
| browsers that support cacheing assets that are gigs in size
| astlouis44 wrote:
| Asset delivery is one of the key aspects, no doubt. Keep
| in mind that today, browsers support up to 4GB at the
| moment - but that is a limitation that won't be an issue
| eventually, and when it's lifted it will allow whatever
| local storage the user's client hardware has to be
| leveraged. This would enable AA and AAA desktop/console
| games on the web.
| zokier wrote:
| I guess website is still wip, the docs definitely seem pretty
| spartan atm
| shmerl wrote:
| Vulkan is supported.
| tmccrary55 wrote:
| Holy fuck that triangle renderer hello world example lol
| tambourine_man wrote:
| No mention of Metal
| [deleted]
| comex wrote:
| IGL does support Metal, according to the README which is linked
| at one point.
| mknapper1 wrote:
| Metal is supported, it's mentioned in the GitHub readme.
|
| https://github.com/facebook/igl
| topspin wrote:
| "IGL is designed to support multiple backends implemented on
| top of various graphics APIs (e.g. OpenGL, _Metal_ and
| Vulkan) with a common interface. "
| jauntywundrkind wrote:
| It's a Khronos press release so not carrying water for the
| opposing proprietary closed system makes sense. I wouldn't
| mention that other thing either.
| [deleted]
| jwpalmer6 wrote:
| Supported platforms from the repo README: -
| Metal 2+ - OpenGL 2.x (requires
| GL_ARB_framebuffer_object) - OpenGL 3.1+ - OpenGL
| ES 2.0+ - Vulkan 1.1 (requires
| VK_KHR_buffer_device_address and VK_EXT_descriptor_indexing)
| - WebGL 2.0
| tambourine_man wrote:
| But not in the linked article.
|
| "It supports various graphics APIs, such as OpenGL(r), OpenGL
| ES(tm), WebGL(tm), and Vulkan(r)"
|
| Seems strange that's missing from one and showing in the
| other.
| zer0zzz wrote:
| It supports Metal. In fact Metal is probably one of the reasons
| they built an adapter like this in the first place since GL
| became less of a supported thing on Darwin.
| pyrolistical wrote:
| Similar to https://dawn.googlesource.com/dawn in the sense that
| both are solving the cross platform problem. But Facebook is
| solving it at a higher level of abstraction
| ironhaven wrote:
| I hope this is a easy to use high level library that wraps Vulkan
| apis. That would help solve one big complaint that Vulkan is too
| low level for normal programmers.
| max_ wrote:
| How does this compare to Google's filament? [0]
|
| [0]: https://github.com/google/filament
| marcinignac wrote:
| Filement is full blown renderer (with shadows, advanced
| materials, effects like transparency, postprocessing) with
| platform abstractions. IGL has only the platform abstractions
| and the rest is left as an exercise for the reader.
| chmod775 wrote:
| That scene that says "Copyright (c)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
| zokier wrote:
| A rendering of a scene definitely is a work of its own has its
| own copyright, which is held by Meta. The scene is also
| attributed in the github repo license[1]. So the only problem
| here is that the _Khronos_ post is missing the attribution.
| didntcheck wrote:
| I wouldn't be so certain. Under US law that may be false due
| to it lacking originality. For example, a photograph of a
| public domain painting is itself considered public domain
| [1]. This is not the same in all countries though, e.g. not
| the UK [2]
|
| [1] https://en.wikipedia.org/wiki/Bridgeman_Art_Library_v._Co
| rel....
|
| [2] https://en.wikipedia.org/wiki/National_Portrait_Gallery_a
| nd_...
| nu11ptr wrote:
| Any ideas why it excluded Direct3D as a target? It seems to be
| the only omission. Or is OpenGL/Vulkan support sufficient to
| cover Windows perhaps?
| edflsafoiewq wrote:
| Probably. The OpenGL ES support also seems to use Google's
| Angle, which can target DirectX.
| genmud wrote:
| 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.
| fsloth wrote:
| "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.
|
| Once you get triangles in, it's up to you to make it nice using
| the shaders you write - materials and GI model of your choice.
| Animats wrote:
| > 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
| sunlit scene with no environment shaders, so it looks rather
| blah. glTF and Vulkan can do more than that, but this is all
| the test example asked for.
| n42 wrote:
| the bistro: https://developer.nvidia.com/orca/amazon-
| lumberyard-bistro
| AtNightWeCode wrote:
| You are too kind. Mid to late 90s game. What is up with those
| shadows. I have written a 3D-engine with better image quality
| than this like 20 years ago.
|
| At least it is not a teapot.
| nomel wrote:
| > I have written a 3D-engine with better image quality than
| this like 20 years ago.
|
| Well good news, it's not a 3d engine at all! It's a nice
| common API to cover all the existing graphics APIs.
| PartiallyTyped wrote:
| It's not texture, it's the lighting, it makes it feel very
| flat, especially when contrasting with RTX'd stuff which we all
| have in memory to some degree.
| jayd16 wrote:
| For better or worse, these graphics API shots are not the place
| to show cool shaders. SIGGRAPH papers are usually the same dry,
| boring test scenes. It's just the culture of it.
| whalesalad wrote:
| Counter Strike 1.6 energy
| nickpeterson wrote:
| Let's go go go!
| edflsafoiewq wrote:
| Whether you like the textures has nothing to do with whether
| the graphics library is any good.
| andai wrote:
| This is a great example of a principle I heard from
| CoderFoundry: "People are visual buyers. If it looks good,
| people assume the code is good."
| IshKebab wrote:
| Sure but it has everything to do with whether I can easily
| _tell_ that it 's good.
| wetpaws wrote:
| [dead]
| smoldesu wrote:
| The original Vulkan Demos were butt ugly too. Then 2 or 3 years
| later that super flashy DOOM remake went all-in on it and shut
| everyone up for a while.
| failuser wrote:
| 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.
| easytiger wrote:
| _Half Life 2: Lost coast_ from 2005 might be a fair
| comparison for this droll hypothetical
|
| https://youtu.be/j-Iykz0gb7Q (video uploaded 2006)
| carlosjobim wrote:
| Unreal and Quake engines handled light and textures far
| better than that.
| CuriouslyC wrote:
| Half life 2 had better looking cityscapes, so early 2000s is
| accurate.
| belthesar wrote:
| It looks about on brand with the static renders used in a lot
| of Final Fantasy games of the PS1 era, albeit with higher
| pixel density of course, so I can see the resemblance. That
| said, this is definitely doing it in engine, so while I can
| see how the GP's memory palace built that memory, you're
| definitely accurate that no game from that era was doing
| graphics like this in-engine.
| dudeinjapan wrote:
| Pre-rendered their were. Vaguely reminds me of Myst or FF7
| quality.
| failuser wrote:
| Pre-rendered? Sure. In-game? No. I think the art direction
| is half of the problem here. You can place lighting much
| better and the textures are lacking.
| n42 wrote:
| there is no "art direction" by Meta or the people working
| on this project; this is a reference scene for PBR
| pipelines.
|
| https://developer.nvidia.com/orca/amazon-lumberyard-
| bistro
| failuser wrote:
| You are right, the lighting makes the original scene look
| worse.
| ajkjk wrote:
| I like it. It manages to be on the healthy side of the uncanny
| valley, so as to feel more like an actual inhabitable world
| instead of a disconcerting knock-off of the real world.
| wlesieutre wrote:
| The textures are ok, but the lighting is super flat. People are
| used to games making at least some attempt at global
| illumination, whether it's prebaked light maps, or faking it
| with SSAO, or anything to not have surfaces be a totally
| consistent brightness across the whole thing.
| joeld42 wrote:
| Your rendering API is not going to implement GI for you, and
| having it in a sample app is kind of misleading, that's not
| really the point. It's probably a mistake to include that as
| a sample scene as it creates the impression that it's trying
| to be a game engine. A few material spheres and test meshes
| would probably be a better example.
| wlesieutre wrote:
| Agreed, just pointing out why parent commenter gets the
| "1990s/early 2000's game" impression from the screenshot
| n42 wrote:
| 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 pipeline
| with little effort, or something rivaling AAA studios with a
| lot more knowledge and effort.
|
| I guess, to make a poor analogy, your comment is sort of like
| looking at a still frame of a poorly shot movie and complaining
| that the codec is shit.
| captainmuon wrote:
| The problem is, it _implies_ that the library isn 't capable
| of higher quality. I could imagine maybe because it is a
| lowest common denominator. Or because the Metaverse is not
| focussing on high end graphics, as their previous releases
| looked poor. Or maybe this is something like VML. Designed to
| be fairly barebones and people would use it for museum
| websites and educational tools but not for graphically
| intense games.
| n42 wrote:
| I always see this idea on HN that a library, website,
| framework should be marketing itself for mass appeal and
| adoption.
|
| this is made for people building rendering engines on top
| of. if you are the software engineer with the knowledge
| necessary to do that, the screenshot is probably not going
| to influence you, because you understand what this is for.
| if you aren't, why should they be marketing to you with eye
| candy?
| Animats wrote:
| 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] Here's the
| source code for that example.[2] Rend3 is a level above WGPU;
| it deals with memory management and synchronization, so you
| just create objects, materials, transforms, and textures,
| then let the renderer do its thing. Rust handles the object
| management via RAII - delete the object, and it drops out of
| the scene.
|
| Looking at Meta's examples, there are too many platform-
| specific #ifdef lines. More than you need with WGPU. Probably
| because WGPU is usually used with something like Winit, which
| abstracts over different window systems.
|
| We'll have to wait for user reports about performance. Meta
| didn't show any video. Here's a test video of mine using
| Rend3/WGPU on a town scene comparable to the "bistro"
| demo.[3] This is a speed run, to test dynamic texture loading
| and unloading while rendering. The WGPU people are still
| working through lock conflicts in that area. The idea with
| Vulkan land is that you should be able to load content while
| rendering is in progress. For that to be useful, all the
| layers above Vulkan also have to have their locking problems
| hammered out. Most open source game engines don't do that
| yet. Unreal Engine and Unity do, which is why you pay for
| them for your AAA title.
|
| [1] https://raw.githubusercontent.com/BVE-
| Reborn/rend3/trunk/exa...
|
| [2] https://github.com/BVE-
| Reborn/rend3/blob/trunk/examples/scen...
|
| [3] https://video.hardlimit.com/w/sFPkECUxRUSxbKXRkCmjJK
| dralley wrote:
| Why does Meta _need_ an answer to WGPU? How does the
| existence of WGPU create problems for them, and how does
| this new thing solve problems that anyone else has with
| WGPU?
|
| This just feels like sour grapes about the fact that WGPU
| excluded Khronos when it was developed, so Khronos wants
| their own, with maybe a bit of promotion-driven development
| on Meta's part.
| n42 wrote:
| 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?
| Animats wrote:
| They seem to have implemented everything that the
| "bistro" scene calls for. I don't know if those hanging
| colored lights emit light, though. Rend3/WGPU doesn't
| handle large numbers of light sources yet. But you
| wouldn't see them in daylight anyway, because this is
| high dynamic range rendering, and, as in real life, those
| light are dim relative to the sun.
|
| Here's the same scene in Godot.[1] This was modified a
| bit, and has accurate values for the lamp illumination.
| So they are totally washed out by the sun.
|
| And here it is in several other renderers, with a
| video.[2]
|
| The original scene was in .fbx, from Amazon's
| "Lumberyard" project. [3] That project started as the
| Crysis engine, was bought by Amazon, spun off as open
| source, was renamed Open 3D Engine, and is still getting
| Github changes, so it's not dead.
|
| There are many open source game engines. Most of them get
| stuck at "mostly works, not ready for prime time". That's
| where the problems get hard and fixing them stops being
| fun.
|
| [1] https://github.com/godotengine/godot/issues/74965
|
| [2] https://www.ronenbekerman.com/orca-amazon-lumberyard-
| bistro/...
|
| [3] https://developer.nvidia.com/orca/amazon-lumberyard-
| bistro
|
| [4] https://en.wikipedia.org/wiki/Amazon_Lumberyard
| bsaul wrote:
| who would benefit from using this ? People building 3D engines
| such as unity or unreal ?
| digdugdirk wrote:
| Darn, I opened the link and saw it was using Python. Sadly that
| seems to just be for the install process, for whatever reason.
|
| Does anyone have any recommendations for an intermediate graphics
| library that uses Python and supports compiling your code to a
| WebGL target?
|
| I'm interested in exploring SDF functions in a parametric CAD
| context, but coming from a Mechanical Engineering background. Not
| having to learn a new programming language for a side curiosity
| would be ideal.
| bmitc wrote:
| Python has wgpu wrappers. Why do you want to use Python though
| for such a heavy graphics program?
| digdugdirk wrote:
| Purely because I already know it well enough to be semi-
| dangerous. My day job is designing physical goods, I don't
| have the time to learn anything new just to satisfy my
| curiosity with signed distance fields.
| joeld42 wrote:
| 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.
| KRAKRISMOTT wrote:
| What about
|
| https://github.com/gfx-rs/wgpu
|
| It is written in Rust
| xpe wrote:
| wgpu is great and worth considering
| Narishma wrote:
| It seems to not support as many back-ends as IGL, for example
| GL ES 2.0 and OpenGL 2.x.
| bogwog wrote:
| 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.
| j1br wrote:
| what does intermediate graphics library mean?
| [deleted]
| s1mon wrote:
| I think this may be useful, but part of me immediately thinks of
| this XKCD about standards: https://xkcd.com/927/
| MikeTheRocker wrote:
| Oh neat! I used this when I worked at Meta about a year ago. It
| didn't support Vulkan at the time, so it's great to see they
| added that. It's nice that IGL abstracts the CPU-side code, but
| you still end up writing shaders for each platform.
| [deleted]
| junon wrote:
| Any reason this is better over BGFX?
| kkukshtel wrote:
| Having to do a lot of your own switching at the implementation
| level seems annoying, I'm surprised there isn't a more simple API
| on top of that to give you the correct impl directly.
| tppiotrowski wrote:
| Can someone explain the significance of this? I do WebGL
| development and I believe there is already an intermediate layer
| called Angle that WebGL compiles to. The Angle layer decouples
| the hardware from the software and allows hardware vendors to
| develop drivers that run Angle and shader languages to target
| Angle without the two needing to know anything about each other.
| (Not sure if that's right?)
|
| This seems like another intermediate decoupling layer?
| komadori wrote:
| ANGLE is a portability layer for Windows which provides the
| OpenGL API on top of DirectX, since Windows clients aren't
| guaranteed to have good OpenGL drivers installed. WebGL is
| itself closely related to OpenGL so it makes sense to build it
| on top of that.
| monocasa wrote:
| Angle is ultimately a OpenGL|ES implementation on top of other
| APIs since webgl is pretty close to GLES, but desktops don't
| typically implement GLES.
|
| This (IGL) is more a layer sitting on top between your app and
| the system provides API since pretty much every system has a
| different blessed API these days: Browser:WebGL/WebGPU,
| Windows:DirectX/Vulkan, Mac:Metal, Linux/Android:Vulkan,
| Consoles: Proprietary APIs like NVN/GNM/AGC/DX12 with a lot of
| extensions.
|
| Just about every major cross platform 3D graphics app/engine
| has a layer like IGL, this just seems to be an attempt to make
| Meta's a standard.
| cobertos wrote:
| So then the full stack for using IGL in browser (on Windows
| at least) would be App Code -> IGL -> WebGL -> ANGLE ->
| DirectX -> Hardware device?
|
| Owie
| hgs3 wrote:
| 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.
| hoten wrote:
| I think for the same reason WebGPU did-there are tons of cruft
| in the opengl API and it doesn't really represent how the
| hardware works anymore.
| nine_k wrote:
| OpenGL is not the most straightforward, not the most compact,
| not the most ergonomic, not the most modern API. It's one of
| the most widespread though.
|
| Meta produced this library not for the benefit of general
| public. They produced it to make their own development easier
| and faster, and internally they are unlikely to benefit from
| OpenGL's ubiquity or backwards compatibility. Then they
| _released_ the library for the benefit of general public. This
| is very nice, thanks! But we are not the main target audience.
| ozarker wrote:
| Abstractions over the low level apis (opengl, directx, vulkan,
| metal) have gotten a bit popular in recent years. I think some
| driving forces behind it are inconsistent support of some apis
| on some platforms (i.e. opengl on macos) and maybe also a
| desire to support some of the newer apis (Vulkan or dx12)
| without going all in due to their complexity/verbosity.
|
| I've been playing with wgpu-rs, bgfx, and a couple others in
| the past and they work pretty well for the most part. At this
| point I think I'd still rather choose just Vulkan for a new
| project though.
| kevingadd wrote:
| Nobody wants to use OpenGL these days, it's a miserable API
| with 30 years of baggage and complex vendor-specific behavior
| TOGoS wrote:
| 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.
| [deleted]
| vitaminka wrote:
| trying to build this rn, and the download scripts has already
| pulled like a gigabyte of dependencies wth
|
| edit: it's already like 2 gb
| isodev wrote:
| It doesn't seem to have Metal support unfortunately. Otherwise
| looks nice, could be fun for small pet projects.
| chunkyguy wrote:
| https://github.com/facebook/igl/tree/main/src/igl/metal
| calibas wrote:
| Says it supports Metal 2+
|
| https://github.com/facebook/igl
| pavlov wrote:
| 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 for the "Tiny" sample? By manually adding a third
| parallel implementation with "#elif USE_METAL_BACKEND"
| everywhere?
|
| [1]
| https://github.com/facebook/igl/blob/main/samples/desktop/Ti...
| bogwog wrote:
| 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.
| Jasper_ wrote:
| Even outside of platform-specific stuff, I'm seeing it all
| over the core rendering code. I'm not impressed. https://gith
| ub.com/facebook/igl/blob/main/samples/desktop/Ti...
| bogwog wrote:
| You're right, that's weird. The particular snippet you
| linked to isn't that egregious, it just creates a dummy 1x1
| texture for some reason, and changes a hint. A lot of stuff
| in that file though is branched on that opengl flag. The
| `render` function is a huge mess, _and_ it doesn 't even
| seem like that demo supports Metal at all.
|
| But tbf also, I'm just skimming the code base. Maybe
| they'll publish some better docs later that explain/justify
| these things.
| Jasper_ wrote:
| It's a very weird one.
|
| createRenderPipelines uses the branch to add #version 460
| to the beginning of shaders (one would think the platform
| backend could do that for you, also this won't support
| GLES2 or GL3), and also makes the programmer build a
| sampler/uniformblock mapping table.
|
| That's... perhaps needed if you're on GL3 because you
| don't have access to binding=N in the shading language
| and you don't want to do any shader parsing in the
| backend, but also, you're forcing it on GL 4.6, so...
| huh? Just use explicit binding in the shader and the
| binding index APIs.
|
| The render function uses USE_OPENGL_BACKEND to adapt for
| the -1...1 clip space. Sure, again, glClipControl is more
| modern than your minspec, but you're _already_ forcing GL
| 4.6, so WTF. Also, it 's not hard to write
| device_->adjustProjectionMatrixForNativeClipSpace(); that
| does a matrix mul.
|
| It also makes the shadow render target have a color
| attachment (wtf? depth-only targets are supported just
| fine in GLES2/GL3 to my knowledge), and it also...
| doesn't use an index buffer when rendering? (EDIT: This
| is because it's using a 32-bit index buffer, which GLES2
| doesn't support. But it's a much better idea to split it
| into multiple 16-bit index buffer draws if required than
| drop the index buffer entirely... also, you know, shaders
| have 4.6). I give up trying to understand what's going
| on. Oh, and despite building the uniformblock mapping
| table from before, you still have to use
| glPipelineState->getUniformBlockBindingPoint? What on
| earth?
|
| This does not impress me.
| yazzku wrote:
| Same impression here. The triangle example isn't better than a
| raw Vulkan one. Then I thought maybe it'd have more value in
| larger applications, but the Bistro demo is just the same kind
| of leaky abstraction code all over the place. The GUI is also
| just ImGUI. I don't know what value this library provides.
| seertaak wrote:
| 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 get abstractions for the stuff that
| really is similar, like command buffers, camera control etc.
|
| I think the API is well designed, and nails flexibility
| together with performance, at the cost of requiring to have, at
| least, expert knowledge in one library. After that I would get
| chatgpt to convert my shaders to metal, Vulkan, etc.
| pavlov wrote:
| 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.
| zokier wrote:
| 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?
| fidotron wrote:
| 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.
| bmitc wrote:
| I have been researching, and it is my current understanding
| that this is the approach that WebGPU takes, specifically
| wgpu.
|
| Is that right? I have been thinking that wgpu is the best
| choice available for intermediate cross platform graphics one
| level below something like Skia and one level above Vulkan,
| OpenGL, DirectX, and Metal.
| usrusr wrote:
| Reads to me like the usual collection of utility/glue that
| people build for their own needs? Those usually don't get
| open sourced, but it's also not wrong to do that. At least if
| you can resist the urge to announce it as the graphics API to
| end all graphics APIs...
| nomel wrote:
| > can resist the urge to announce it as the graphics API to
| end all graphics APIs
|
| Please quote the text that made you believe this. It's a
| very negative take.
| usrusr wrote:
| I did not intend to imply that they did. Sorry if that
| hasn't been clear. I was considering adding a few words
| in that direction but went with brevity.
| Jasper_ wrote:
| 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.
| PcChip wrote:
| ImGui spotted, someone should tell ocornut to add it to the list!
|
| https://github.com/ocornut/imgui/wiki/Software-using-dear-im...
| codelord wrote:
| 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.
| vitaminka wrote:
| ye, it's approaching 50% of LOD of a vulkan hello triangle
| shaunxcode wrote:
| but its called tiny!
| seertaak wrote:
| ... for metal, gl, and Vulkan.
|
| Sorry but this is simply par for the course for any of the
| above.
|
| You can certainly wrap a lot of that stuff, but you need to
| make assumptions, and the person that uses likely is writing
| demanding app, and they want full control over literally
| everything - but they also would like to cut time to port to
| Linux by half (say).
| n42 wrote:
| 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.
| terracottalite wrote:
| Just noticed the installation command "python3 deploy_content.py"
| installs the scene and not the library. Don't run that one if you
| don't want do download 2G of stuff, just run the deploy_deps one.
___________________________________________________________________
(page generated 2023-07-07 23:00 UTC)