15 ms·

3D Portability Initiative

91 points by ooyy 10y ago

chubs 10y ago
Isn't the de-facto answer to this 'Unity' or 'Unreal Engine' ?
- khedoros1 10y ago
  Those seem like de-facto work-arounds for the absence of 3D portability. Using an engine locks you into the constructs of that engine, though. It seems like it'd be kind of backwards to do that if you're using an API to get closer to the hardware, for performance purposes.
  - mrec 10y ago
    And a full-blown game engine is a very heavyweight solution for a lot of lightweight 3D problems, especially if you're looking at Web delivery. (One of the stated goals for this initiative is a next-gen WebGL.)
  - K0SM0S 10y ago
    Could work as a preprocessor on the dev side for quickly outputting each native API code from a more general form, probably designed as a superset above SPIR-V (bound to be a bit more verbose than pure native code, but even a 100% larger project is better than 2+ discrete ones). Maybe even JIT if they can essentially extend LLVM (or at least generate direct hooks through the preproc). I don't see much 'impossible' on the tech front, however politically... it's just my intuition but somehow I see Microsoft and Apple not cooperating much beyond WebGL efforts, and actually baking progress into their own proprietary APIs/platforms. The matter of the fact is that as of today it's still profitable to develop 3D applications even under the restrictions posed by proprietary APIs, and OpenGL/Vulkan are still optionally usable too (though generally worse performing on Windows or Mac, notably because there's no efforts by MS or Apple to help). So there's really not much incentive for opened platforms. Essentially users are absorbing the costs (more money and/or less features, e.g. cross-platform game which sunk costs in porting/licenses rather than content), but so far don't complain much about it (probably because there's no comparison to be made in the real-world with opened platforms since none of the commercially successful OS is truly open at the consumer level). As so often, nice spirit by Khronos, unfortunately they're so lonely on that road, surrounded by giants with conflicting interests and much wider preoccupations (read: emphasis on building an ecosystem + verticality of control). See Surface lineups, or even Google, now making Pixels. Actually the latter is a prime candidate to further Khronos' goals, I wonder what the 3D API landscape will look like on their alleged x86 efforts.
- pfranz 10y ago
  Unless I'm misunderstanding you, those aren't the answer. I think the article title is a bit too vague. They're talking about probability of 3D for hardware accelerated rendering. Unity and Unreal Engine are complete game engines. Hardware accelerated rendering gets a lot of focus on games, but is used quite a bit elsewhere; apps for video editing, sound editing, 3d content generation (Maya, Houdini), CAD (the originator of OpenGL), and I think the UI on all major platforms are all hardware accelerated. Also, many game studios write their own engines in house because those game engines are big and a lot of "baggage" can come with that.
- pjmlp 10y ago
  Yes they are. HN folk doesn't like to hear it, but that is how the game industry has worked since the early 80's where each gaming platform was a special snowflake. There is a thriving industry of game engines and middleware that grew from there and the majority of game studios doesn't spend more than the time required to select which middleware they want to use. Even for those that build their own engines, the graphics abstraction layer is a tiny portion of the engine, versus everything else that isn't covered by Khronos standards. Meaning GUI support, font, texture and shaders loading, mesh rendering, scene descriptions, game editors,.... Usually adding a new rendering backend to an engine doesn't take more than around one month, the biggest time slice being consumed by time to first triangle. Given that Vulkan specification already has 74 extensions and is only at version 1.0.42, already bringing up the fun of "write once, port multiple times" from OpenGL, I am not confident this is going anywhere. https://www.khronos.org/registry/vulkan/specs/1.0-extensions/html/vkspec.html https://www.khronos.org/registry/vulkan/specs/1.0-extensions...
  - exDM69 10y ago
    > Given that Vulkan specification already has 74 extensions and is only at version 1.0.42, already bringing up the fun of "write once, port multiple times" from OpenGL This is a dishonest and decieving way of putting things. The difference between Vulkan and OpenGL here is that most of the functionality extensions are software only additions and are available everywhere with up-to-date drivers. Mobile is a bit of a pain point because they don't get driver updates as nicely. If you look at Vulkan extensions qualitatively (not just the numbers) you'll see that it's nothing at all like the OpenGL extension mess. The vast majority is window system integration (WSI) and extenral memory and multi device stuff. Platform specific stuff which would exist in WGL/GLX/EGL for OpenGL and can't reasonably be put in "core" (because everyone must support all of core). It was perhaps a mistake to attempt to release Vulkan 1.0 as early as they did, it might have been a better idea to put out 0.9 beta version and accept that there will be API changes. However, very few changes have been made to the core apis.
    - pjmlp 10y ago
      It is not being dishonest as alternative APIs don't suffer from extension explosion. Also I don't believe that by following this path Vulkan will be any better than OpenGL, ES, WebGL. Let's see how many Vulkan 2.0 will have and of what kind.
- exDM69 10y ago
  Yes, but Unity, Unreal and the other engines need a 3d API to run on. They can use Vulkan, D3D or Metal on native desktop/mobile platforms but that's already 3 separate backends and there's no good API for the browser (WebGL being suboptimal in many ways and about 15 years behind the native platforms).
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
33a 10y ago
Why not just port some subset of Vulkan to Apple?
- exDM69 10y ago
  There is a commercial, proprietary Vulkan implementation (called MoltenVk) that runs on top of Apple's Metal. This is not a technical issue, but a political one. Apple has decided not to allow Vulkan in their walled garden.
cordite 10y ago
Isn't the industry getting a little fatigued by now?
mintplant 10y ago
Huh. I thought Vulkan was supposed to be the new portable 3D standard from Khronos. Now we need a new new standard on top of the old new standard?
- detaro 10y ago
  Supposed to be, but Apple and probably parts of Microsoft don't want to play ball.
  - ClassyJacket 10y ago
    So why would they play ball with this?
    - detaro 10y ago
      I understand this proposal as suggesting to build an API that can be implemented efficiently on top of the vendor-specific APIs, without the vendors doing anything. E.g. similar to how the ANGLE library offers OpenGL on top of Direct3D APIs, for Windows PCs without/with bad OpenGL support.
badsectoracula 10y ago
Is Khronos going to implement something? Because AFAIK they only write the specs for others to implement them - so it is up to each vendor to make the API available. If Apple and Microsoft aren't going to implement Vulkan, why would they implement something else?
- pzone 10y ago
  The point of Khronos was never to implement anything. It serves as a coordination mechanism among industry players, where the specs for OpenGL, Vulkan etc. are debated, hashed out and formalized. I'm not exactly sure what your last question means. Vulkan will be available on Windows. I think it may be more correct to say NVidia/AMD/Intel are implementing Vulkan APIs in their graphics drivers and Windows will expose the API to applications. At the same time, they do seem to see benefits in creating other APIs at the same time, i.e. DirectX 12 and Metal. So we'll see I guess.
- slimsag 10y ago
  It could be that this is a specification on how to implement some new API which operates consistently across the trio; i.e. "this function invokes X with parameters Y in Vulkan, X with Y in Metal, X with Y in DirectX" since that is no trivial task to do right and extensively. But I'm sure that'd also include a real implementation.. so.. yeah.
- exDM69 10y ago
  Recently, Khronos has been also implementing some of the infrastructure, like the Vulkan loader and validation layers, the GLSL-to-SpirV compiler (glslang) and the SpirV tools which are open source and developed by LunarG and others. The actual driver parts are written by hardware vendors (IHV's in Khronos-speak) but there's a push to put less stuff in the drivers and more stuff that is common to all vendors. Not sure about this project, though. Looks to me like an effort to get the relevant parties discuss this in GDC and see what comes up.
- theandrewbailey 10y ago
  Khronos is an industry standards group. It is composed of companies that implement Khronos APIs. So yes, in a way.
daurnimator 10y ago
I'm not sure why Vulkan couldn't work on windows: isn't it mostly in the hands of driver developers (i.e. Nvidia/AMD) rather than Microsoft?
- detaro 10y ago
  Microsoft is not just Windows, some mobile devices and more importantly the XBox as well. On Windows, the GPU makers can (and do, at least partially/beta) provide drivers with Vulkan support, yes.
- cma 10y ago
  It does work on Windows. Not sure about Windows Phone though.
  - pjmlp 10y ago
    UWP only allows for DX, but one can built other APIs on top, e.g. ANGLE for OpenGL support.
phonon 10y ago
This sounds like a response to Apple's WebGPU initiative?[1] https://news.ycombinator.com/item?id=13593272 https://news.ycombinator.com/item?id=13593272
- yousry 10y ago
  The emulation cost for non Apple Systems would be enormous to implement this solution (= SLOW). SPIR could be used native on most devices.
yousry 10y ago
This proposal makes much more sense than Apples "Metal Only" solution (https://webkit.org/blog/7380/next-generation-3d-graphics-on-the-web/ https://webkit.org/blog/7380/next-generation-3d-graphics-on-...). I liked Metal at the beginning but over time it turned out that it is just another OpenGL/DX flavor with the same old driver/performance problems. Also using SPIR as IL allows the use of the preferred shader language. WebGL Next is about parallelism and abstraction, otherwise there would be absolutely no benefit.
- DowsingSpoon 10y ago
  Can you comment a bit more on the limitations of Metal? I've been spending the last few days reading through the docs and learning how to use Metal. So, I'm curious what you (and anyone else, I guess) perceive its shortcomings to be.
  - yousry 10y ago
    My personal biggest concern was the re-invention of OpenGL/DX features without the proper knowledge why and how these features can be used. For example I never managed to apply a skeletal animation to a indirect indexed draw call or use transform feedback loops for ray-casting or other deferred shading techniques.
Animats 10y ago
Who needs a "next generation WebGL?" It's hard to find an interesting or useful WebGL site. There are plenty of demos and ads, but few sites worth visiting. Here, go shoot some zombies. http://www.y8.com/games/abandoned_island http://www.y8.com/games/abandoned_island That's about as good as it gets.
- legulere 10y ago
  Google maps doesn't work without WebGL, and some other map related websites like mappilary.
  - Animats 10y ago
    Right, but the proposal is about an API which lets web applications do shader-language stuff beyond the level of WebGL. Is this really necessary?
    - deafcalculus 10y ago
      The new APIs (Vulkan, DX12, Metal) are mostly about performance. I can't think of any major thing that you can't implement in WebGL. But, a portable 3d API would be awesome for native apps. And, why not have that be the 3d API for the web too? Like WebGL / OpenGL ES 2.
  - deleted 10y ago
    [deleted]
  - mirimir 10y ago
    It seems to work in Firefox with WebGL disabled.
  - TeMPOraL 10y ago
    Why on Earth (no pun intended) should Google Maps require WebGL? Another example of people losing focus on providing actual value with the products they make.
    - 10y ago
cmrx64 10y ago
In accordance with federal law (http://n-gate.com/ http://n-gate.com/), I'm obligated to point out this Rust library, which does exactly this! https://github.com/gfx-rs/gfx https://github.com/gfx-rs/gfx. I worked on the second version of the API in 2014 and it's only gotten better since. The major thing this particular abstraction still doesn't solve is shaders: you need to write a shader per backend you support. Shader portability is a bit of a sticky problem.
sipos 10y ago
This seems like a better approach than Apple's WebGPU in that it is more realistic (depends on using a usable subset of the three APIs that is reasonably common) and, not started by the same company that is the biggest obstacle to cross-platform graphics APIs in the first place. It seems unfortunate that it is necessary though. It is clear that neither Metal or DirectX can be the cross-platform API we'd all like so, it seems a shame Microsoft and Apple can't just support Vulkan.

91 points by ooyy 10y ago

chubs 10y ago

Isn't the de-facto answer to this 'Unity' or 'Unreal Engine' ?

khedoros1 10y ago
Those seem like de-facto work-arounds for the absence of 3D portability. Using an engine locks you into the constructs of that engine, though. It seems like it'd be kind of backwards to do that if you're using an API to get closer to the hardware, for performance purposes.
- mrec 10y ago
  And a full-blown game engine is a very heavyweight solution for a lot of lightweight 3D problems, especially if you're looking at Web delivery. (One of the stated goals for this initiative is a next-gen WebGL.)
- K0SM0S 10y ago
  Could work as a preprocessor on the dev side for quickly outputting each native API code from a more general form, probably designed as a superset above SPIR-V (bound to be a bit more verbose than pure native code, but even a 100% larger project is better than 2+ discrete ones). Maybe even JIT if they can essentially extend LLVM (or at least generate direct hooks through the preproc). I don't see much 'impossible' on the tech front, however politically... it's just my intuition but somehow I see Microsoft and Apple not cooperating much beyond WebGL efforts, and actually baking progress into their own proprietary APIs/platforms. The matter of the fact is that as of today it's still profitable to develop 3D applications even under the restrictions posed by proprietary APIs, and OpenGL/Vulkan are still optionally usable too (though generally worse performing on Windows or Mac, notably because there's no efforts by MS or Apple to help). So there's really not much incentive for opened platforms. Essentially users are absorbing the costs (more money and/or less features, e.g. cross-platform game which sunk costs in porting/licenses rather than content), but so far don't complain much about it (probably because there's no comparison to be made in the real-world with opened platforms since none of the commercially successful OS is truly open at the consumer level). As so often, nice spirit by Khronos, unfortunately they're so lonely on that road, surrounded by giants with conflicting interests and much wider preoccupations (read: emphasis on building an ecosystem + verticality of control). See Surface lineups, or even Google, now making Pixels. Actually the latter is a prime candidate to further Khronos' goals, I wonder what the 3D API landscape will look like on their alleged x86 efforts.
pfranz 10y ago
Unless I'm misunderstanding you, those aren't the answer. I think the article title is a bit too vague. They're talking about probability of 3D for hardware accelerated rendering. Unity and Unreal Engine are complete game engines. Hardware accelerated rendering gets a lot of focus on games, but is used quite a bit elsewhere; apps for video editing, sound editing, 3d content generation (Maya, Houdini), CAD (the originator of OpenGL), and I think the UI on all major platforms are all hardware accelerated. Also, many game studios write their own engines in house because those game engines are big and a lot of "baggage" can come with that.
pjmlp 10y ago
Yes they are. HN folk doesn't like to hear it, but that is how the game industry has worked since the early 80's where each gaming platform was a special snowflake. There is a thriving industry of game engines and middleware that grew from there and the majority of game studios doesn't spend more than the time required to select which middleware they want to use. Even for those that build their own engines, the graphics abstraction layer is a tiny portion of the engine, versus everything else that isn't covered by Khronos standards. Meaning GUI support, font, texture and shaders loading, mesh rendering, scene descriptions, game editors,.... Usually adding a new rendering backend to an engine doesn't take more than around one month, the biggest time slice being consumed by time to first triangle. Given that Vulkan specification already has 74 extensions and is only at version 1.0.42, already bringing up the fun of "write once, port multiple times" from OpenGL, I am not confident this is going anywhere. https://www.khronos.org/registry/vulkan/specs/1.0-extensions/html/vkspec.html https://www.khronos.org/registry/vulkan/specs/1.0-extensions...
- exDM69 10y ago
  > Given that Vulkan specification already has 74 extensions and is only at version 1.0.42, already bringing up the fun of "write once, port multiple times" from OpenGL This is a dishonest and decieving way of putting things. The difference between Vulkan and OpenGL here is that most of the functionality extensions are software only additions and are available everywhere with up-to-date drivers. Mobile is a bit of a pain point because they don't get driver updates as nicely. If you look at Vulkan extensions qualitatively (not just the numbers) you'll see that it's nothing at all like the OpenGL extension mess. The vast majority is window system integration (WSI) and extenral memory and multi device stuff. Platform specific stuff which would exist in WGL/GLX/EGL for OpenGL and can't reasonably be put in "core" (because everyone must support all of core). It was perhaps a mistake to attempt to release Vulkan 1.0 as early as they did, it might have been a better idea to put out 0.9 beta version and accept that there will be API changes. However, very few changes have been made to the core apis.
  - pjmlp 10y ago
    It is not being dishonest as alternative APIs don't suffer from extension explosion. Also I don't believe that by following this path Vulkan will be any better than OpenGL, ES, WebGL. Let's see how many Vulkan 2.0 will have and of what kind.
exDM69 10y ago
Yes, but Unity, Unreal and the other engines need a 3d API to run on. They can use Vulkan, D3D or Metal on native desktop/mobile platforms but that's already 3 separate backends and there's no good API for the browser (WebGL being suboptimal in many ways and about 15 years behind the native platforms).

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]

33a 10y ago

Why not just port some subset of Vulkan to Apple?

exDM69 10y ago
There is a commercial, proprietary Vulkan implementation (called MoltenVk) that runs on top of Apple's Metal. This is not a technical issue, but a political one. Apple has decided not to allow Vulkan in their walled garden.

cordite 10y ago

Isn't the industry getting a little fatigued by now?

mintplant 10y ago

Huh. I thought Vulkan was supposed to be the new portable 3D standard from Khronos. Now we need a new new standard on top of the old new standard?

detaro 10y ago
Supposed to be, but Apple and probably parts of Microsoft don't want to play ball.
- ClassyJacket 10y ago
  So why would they play ball with this?
  - detaro 10y ago
    I understand this proposal as suggesting to build an API that can be implemented efficiently on top of the vendor-specific APIs, without the vendors doing anything. E.g. similar to how the ANGLE library offers OpenGL on top of Direct3D APIs, for Windows PCs without/with bad OpenGL support.

badsectoracula 10y ago

Is Khronos going to implement something? Because AFAIK they only write the specs for others to implement them - so it is up to each vendor to make the API available. If Apple and Microsoft aren't going to implement Vulkan, why would they implement something else?

pzone 10y ago
The point of Khronos was never to implement anything. It serves as a coordination mechanism among industry players, where the specs for OpenGL, Vulkan etc. are debated, hashed out and formalized. I'm not exactly sure what your last question means. Vulkan will be available on Windows. I think it may be more correct to say NVidia/AMD/Intel are implementing Vulkan APIs in their graphics drivers and Windows will expose the API to applications. At the same time, they do seem to see benefits in creating other APIs at the same time, i.e. DirectX 12 and Metal. So we'll see I guess.
slimsag 10y ago
It could be that this is a specification on how to implement some new API which operates consistently across the trio; i.e. "this function invokes X with parameters Y in Vulkan, X with Y in Metal, X with Y in DirectX" since that is no trivial task to do right and extensively. But I'm sure that'd also include a real implementation.. so.. yeah.
exDM69 10y ago
Recently, Khronos has been also implementing some of the infrastructure, like the Vulkan loader and validation layers, the GLSL-to-SpirV compiler (glslang) and the SpirV tools which are open source and developed by LunarG and others. The actual driver parts are written by hardware vendors (IHV's in Khronos-speak) but there's a push to put less stuff in the drivers and more stuff that is common to all vendors. Not sure about this project, though. Looks to me like an effort to get the relevant parties discuss this in GDC and see what comes up.
theandrewbailey 10y ago
Khronos is an industry standards group. It is composed of companies that implement Khronos APIs. So yes, in a way.

daurnimator 10y ago

I'm not sure why Vulkan couldn't work on windows: isn't it mostly in the hands of driver developers (i.e. Nvidia/AMD) rather than Microsoft?

detaro 10y ago
Microsoft is not just Windows, some mobile devices and more importantly the XBox as well. On Windows, the GPU makers can (and do, at least partially/beta) provide drivers with Vulkan support, yes.
cma 10y ago
It does work on Windows. Not sure about Windows Phone though.
- pjmlp 10y ago
  UWP only allows for DX, but one can built other APIs on top, e.g. ANGLE for OpenGL support.

phonon 10y ago

This sounds like a response to Apple's WebGPU initiative?[1] https://news.ycombinator.com/item?id=13593272 https://news.ycombinator.com/item?id=13593272

yousry 10y ago
The emulation cost for non Apple Systems would be enormous to implement this solution (= SLOW). SPIR could be used native on most devices.

yousry 10y ago

This proposal makes much more sense than Apples "Metal Only" solution (https://webkit.org/blog/7380/next-generation-3d-graphics-on-the-web/ https://webkit.org/blog/7380/next-generation-3d-graphics-on-...). I liked Metal at the beginning but over time it turned out that it is just another OpenGL/DX flavor with the same old driver/performance problems. Also using SPIR as IL allows the use of the preferred shader language. WebGL Next is about parallelism and abstraction, otherwise there would be absolutely no benefit.

DowsingSpoon 10y ago
Can you comment a bit more on the limitations of Metal? I've been spending the last few days reading through the docs and learning how to use Metal. So, I'm curious what you (and anyone else, I guess) perceive its shortcomings to be.
- yousry 10y ago
  My personal biggest concern was the re-invention of OpenGL/DX features without the proper knowledge why and how these features can be used. For example I never managed to apply a skeletal animation to a indirect indexed draw call or use transform feedback loops for ray-casting or other deferred shading techniques.

Animats 10y ago

Who needs a "next generation WebGL?" It's hard to find an interesting or useful WebGL site. There are plenty of demos and ads, but few sites worth visiting. Here, go shoot some zombies. http://www.y8.com/games/abandoned_island http://www.y8.com/games/abandoned_island That's about as good as it gets.

legulere 10y ago
Google maps doesn't work without WebGL, and some other map related websites like mappilary.
- Animats 10y ago
  Right, but the proposal is about an API which lets web applications do shader-language stuff beyond the level of WebGL. Is this really necessary?
  - deafcalculus 10y ago
    The new APIs (Vulkan, DX12, Metal) are mostly about performance. I can't think of any major thing that you can't implement in WebGL. But, a portable 3d API would be awesome for native apps. And, why not have that be the 3d API for the web too? Like WebGL / OpenGL ES 2.
- deleted 10y ago
  [deleted]
- mirimir 10y ago
  It seems to work in Firefox with WebGL disabled.
- TeMPOraL 10y ago
  Why on Earth (no pun intended) should Google Maps require WebGL? Another example of people losing focus on providing actual value with the products they make.
  - 10y ago

cmrx64 10y ago

In accordance with federal law (http://n-gate.com/ http://n-gate.com/), I'm obligated to point out this Rust library, which does exactly this! https://github.com/gfx-rs/gfx https://github.com/gfx-rs/gfx. I worked on the second version of the API in 2014 and it's only gotten better since. The major thing this particular abstraction still doesn't solve is shaders: you need to write a shader per backend you support. Shader portability is a bit of a sticky problem.

sipos 10y ago

This seems like a better approach than Apple's WebGPU in that it is more realistic (depends on using a usable subset of the three APIs that is reasonably common) and, not started by the same company that is the biggest obstacle to cross-platform graphics APIs in the first place. It seems unfortunate that it is necessary though. It is clear that neither Metal or DirectX can be the cross-platform API we'd all like so, it seems a shame Microsoft and Apple can't just support Vulkan.