3D Portability Initiative
khronos.org
khronos.org
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.
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.
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.
But I'm sure that'd also include a real implementation.. so.. yeah.
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.
This is not a technical issue, but a political one. Apple has decided not to allow Vulkan in their walled garden.
Here, go shoot some zombies.
http://www.y8.com/games/abandoned_island
That's about as good as it gets.
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.
Almost every non-trivial WebGL page I've seen shows a "Loading" message for some period of time.
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.
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.
Another example of people losing focus on providing actual value with the products they make.
The recently discussed Qt remote WebGL app feature is a nice example that you can do even with WebGL 1 (https://news.ycombinator.com/item?id=13744631)
Also a lot of non-game 3D customers historically have been inhouse scientific / data visualization users. I suspect many of those are already moving to WebGL & internal web apps, but you won't see them much on public web sites.
It took a good while for interesting or useful JS apps to arrive too...
We've got those super powerful processors that can be one or two orders of magnitude faster than CPUs, but their performance is mostly wasted because there is no way to do general compute on GPUs in browsers.
But even so, there are still some pretty cool things being done with WebGL:
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.
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...
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.
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.
I can't name a single extension that would be causing any friction in Vulkan, unlike OpenGL where there's lots of code paths that need to be implemented to do even basic stuff (and all the core/ARB/EXT variations).
Yeah, Vulkan has some extra complexity stemming from being cross-vendor and designed by a commitee. But it's nowhere nearly as bad as you imply.
In my experience with Vulkan, it's all the optional features and device capabilities that need to be queried at runtime and decisions made based on that that's causing complexity with portability (you don't need to care about most of the extensions, and the ones you do have to care about are simpler than their OpenGL counterparts, ie. WSI vs. GLX/WGL/EGL). And apart from a few pain points (like numbers of queues exposed), it's relatively straightforward and comparable to D3D or Metal in complexity.