Whose experience in the industry says that lock-in is good for development? Sources please. Or may be you have an example of GDC presentations titled "Lock-in - the ultimate driver of engines' progress" or "Drive development costs down by proliferating lock-in"?
> Whose experience in the industry says that lock-in is good for development?
Lock-in is only in the heads of FOSS advocates, not in the game developers that want to squeeze the hardware to the limits of what it can do, while selleing the game.
> Sources please.
Go to GDC, IGDA, PAX, Game Development university degrees events close to you and do some networking talking with actual professional game developers, what is their opinion about graphical APIs.
Attend their talks about graphic APIs.
Read articles on magazines like Gamasutra, EDGE, Game Connections, Making Games about graphic APIs and the industry view on them.
Again, please show me any talk which says, that developers benefit from the need to address vendor lock-in which forces them to support multiple APIs instead of having an option of good cross platform ones. I doubt you can show any such talk.
But I suppose you'll say that it's all imaginary. In such case further discussion is pointless. Figure out, does it exist and you support it, or you think it doesn't exist and you actually don't.
> Again, please show me any talk which says, that developers benefit from the need to address vendor lock-in which forces them to support multiple APIs instead of having an option of good cross platform ones. I doubt you can show any such talk.
You know that even OpenGL requires multiple paths full with extensions for supporting properly various render targets, right?
So if there isn't a talk accessible in the Internet it didn't happen?!
Again, talk to professional game developers, which apparently it is something you don't do.
As for the rest, FOSS advocates see lock-in as an hindrance, professional game developers see lock-in as the right set of features to make their game outsell the others.
That was the magic of computer hardware like Commodore 64, Atari, Amiga.
It was the lock-in to their hardware, to their special processors that made these platforms special, and many of the ports just meh quality.
This is the culture of games industry, pushing an agenda without understanding how the industry works, is like D. Quixote fighting windmills.
> But I suppose you'll say that it's all imaginary. In such case further discussion is pointless.
Of course, because I have the game industry experience that you lack and are unwilling to accept how it actually works.
Which I might add, also caused me issues in the past, because I used to think like you, before having had the opportunity to see the industry from inside.
It has nothing to do with FOSS specifically. Lock-in is a hindrance for pragmatic reasons. Time costs money, which you seem to blindly ignore. Trying to say that lock-in is something positive is beyond silly.
> Of course, because I have the game industry experience
Apparently your experience didn't demonstrate you the negative effects of lock-in. May be you can develop an engine for all APIs at once for the cost of one?
So far, I'm waiting for some more substantial sources from you about benefits of lock-in for the industry, and how it's not a tax that hinders development, instead of abstract "get it from GDC".
> May be you can develop an engine for all APIs at once for the cost of one?
Because as anyone in the industry knows, the portability of APIs like OpenGL only happens in theory.
To expose the hardware features that makes the game shine and stand out over others, one needs to make use OpenGL extensions.
A different set of calls for each card model, manufacturer and game consoles if they expose an OpenGL wrapper API.
Then there are the workarounds for the API calls that are supposed to be part of portable OpenGL, but then again behave differently across graphics hardware and drivers, leading to additional code paths.
The shading language features are also different across OpenGL versions and graphic drivers.
Finally OpenGL and OpenGL ES are common just in the name and a few overlapping APIs, leading to rewrites between desktop and mobile platforms.
In the end, the development effort of writing "portable" OpenGL, while taking advantage of vendor extensions and working around bugs is bigger than use exposing an common abstraction layer on the games engine that takes advantage of each native API without piles of workarounds.
OpenGL wasn't portable enough to be performant at the same time, for several reasons. I'm talking about Vulkan, not about OpenGL and its troubles in the past. Vulkan addresses the issues which you mentioned.
Vulkan still has extensions. The whole reason game developers want to have lock-in is so that you can squeeze the maximum possible quality out of a known set of hardware.
Once you start abstracting that away you are falling behind other companies who may be able to draw slightly more particles at slightly higher frame rates at slightly higher resolutions.
The whole reason Nintendo is still saying "we have Vulkan" is because they are the only console manufacturer were raw graphical performance was never the system seller.
DX has driver caps, feature levels and optional features within each feature level - so you have to branch on runtime anyway, just like with OpenGL or Vulcan extensions. Even Apple Metal has Feature Sets for exactly that reason.
If you want to evolve your API together with the hardware, you need some extension mechanism.
Lock-in doesn't cause you to be able to 'squeeze performance' out of the hardware. It causes you to specialize your code to the platform so much you can't port it to another.
It's the other way around. Developers don't care much about portability. The care about APIs that allow them to build performant programs. For them, a bad side effect of such APIs is vendor lock-in.
Why would a game developer want to limit his audience?
> Lock-in doesn't cause you to be able to 'squeeze performance' out of the hardware.
Let's assume GPU X supports some feature that GPU Y does not. Then you either use an (say OpenGL or Vulkan) extension to use it to squeeze out performance (lock-in) or you eschew the lock-in, don't use the feature and ignore the performance advantage. Now multiply this with lots of features and also consider that the graphic APIs of consoles offer some rather unique features that don't map directly to, say, DirectX11 or OpenGL.
> It has nothing to do with FOSS specifically. Lock-in is a hindrance for pragmatic reasons. Time costs money, which you seem to blindly ignore. Trying to say that lock-in is something positive is beyond silly.
As a game development studio you can buy support if you get to a problem with the locked-in drivers (NVidia is even well-known to smarm over game development studios and "lend programmers out" to make the game fast/good-looking on NVidia GPUs (and perhaps worse on AMD ones? ;-) )). In most cases game developers don't have the time to track down deep bugs in the graphics drivers (even if the GPU source were available). I ask: Can you at least buy on-time support from the Linux GPU driver developers if you find a problem with their drivers and/or buy on-time support to make the game run well on GNU/Linux?
As soon as the available support of the GNU/Linux developers becomes much better the the support GPU vendors offer to game developers for their "lock-in drivers", I believe game studios could become interested in supporting the "open source GPU driver" agenda. But not before.
It's because no-one would both to write such a talk.
Game developers have already tuned their engines for the PS4 and Xbox 1 separately, and in both cases apply substantial specializations, designed to take maximum advantage of exactly the chips, the number of shaders, etc. available.
Any cross-platform library has to make some simplifying assumptions, which will produce a small loss of performance. Now, that's an easy trade-off to make if you are developing for PCs, there are thousands of common CPU/memory/GPU triples you might come across, you obviously aren't going to optimise for each individually. On consoles you do.
There have been a number of consoles that supports OpenGL. No-one ever used it, because the performance wasn't good enough.
> That's why there is Vulkan. OpenGL doesn't offer enough control to address such cases and isn't even designed to be parallelized.
That's why there is libGCM (PS4) and NVN (Nintendo Switch; cf. http://www.neogaf.com/forum/showthread.php?t=1297662). Vulkan doesn't offer enough control to address such cases and isn't even designed to take full-advantage of the hardware that is available in the concoles.
> Again, please show me any talk which says, that developers benefit from the need to address vendor lock-in
I don't believe it is a benefit for game developers. pjmlp already hinted some points. I will describe it a little differently.
For OSS hackers it is very important to be able to debug the things on their own. Game developers probably simply don't have the time for this. They instead buy support from the hardware vendor (AMD, NVidia, Microsoft, Sony, Nintendo etc.) if they get into driver bugs that they can't trace down on their own. Even more: In many PC game development studios there sit programmers that are actually financed by NVidia ("NVidia mafia") whose job is to make the game run fast/good-looking on NVidia GPUs (and perhaps worse on AMD ones ;-) ). In particular gamers playing on AMD GPUs are of course critical of this fact for obvious reasons. Now I ask snakily: What service do OSS (including OSS GPU driver) developers offer/deliver to game development studios to make the game-in-production run well on GNU/Linux and/or on open source GPU drivers? This should perhaps answer your question why game developers often don't care about OSS drivers etc.
No-one claims that gamedevs see lock-in as something positive; only that very few AAA gamedev shops care about lock-in - especially for a relatively small part of the production pipeline as a graphics API.
What you see as locked-in API, others see as a great feature set to build on, probably with access to driver developers to help reach even further, past publicly available APIs.
A game engine is not something you can switch out of easily anyway. Everything from game code, to years of asset libraries to decades of source control repositories - all of those are very rigid parts of the production pipeline.
