
3D Portability Initiative - ooyy
https://www.khronos.org/3dportability
======
yousry
This proposal makes much more sense than Apples "Metal Only" solution
([https://webkit.org/blog/7380/next-generation-3d-graphics-
on-...](https://webkit.org/blog/7380/next-generation-3d-graphics-on-the-
web/)). 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
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
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.

------
cmrx64
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.

------
mintplant
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
Supposed to be, but Apple and probably parts of Microsoft don't want to play
ball.

~~~
ClassyJacket
So why would they play ball with this?

~~~
detaro
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
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
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.

------
sipos
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.

------
33a
Why not just port some subset of Vulkan to Apple?

~~~
exDM69
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.

------
phonon
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
The emulation cost for non Apple Systems would be enormous to implement this
solution (= SLOW). SPIR could be used native on most devices.

------
daurnimator
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?

~~~
cma
It does work on Windows. Not sure about Windows Phone though.

~~~
pjmlp
UWP only allows for DX, but one can built other APIs on top, e.g. ANGLE for
OpenGL support.

------
Animats
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.

~~~
vardump
Same was said about sound, Javascript, web video, and pretty much any addition
on top of basic markup.

I think future web will be better and/or can consume less power when sites
have more direct control of rendering.

Emphasis on power usage -- I think they (= browser vendors) should give a
_lot_ of consideration how to enable developers to save power. Web rendering
is already mainly done on GPUs anyways, but there's opportunity to push less
pixels to achieve the same results as the current rendering methods. Pushing
less pixels equals less power. Of course passive power savings (from
developers' point of view) are also good.

WebGL must also not perceptibly increase page load times, a few milliseconds
is acceptable.

If the features turn out to be useful, when reliable WebGL is ubiquitous,
various javascript libraries will start to use it and number of sites using
WebGL will increase rapidly.

~~~
Animats
_WebGL must also not perceptibly increase page load times, a few milliseconds
is acceptable._

Almost every non-trivial WebGL page I've seen shows a "Loading" message for
some period of time.

~~~
vardump
Well, I meant just fixed base cost in milliseconds. In other words, how long
it takes to just output something extremely simple, say, a flat shaded
triangle without external libraries. Not to measure resource loading and other
initialization.

Of course initialization and possible shader language, SPIR or whatever
compilation will take time on top of that.

Many current WebGL apps require a lot of large data, textures, meshes and
libraries. Obviously loading those will take time.

~~~
Animats
Flash had an scheduled loading scheme, so the timeline specified when an asset
would be sent as you played a Flash animation. Macromedia had authoring tools
which would try to slot the assets in the timeline so they'd be available when
needed, while staying under a bandwidth limit.

You could, in theory, do that with WebGL. Google is all fired up about
"preloading" lately. This is an authoring tool problem, and if WebGL games get
serious, there will probably be author-side tools for this.

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

~~~
khedoros1
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
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.)

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

