In practice, the word "open" in "Open Standards", such as OpenGL or Vulkan, doesn't mean very much. For example, being able to vote, participate in the specs' working group, or access the conformance tests costs a considerable amount of money[1].
APIs such as DirectX or Metal receive just as much or more input from developers, albeit mostly through back channels or explicit reach out by Microsoft, Apple, etc.
The conformance tests are open source and will be available from day 1 ;)
As far as participating in the design of the standard, are you really saying you'd want everyone and their mother to have their word? I think it's best to leave this to GPU vendors and engine implementers, as they're the ones who know how it can work.
Well OpenGL regardless of urban myths has been mostly ignored by the games industry, except on iOS, Android and indies before the rise of middleware due to lack of proper tooling.
Or it can be a very nice object based API instead of a state based API that made sense in 1992 as the slide deck said and certainly didn't make any sense in 2008 when the industry group Khronos sided with the commercial CAD industry to screw over Linux consumer gaming because there was no money in it. How was that DirectX's fault again?
I am guess you're not a game developer and your post is yet another case of [1].
I am a game dev and here are some links that show to non game devs why DirectX is more popular:
> Perhaps because design by a committee of peers usually results in a fragmentation and compatibility nightmare like this
It can. Or it can result in spec which helps everyone instead of just MS alone. Depends on how it's done. Vulkan is done from scratch, and so far I see no signs of them making mistakes of OpenGL. I guess we'll see more once it's released. Either way, what's the alternative? There is none, unless of course you work for MS and envision them controlling everything.
>Or it can result in spec which helps everyone instead of just MS alone.
Just MS alone? DirectX helps hundreds of millions of gamers, a whole bunch of game and application developers and companies.
That's like saying improvements to the Linux kernel help only the Linux kernel.
>Vulkan is done from scratch, and so far I see no signs of them making mistakes of OpenGL
Huh, how do you see that? The spec is developed behind closed doors by corporate folks each with their own interests. Even the W3C holds open discussions with specs.
A real alternative would be for the FOSS/Linux dev community to create and implement a standard properly.
Yes. How can you use DirectX on non MS platforms? If MS wanted to help someone besides themselves, you could answer that question in a satisfactory fashion. But of course, they don't care about it, they only care about lock-in. Trying to pretend that lock-in serves anyone besides those who push for such lock-in is highly disingenuous.
> Huh, how do you see that?
From what was published about it so far (origin in Mantle, collaborative input of those who know better and so on).
> A real alternative would be for the FOSS/Linux dev community to create and implement a standard properly.
Linux community was involved. In fact the main link in this post is from one of the contributors to Wayland and Mesa who was working on Vulkan.
Other folks are beating about the bush, so I'll just come out and say it:
Linux is basically irrelevant to game developers.
Other folks have been nice, but let's just be clear here. Linux's graphics story is a stupid joke, the driver story is a stupid joke, the 3D story by way of OpenGL is a stupid joke, audio is a stupid joke.
That's why it doesn't matter if you can only use DirectCX on MS platforms--because by reaching only that teensy tiny vast majority of installed computers, devs can do well.
MS has always treated their developers better than anything in the 'nix or BSD ecosystem, and that extends to better thought-out and implemented APIs.
Sorry, but that's the world we live in, and in reality there is little point in MS worrying about a non-DX API--and little point in supporting one if you're making games for PC.
> Linux is basically irrelevant to game developers.
Sounds like a quote form early 2000s. We are long since past that. If you didn't pay attention to the last few years - then may be research what's going on now.
> That's why it doesn't matter if you can only use DirectCX on MS platforms
It does matter. Lock-in forces developers to do double work. I.e. if they can't reuse the effort - they need to duplicate it. To put it differently - MS on purpose increases the cost of making cross platform games. Obviously for the reason of putting competing platforms at a disadvantage. How can any developer find such behavior beneficial is hard to understand. All normal developers have no respect for lock-in.
> MS has always treated their developers better than anything
Oh, really? Forcing people to do double work is not called treating you better. It's called being a jerk. And jerks they are, same as anyone who uses tools for lock-in purposes (instead of for what they should be - tools).
So to be clear, you are calling all the game industry studios that specialize in platforms, porting and tooling, a practice that goes all the way back to the industry roots, jerks.
> you are calling all the game industry studios that specialize in platforms, porting and tooling, a practice that goes all the way back to the industry roots, jerks.
How exactly did you read that into my words? I said those who force people to do double work are jerks. I.e. those who create and enforce lock-in (MS and their ilk). Why would developers who have no option but to do that double work be jerks? It wasn't their decision and they have no control over those who create those walled gardens and lock-in.
Practice of lock-in doesn't go to "industry roots". It goes to those jerks who don't care about the industry and want to make life harder for developers by making tooling useless outside given walled gardens. Their selfish and stupid idea is based on assumption that the harder and more costly it is for anyone to do the work (because of duplication), the less likely they'll do it, thus sticking only to the walled garden they initially focused on. I.e. their usual exclusivity idea. Remember browser lock-in? Same idea here. It has nothing to do with the industry - it's all about jerkiness of those who make the tools and control the market.
But its not helpful is it. Its the same case for windows mobile where nobody is interested to create any apps since its user base is almost irrelevant.
Sony, Nintendo and Apple are as guilty of lock-in as MS is. At least Nintendo, Apple and Sony are part of the Vulkan working group. Whether they'll support Vulkan on their walled gardens - time will tell. If they'll outgrow their petty lock-in mentality, they might. But MS didn't even join. To be clear - I have no respect for lock-in whether it comes from MS, Nintendo, Sony, Apple or whoever else.
Who knows. Being part of the working group might mean they are considering it. Or may be not. MS though lets everyone know now that they don't care (by not being part of the group).
> So how are they again different from MS?
They are pretty similar in many (bad) ways, including the issue of lock-in. Apple is probably even worse these days.
Not MS alone, but anyone who uses lock-in. And why should such despicable behavior be respected, because it's an "industry practice"? It is not. It's just common because various major companies in the industry are indeed jerks.
>NVIDIA will therefore provide a few Vulkan extensions from day zero, so that you as developer can enjoy less obstacles on your path to Vulkan. We will support consuming GLSL shader strings directly next to Vulkan's mandatory SPIR-V input
Nefarious intent aside. This will make it much easier to port large projects over piece by piece so its not an all or nothing proposal that requires a complete rewrite from day 1.
The lack of information about Vulkan is a bit concerning. For something that is about to be announced anyday now there is very little concrete information available about basic details like - what hardware that is currently shipping will support vulkan and how long after announcement will vendors have drivers out (weeks/months/years?).
> what hardware that is currently shipping will support vulkan
AMD will support it for all GCN GPUs (7000 series).
Nvidia will support Vulkan for Fermi (GeForce 400) and newer. I don't really believe them here, but they even talked about Windows XP support. Announced on SIGGRAPH 2015.
Intel is Haswell and newer. It's possible that Ivy Bridge may get it on Linux, but Windows driver looks unlikely as they don't even support OpenGL 4.3 in Windows.
> how long after announcement will vendors have drivers out
Valve demonstrated Vulkan driver developed by LunarG for Intel hardware back in March of 2015. It's will be released with source code once specification released.
Nvidia driver with Vulkan (358.66) leaked in November.
AMD employees confirmed they already have Vulkan working on top of new Linux AMDGPU driver.
>what hardware that is currently shipping will support vulkan
Khronos has committed to publishing an API which can be implemented on all OpenGL ES 3.1 capable hardware.
>how long after announcement will vendors have drivers out (weeks/months/years?).
AMD, NVIDIA, and intel have all committed to timelines, or do not need to.
AMD developed Mantle, and has been developing their Vulkan stack since the beginning. They haven't set a date, but I doubt it'll be more than a month past public API release.
NVIDIA has committed to same-day delivery of a compliant driver. The day that the spec comes out, NVIDIA says they will have a driver.
For intel, I'm not certain about their proprietary drivers. I do know, however, that Valve and LunarG have developed an intel Vulkan driver. They are committed to a same-day release with source code.
So no: not years, probably not months, maybe not even weeks.
Newest thing I've heard is that there will be games using Vulkan at launch. So, the specification, the drivers and some game ports will all go public the same day. Anything might be holding it up (most likely the ports), but GDC in March seems like a reasonable deadline considering the amount of talks about Vulkan.
I really think one of the important aspects is that it should be much easier to reverse engineer proprietary drivers now given how explicit the API is supposed to be.
More garbage from the same trash factory. Get back to me when you have an API that doesn't incentivize drivers to behave differently based on the name of the video game engine.
No one has such an API, as far as I can tell. You think drivers aren't activating special code paths and replacing shader code for games that use Direct3D? I suspect we'll have a short time period where drivers don't do this for Vulkan and D3D12 before we go right back to it because in the end, whoever runs the game and runs it faster wins, no matter how broken the game is.
I think he's referring to GR_APPLICATION_INFO, which in Mantle was a struct passed during initialization containing the string names of the game and engine plus their version numbers.
The intention probably is to make app specific driver paths easier to implement but as you say, driver developers would do that regardless using the name/path/checksum of the EXE if they had to.
Seriously Khronos, take a fucking page out of C++. They went two decades with awful broken language syntax until sometime between 2004 and 2008 they got together and decided to fix it.
Today, https://isocpp.org/ is a gold mine of how to do an open standard correctly. Everything is public, future features are discussed with the community, and all the working groups are on github. That is how you take a legacy standardization body and modernize it for the open source world, not make presentations at every event for over a year going "Hey guys its gonna be great! Just wait until you see it! Ooooonnnnnneeeee day! We just know you'll love it!"
Not only as drivers, but also documents, books, tools and graphical debuggers.
I hope this doesn't turn out into another Longs Peak.
[0] Yes, I know it is Mantle inspired and I have those PDFs.