New DirectX Shader Compiler Based on Clang/LLVM Open-Sourced(blogs.msdn.microsoft.com)
blogs.msdn.microsoft.com
New DirectX Shader Compiler Based on Clang/LLVM Open-Sourced
https://blogs.msdn.microsoft.com/directx/2017/01/23/new-directx-shader-compiler-based-on-clangllvm-now-available-as-open-source/
83 comments
If there's anyone reading this who's a LLVM contributor (and therefore copyright holder), can you send a DMCA notice to github over this please?
https://help.github.com/articles/dmca-takedown-policy/
https://help.github.com/articles/dmca-takedown-policy/
I don't get it – why use the nuclear option when you could open an issue and ask them to look into it? This may be just an oversight.
It's almost certainly an oversight, an issue is the correct course of action here. You can always resort to DCMA if that isn't effective.
I think that's pretty unlikely.
Probably try to resolve it peacefully
I gotta say, this "new, open Microsoft" is really surprising me. I think what this signals is the end of selling software. Microsoft has seen the writing on the wall and realize that the money is in subscriptions and services.
Due to piracy, a company can no longer just release an incremental update of their software package every couple years. They have to have rolling updates and constant improvements to keep the money stream rolling in from their customers.
This is why MS is focusing on Azure, Office 360, Windows 10, etc.
Due to piracy, a company can no longer just release an incremental update of their software package every couple years. They have to have rolling updates and constant improvements to keep the money stream rolling in from their customers.
This is why MS is focusing on Azure, Office 360, Windows 10, etc.
> Due to piracy, a company can no longer just release an incremental update of their software package every couple years.
In earlier days (before Microsoft introduced much stronger copy protection schemes, such as the necessity to activate the products or WGA) a lot more installed copies of Microsoft products were illegal copies (in particular on computers owned by private users). And Microsoft survived quite well. So if you really believe in the "piracy explanation", you are deeply brainwashed by rightholder's propaganda.
The IMHO most plausible reason why the model worked in former days, but worse today (though "worse" is probably a really bad word: revenue today is surely still much larger than in the former days), is that as long as Moore's law correlated to increased speed for existing applications (without need for new programming tricks such as having to use multithreading, new SIMD instructions etc. in the programs to make use of the additional power of new processors), there was a good reason to buy a new PC every few years. With each new PC there came a new OEM version of Windows and sometimes some Microsoft Office applications. So the formerly existing correlation between Moore's law and speed for existing applications drove Microsoft's sales.
In earlier days (before Microsoft introduced much stronger copy protection schemes, such as the necessity to activate the products or WGA) a lot more installed copies of Microsoft products were illegal copies (in particular on computers owned by private users). And Microsoft survived quite well. So if you really believe in the "piracy explanation", you are deeply brainwashed by rightholder's propaganda.
The IMHO most plausible reason why the model worked in former days, but worse today (though "worse" is probably a really bad word: revenue today is surely still much larger than in the former days), is that as long as Moore's law correlated to increased speed for existing applications (without need for new programming tricks such as having to use multithreading, new SIMD instructions etc. in the programs to make use of the additional power of new processors), there was a good reason to buy a new PC every few years. With each new PC there came a new OEM version of Windows and sometimes some Microsoft Office applications. So the formerly existing correlation between Moore's law and speed for existing applications drove Microsoft's sales.
Hopefully it will be of some help for this effort: https://github.com/KhronosGroup/glslang/issues/362
I'm kind of surprised that this happened, though I've heard it could happen from glslang developers. It helps reducing DX/HLSL lock-in, and it's as if usual MS management responsible for such lock-in fell asleep, and developers managed to release something good for the world for once.
I'm kind of surprised that this happened, though I've heard it could happen from glslang developers. It helps reducing DX/HLSL lock-in, and it's as if usual MS management responsible for such lock-in fell asleep, and developers managed to release something good for the world for once.
Microsoft has been going away from that path for quite a while now, ever since Balmer left. For example the .NET runtime now runs on BSD/Unix/Mac OS X and sql server was released for Linux.
Ultimately it is still in the interest of Microsoft if their toolchain is interesting because it is compatible among all target devices (PC, Xbox, PS, Mobile) so I'm unsurprised they are moving in that direction.
Ultimately it is still in the interest of Microsoft if their toolchain is interesting because it is compatible among all target devices (PC, Xbox, PS, Mobile) so I'm unsurprised they are moving in that direction.
> For example the .NET runtime now runs on BSD/Unix/Mac OS X
Under Balmer's time, there already publicly existed Microsoft Rotor - a .net runtime that ran under FreeBSD and OS X:
> https://en.wikipedia.org/w/index.php?title=Shared_Source_Com...
So don't do a corruption of historical facts.
Under Balmer's time, there already publicly existed Microsoft Rotor - a .net runtime that ran under FreeBSD and OS X:
> https://en.wikipedia.org/w/index.php?title=Shared_Source_Com...
So don't do a corruption of historical facts.
You're being really pedantic when you say there was already Microsoft support for .Net on non-windows platform.
It was a unsupported (no release after 2006) bare fork of the runtime that couldn't be used commercially [2]. Would you have corrected me if I stated "Internet Explorer doesn't run on Mac Os X" just because there is a version of it from 2003?
Especially when you compare it to a large part of the toolchain including compiler and runtime under a MIT license that builds to multiple platforms from the same codebase [1], that's not even in the same league.
[1]: https://github.com/dotnet/
[2]: From your own "This license [...] allows for personal or academic usages, but they can't be used for commercial products"
It was a unsupported (no release after 2006) bare fork of the runtime that couldn't be used commercially [2]. Would you have corrected me if I stated "Internet Explorer doesn't run on Mac Os X" just because there is a version of it from 2003?
Especially when you compare it to a large part of the toolchain including compiler and runtime under a MIT license that builds to multiple platforms from the same codebase [1], that's not even in the same league.
[1]: https://github.com/dotnet/
[2]: From your own "This license [...] allows for personal or academic usages, but they can't be used for commercial products"
> Would you have corrected me if I stated "Internet Explorer doesn't run on Mac Os X" just because there is a version of it from 2003?
Without kidding: I actually know Apple fanatics who use this to "point out" that Internet Explorer does run on OS X and use the argument that this version is from 2003 to show how badly Microsoft treats Apple users. :-)
Without kidding: I actually know Apple fanatics who use this to "point out" that Internet Explorer does run on OS X and use the argument that this version is from 2003 to show how badly Microsoft treats Apple users. :-)
While you're technically correct, ROTOR hadn't received any updates for a long time, and the source was licensed in such a was as to make sure anyone who could benefit from it running on *NIX platforms was heavily incentivized not to do so.
IIRC, Rotor's license explicitly forbade porting it to Linux.
The impression I got back then was not so much of Microsoft showing how "cross-platform" .Net was, more like a big middle finger towards Linux.
The impression I got back then was not so much of Microsoft showing how "cross-platform" .Net was, more like a big middle finger towards Linux.
.NET Core on Linux and macOS runs on Rotor, as does ChakraCore.
.NET Core works on Rotor for Linux and macOS, right.
Silverlight for macOS also works on Rotor AFAIK.
Oh they are still working on DirectX 12.
Microsoft has the tendency to downside and almost stop development after reaching near monopoly of a niche. Everyone remembers the Internet Explorer 6 years, it took years and Firefox reaching 25% market share to continue development of IE7. The same with DirectX: DirectX 9 was too successful, and OpenGL supported was limited to OpenGL 1 in WinXP and onwards (only tricks like bootstrapping allows OpenGL2+ on Win). DirectX 9 was around for many years. When OpenGL 3 and 4 came around, Microsoft restarted development of DirectX 10. DirectX 11 was merely a maintenance release. When the new AMD API (now Vulcan) came along, Microsoft restarted development with DirectX 12. Nowadays 99.9% of all new games are DirectX10/11 or Vulcan and support Win7+ and are usually available over Steam and/or GoG. And PlayStation 4 is very successful worldwide. XBoxOne is mainly successful in US and has little presents worldwide, Microsoft even stopped announcing sales two years ago - it's that bad. Nor are there any new exclusive games to speak of, PS4 has dozends of exclusive games, Win7+ has millions of exclusive games. Win10 Store is a complete desaster, worst software ever and hardly anyone would use it to buy games, if there are far better alternatives like Steam and GoG. Is DirectX 12 still a thing?
Microsoft has the tendency to downside and almost stop development after reaching near monopoly of a niche. Everyone remembers the Internet Explorer 6 years, it took years and Firefox reaching 25% market share to continue development of IE7. The same with DirectX: DirectX 9 was too successful, and OpenGL supported was limited to OpenGL 1 in WinXP and onwards (only tricks like bootstrapping allows OpenGL2+ on Win). DirectX 9 was around for many years. When OpenGL 3 and 4 came around, Microsoft restarted development of DirectX 10. DirectX 11 was merely a maintenance release. When the new AMD API (now Vulcan) came along, Microsoft restarted development with DirectX 12. Nowadays 99.9% of all new games are DirectX10/11 or Vulcan and support Win7+ and are usually available over Steam and/or GoG. And PlayStation 4 is very successful worldwide. XBoxOne is mainly successful in US and has little presents worldwide, Microsoft even stopped announcing sales two years ago - it's that bad. Nor are there any new exclusive games to speak of, PS4 has dozends of exclusive games, Win7+ has millions of exclusive games. Win10 Store is a complete desaster, worst software ever and hardly anyone would use it to buy games, if there are far better alternatives like Steam and GoG. Is DirectX 12 still a thing?
Regardless of urban legends, game consoles have their own graphic APIs.
PlayStation 4 doesn't use OpenGL either, rather LibCGM.
From all other PlayStations, including the portable ones, only the PlayStation 3 did support a mixture of OpenGL 1.0 + NVidia's Cg for shaders in addition to their actual graphics API. Almost no one ever bother with it, other than creating game prototypes.
Nintendo Switch has adopted Vulkan, but it remains to be seen if it will be any more successful on the market than Wii U was. None of the other Nintendo consoles do support OpenGL, rather they have an OpenGL-like API, GX and GX2.
Actually if it wasn't for Apple's adoption of OpenGL ES 1.0 for the iPhone, the first hardware support after Nokia's N95, it wouldn't probably ever taken off on the mobile devices.
PlayStation 4 doesn't use OpenGL either, rather LibCGM.
From all other PlayStations, including the portable ones, only the PlayStation 3 did support a mixture of OpenGL 1.0 + NVidia's Cg for shaders in addition to their actual graphics API. Almost no one ever bother with it, other than creating game prototypes.
Nintendo Switch has adopted Vulkan, but it remains to be seen if it will be any more successful on the market than Wii U was. None of the other Nintendo consoles do support OpenGL, rather they have an OpenGL-like API, GX and GX2.
Actually if it wasn't for Apple's adoption of OpenGL ES 1.0 for the iPhone, the first hardware support after Nokia's N95, it wouldn't probably ever taken off on the mobile devices.
Revisit this topic when graphics APIs lock-in age will come to an end.
Middleware has already settled that question several years ago, only FOSS advocates without experience in the games industry keep wishing for a different outcome.
[deleted]
Nothing is settled, until the tax of supporting multiple APIs exist. Don't imagine it comes for free. The price is paid, whether it's in the middleware or not. You pay this tax in various ways, from slower progress of game engines, to more bugs in your games. And it clearly demonstrates the intent. Those who push this tax on developers don't want faster progress and higher quality. They want lock-in.
Like I said, without experience in the games industry.
That is not how professional game developers see it, attending a few GDC would help to understand this.
Or if you don't want to pay for a ticket, there are plenty of talks available for free at GDC Vault.
That is not how professional game developers see it, attending a few GDC would help to understand this.
Or if you don't want to pay for a ticket, there are plenty of talks available for free at GDC Vault.
> That is not how professional game developers see it, attending a few GDC would help to understand this.
Do you wish to enlighten the HN community with the perspective you keep teasing? Or should we assume it's simply a narrative you wish to support?
Many companies have invested a lot of money into building various types of middleware as far as I understand it. But no matter how you slice it if you want to support multiple graphics APIs you do have to pay a tax in doing the QA and possibly custom development for each one.
I'm not sure how you get around that but...
> Or if you don't want to pay for a ticket, there are plenty of talks available for free at GDC Vault.
This isn't helpful and does not add to the conversation.
Do you wish to enlighten the HN community with the perspective you keep teasing? Or should we assume it's simply a narrative you wish to support?
Many companies have invested a lot of money into building various types of middleware as far as I understand it. But no matter how you slice it if you want to support multiple graphics APIs you do have to pay a tax in doing the QA and possibly custom development for each one.
I'm not sure how you get around that but...
> Or if you don't want to pay for a ticket, there are plenty of talks available for free at GDC Vault.
This isn't helpful and does not add to the conversation.
> But no matter how you slice it if you want to support multiple graphics APIs you do have to pay a tax in doing the QA and possibly custom development for each one.
Because the portability of APIs like OpenGL only happens in theory when you restrain yourself to a specific set of hardware.
The combinatory explosion of vendor extensions, driver bugs, shading language differences across versions and drivers, differences between OpenGL and OpenGL ES, force any studio that wants to keep sanity in their code, to write an OpenGL adaption layer anyway.
So if one if forced to write an adaptation layer anyway, then better go for the API that properly exposes all hardware features with less bugs and better tooling support.
This is one reason that while there are third party OpenGL wrappers to game consoles, or even first party ones like on the PS3, no one bothers to use them.
Taking the PS3 as an example, OpenGL ES doesn't define how to take advantage of the SPUs, other than via extensions anyway, thus making the code PS3 specific even if OpenGL ES is being use.
While at the same time less performant than the PS3 native API due to the OpenGL ES driver semantics.
Because the portability of APIs like OpenGL only happens in theory when you restrain yourself to a specific set of hardware.
The combinatory explosion of vendor extensions, driver bugs, shading language differences across versions and drivers, differences between OpenGL and OpenGL ES, force any studio that wants to keep sanity in their code, to write an OpenGL adaption layer anyway.
So if one if forced to write an adaptation layer anyway, then better go for the API that properly exposes all hardware features with less bugs and better tooling support.
This is one reason that while there are third party OpenGL wrappers to game consoles, or even first party ones like on the PS3, no one bothers to use them.
Taking the PS3 as an example, OpenGL ES doesn't define how to take advantage of the SPUs, other than via extensions anyway, thus making the code PS3 specific even if OpenGL ES is being use.
While at the same time less performant than the PS3 native API due to the OpenGL ES driver semantics.
All this assumes, you need to use non portable extensions every time. It could be reasonable in the past, it's way less reasonable today. And using a whole different API is surely more complex, than adapting usage of portable API to differences of potential targets, depending on features which they support.
It's pretty easy to check what's supported by the driver and decide whether to use some optional feature.
It's pretty easy to check what's supported by the driver and decide whether to use some optional feature.
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.
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.
> Attend their talks about graphic APIs.
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.
> Lock-in is only in the heads of FOSS advocates
Oh, now you are trying to deny that lock-in exists? Then read about it from those who actually push it on developers: https://en.wikipedia.org/wiki/Criticism_of_Microsoft#Vendor_...
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.
> Lock-in is only in the heads of FOSS advocates
Oh, now you are trying to deny that lock-in exists? Then read about it from those who actually push it on developers: https://en.wikipedia.org/wiki/Criticism_of_Microsoft#Vendor_...
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.
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".
> 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.
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.
> 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.
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.
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.
> 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 Vulkan. OpenGL doesn't offer enough control to address such cases and isn't even designed to be parallelized.
> 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.
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.
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.
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.
> No-one claims that gamedevs see lock-in as something positive
Not according to pjmlp apparently, who tried to claim lock-in doesn't even exist, except in the mind of FOSS developers.
Not according to pjmlp apparently, who tried to claim lock-in doesn't even exist, except in the mind of FOSS developers.
The tax of supporting multiple APIs is not always huge. I recall reading that Unreal's Vulkan support was done by 1 or 2 employees.
> The tax of supporting multiple APIs is not always huge. I recall reading that Unreal's Vulkan support was done by 1 or 2 employees.
And because of that, we still don't see full Vulkan support there - it takes time to implement. See https://trello.com/b/gHooNW9I/ue4-roadmap (search for Vulkan).
If anything, it highlights the tax, not disproves its existence.
And because of that, we still don't see full Vulkan support there - it takes time to implement. See https://trello.com/b/gHooNW9I/ue4-roadmap (search for Vulkan).
If anything, it highlights the tax, not disproves its existence.
Because DX12 gives you support for 2 out of the 3 major AAA platforms.
Sony seems to have no inclination of supporting Vulcan as a native API for the PS4/PS4pro.
Vulkan is also not Mantle, it's similar to the original Spec which was written by Johan Andersson from DICE. AMD did give Khronos the spec but there isn't some shared code implementation for Vulkan that is based on Mantle, there isn't a common shared library in general as the implementation for each IHV/System is proprietary.
Vulkan is still a camel, not as much as OpenGL but a camel nonetheless, it's currently quite behind DX as far as featureset goes and Vulkan Next which would add needed features such as mGPU support seems lag into late 2017.
Vulkan is a good alternative but it already shows some signs of getting it self into the same position that OpenGL found it self.
It's also worth noting that DX12 development has nothing to do with Mantle, it's a continuation of the Xbox 360 API and effectively the mature version of the API developed for the Xbox One.
Vulkan is also not Mantle, it's similar to the original Spec which was written by Johan Andersson from DICE. AMD did give Khronos the spec but there isn't some shared code implementation for Vulkan that is based on Mantle, there isn't a common shared library in general as the implementation for each IHV/System is proprietary.
Vulkan is still a camel, not as much as OpenGL but a camel nonetheless, it's currently quite behind DX as far as featureset goes and Vulkan Next which would add needed features such as mGPU support seems lag into late 2017.
Vulkan is a good alternative but it already shows some signs of getting it self into the same position that OpenGL found it self.
It's also worth noting that DX12 development has nothing to do with Mantle, it's a continuation of the Xbox 360 API and effectively the mature version of the API developed for the Xbox One.
> It's also worth noting that DX12 development has nothing to do with Mantle, it's a continuation of the Xbox 360 API and effectively the mature version of the API developed for the Xbox One.
... significant parts of DX12 are a carbon copy of Vulcan. Are you saying they ended up with the exact same solutions, including things like error codes that are entirely arbitrary choices, by accident?
DX12, and the Xbox One API was NOT developed from the Xbox 360 API. It's based on Mantle. As is Vulkan.
... significant parts of DX12 are a carbon copy of Vulcan. Are you saying they ended up with the exact same solutions, including things like error codes that are entirely arbitrary choices, by accident?
DX12, and the Xbox One API was NOT developed from the Xbox 360 API. It's based on Mantle. As is Vulkan.
Vulkan was influenced by DX12 designs not the other way around, Vulkan is currently lagging behind.
Mantle was written by Johan Andersson and as a result of DICE working on FB3 for the XboxOne.
The Vulkan spec diverges quite a bit from Mantle and is considerably closer to DX12, and again this isn't because DX12 somehow copies Vulkan, but because quite a few of the people involved like Niklas Smedberg and Aras Pranckevicius have been working with the XboxOne/PS4 for quite a while.
The Vulkan spec diverges quite a bit from Mantle and is considerably closer to DX12, and again this isn't because DX12 somehow copies Vulkan, but because quite a few of the people involved like Niklas Smedberg and Aras Pranckevicius have been working with the XboxOne/PS4 for quite a while.
https://twitter.com/repi/status/446718535616585730
Direct3D 12 blog with some more details: http://blogs.msdn.com/b/directx/archive/2014/03/20/directx-1... … You may recognize the design ;)
https://twitter.com/renderpipeline/status/581086347450007553
I had a déjà vu while reading in the #DirectX12 specs… #mantle
Direct3D 12 blog with some more details: http://blogs.msdn.com/b/directx/archive/2014/03/20/directx-1... … You may recognize the design ;)
https://twitter.com/renderpipeline/status/581086347450007553
I had a déjà vu while reading in the #DirectX12 specs… #mantle
Look into the history of Mantle, why Johan Andersson wrote the spec as it was, gamedev is a good place to start.
While you'll keep repeating unfounded vague claims, and I'm talking for your original claim that DX12 influenced Vulcan/Mantle I'll keep posting links that prove the exact opposite.
> We’ve spoken to several sources with additional information on the topic who have told us that Microsoft’s interest in developing a new API is a recent phenomenon, and that the new DirectX (likely DirectX 12) will substantially duplicate the capabilities of AMD’s Mantle.
https://www.extremetech.com/gaming/177407-microsoft-hints-th...
> We’ve spoken to several sources with additional information on the topic who have told us that Microsoft’s interest in developing a new API is a recent phenomenon, and that the new DirectX (likely DirectX 12) will substantially duplicate the capabilities of AMD’s Mantle.
https://www.extremetech.com/gaming/177407-microsoft-hints-th...
Stop spreading misinformation, Vulkan was not influenced by DX12.
> Vulkan is derived from and built upon components of AMD's Mantle API, which was donated by AMD to Khronos with the intent of giving Khronos a foundation on which to begin developing a low-level API that they could standardize across the industry, much like OpenGL.
https://en.wikipedia.org/wiki/Vulkan_(API)
> Vulkan is derived from and built upon components of AMD's Mantle API, which was donated by AMD to Khronos with the intent of giving Khronos a foundation on which to begin developing a low-level API that they could standardize across the industry, much like OpenGL.
https://en.wikipedia.org/wiki/Vulkan_(API)
It's not misinformation, AMD delivered the mantle spec to Khronos, but you are ignoring the fact the mantle spec was nearly single handedly written by Johan Andersson and was derived from his work on building Frostbite for consoles.
Vulkan then was influenced by quite a few other people from Unity, Epic and Valve.
DX12 is the base for XBox One API so it's going to be a thing, I suppose, until MS pulls out of console business (but I don't see why they would, the original XBox was a bigger disaster yet they stayed). After all, both Sony and Nintendo use their proprietary APIs too.
The reason you need a proprietary API on a console is that you cannot make a game running on a $200-300 piece of consumer electronics compete with a game running on a $1000+ PC if they both use the same API. There is a lot of work a DX/OpenGL driver does behind the scenes to make the same code run on GPUs of different architectures while sharing the same device with other processes. When you target only one GPU in exclusive mode you can do the same things so much faster.
The reason you need a proprietary API on a console is that you cannot make a game running on a $200-300 piece of consumer electronics compete with a game running on a $1000+ PC if they both use the same API. There is a lot of work a DX/OpenGL driver does behind the scenes to make the same code run on GPUs of different architectures while sharing the same device with other processes. When you target only one GPU in exclusive mode you can do the same things so much faster.
Nintendo started to use Vulkan, so things are moving in the right direction, though pretty slowly.
> The reason you need a proprietary API on a console is that you cannot make a game running on a $200-300 piece of consumer electronics compete with a game running on a $1000+ PC if they both use the same API.
Their primary reason is to tax developers who want to release games cross platform. In practice, no one prevents console makers from making more expensive high end consoles. Those who want demanding games, would buy more expensive hardware. Console is just a type of human interface, nothing inherently in it requires it to be cheap. Same as in regular PCs. The only reason current incumbent consoles are like that is lack of proper competition in their space. Compare it to mobile hardware where competition is fierce.
> The reason you need a proprietary API on a console is that you cannot make a game running on a $200-300 piece of consumer electronics compete with a game running on a $1000+ PC if they both use the same API.
Their primary reason is to tax developers who want to release games cross platform. In practice, no one prevents console makers from making more expensive high end consoles. Those who want demanding games, would buy more expensive hardware. Console is just a type of human interface, nothing inherently in it requires it to be cheap. Same as in regular PCs. The only reason current incumbent consoles are like that is lack of proper competition in their space. Compare it to mobile hardware where competition is fierce.
I don't develop for Nintendo so I am curious, is it like PS3 support for OpenGL or is it an actual native API?
And to reply to your edit: It's true, nobody prevents anybody from making $1000+ consoles. They sell for shit though. Even PS3 suffered from being a $600 console a lot, a $1000 console would be as successful as the Steambox.
And to reply to your edit: It's true, nobody prevents anybody from making $1000+ consoles. They sell for shit though. Even PS3 suffered from being a $600 console a lot, a $1000 console would be as successful as the Steambox.
The Switch supports Vulkan but it also has its own native API. It's a bit early to tell but it looks from my perspective a lot like OpenGL on PS3, though perhaps with a bit more adoption since Vulkan is more suited to console-style dev and the Switch has less "weird" hardware like the SPUs to get in the way of a standard API.
It's not about supporting weird hardware but about removing the unnecessary abstraction. E.g. in Vulkan you cannot directly write non-uniform inputs for the shaders because different GPUs may need that data in different formats and layouts. There is absolutely no reason to do this on a console, which only has one GPU and the layout of its data is very well known so you can just save a whole bunch of unnecessary code and gain an ability to use GPU compute to set up your draws on top of that.
And how much of a benefit it gives vs requiring to make a completely different set of shaders which you can't even reuse? That's a strong claim that you can't have good performance, after SPIR-V is translated by the compiler.
I am not sure what are you talking about here (how is setting up inputs for a shader related to SPIR-V, which is IR format for shader code?) but, as I said and you denied, this how you get a game running on a $200-$300 console look the same as a game running on a $1000-$2000 PC.
They support OpenGL and Vulkan now natively on their Switch console. I.e. proper support, and not some fake pseudo API.
> They sell for shit though.
All it means, that most of those who use consoles don't want to play high end games. And console makers aren't incentivized to market that, because they don't have much competitors.
Compare it to mobile hardware as I said. You could argue, that people also don't want to overpay for it. Yet, mobile hardware makers rush to refresh it way more frequently than console makers do, and prices there are more realistic. Competition helps.
> a $1000 console would be as successful as the Steambox.
It would surely sell less than cheaper ones, but same goes for regular PCs. Only a minority of enthusiasts buy high end computers. The vast majority buy weak laptops and such. But gaming market can address both use cases. I don't see how interface of controller vs mouse + keyboard is supposed to change that.
> They sell for shit though.
All it means, that most of those who use consoles don't want to play high end games. And console makers aren't incentivized to market that, because they don't have much competitors.
Compare it to mobile hardware as I said. You could argue, that people also don't want to overpay for it. Yet, mobile hardware makers rush to refresh it way more frequently than console makers do, and prices there are more realistic. Competition helps.
> a $1000 console would be as successful as the Steambox.
It would surely sell less than cheaper ones, but same goes for regular PCs. Only a minority of enthusiasts buy high end computers. The vast majority buy weak laptops and such. But gaming market can address both use cases. I don't see how interface of controller vs mouse + keyboard is supposed to change that.
> All it means, that most of those who use consoles don't want to play high end games.
It's actually opposite. Console audience (maybe with exception for Nintendo) wants to play high end games. This is why high end games sell much more on console SKUs. If by "high end" you mean AAA, of course.
It's actually opposite. Console audience (maybe with exception for Nintendo) wants to play high end games. This is why high end games sell much more on console SKUs. If by "high end" you mean AAA, of course.
Well, if they really want high end games, they shell out for PCs and high end GPUs, because as you said, current consoles simply are behind. No API can work around that.
By high end I mean demanding, those which heavily load the GPU, and benefit from better ones.
So IMHO those who stick to current day consoles, are OK with not getting the max settings in demanding games. But why those who do want more, can't play their games using controller / sofa style gaming? I.e. I don't see an inherent relation between console style gaming and avoiding more expensive hardware.
By high end I mean demanding, those which heavily load the GPU, and benefit from better ones.
So IMHO those who stick to current day consoles, are OK with not getting the max settings in demanding games. But why those who do want more, can't play their games using controller / sofa style gaming? I.e. I don't see an inherent relation between console style gaming and avoiding more expensive hardware.
API works around just fine like I said. I cannot recall any recent (in the past 10 years) AAA games, which don't run on the consoles. PC exclusives have not been setting graphcis bar for a long while.
> API works around just fine like I said. I cannot recall any recent (in the past 10 years) AAA games, which don't run on the consoles.
But they all run with reduced settings, and their non console versions offer higher quality on better hardware (if developers of course took care of taking advantage of that and make it all configurable).
So I'm really not sure how API can change the simple fact that current day consoles are underpowered in comparison with modern high end PC hardware.
But they all run with reduced settings, and their non console versions offer higher quality on better hardware (if developers of course took care of taking advantage of that and make it all configurable).
So I'm really not sure how API can change the simple fact that current day consoles are underpowered in comparison with modern high end PC hardware.
>with reduced settings
Not sure what you mean by this. MGS V, for example, runs with more effects on PS4 than on my PC with Geforce 980Ti (which alone costs as much as two PS4s btw). Anyways, this conversation is stupid. It's not a Console vs PC flamewar. Nobody forbids you from buying a $10K PC with colored lights everywhere and setting all the settings to 11. And if you think it's a good business, this being an entrepreneur site, you should starting making those and selling to others, driving stupid console developers out of business and laughing while doing so.
Not sure what you mean by this. MGS V, for example, runs with more effects on PS4 than on my PC with Geforce 980Ti (which alone costs as much as two PS4s btw). Anyways, this conversation is stupid. It's not a Console vs PC flamewar. Nobody forbids you from buying a $10K PC with colored lights everywhere and setting all the settings to 11. And if you think it's a good business, this being an entrepreneur site, you should starting making those and selling to others, driving stupid console developers out of business and laughing while doing so.
I haven't played it myself yet (waiting for Wine to support it on Linux), but I'm sure I've red somewhere, that The Witcher 3 uses reduced settings on consoles and you can't change them there. Developers explicitly recommended running the game on better hardware for those who want max graphics settings. It makes perfect sense to me. Developers use what the hardware allows.
"Developers use what the hardware allows."
Nonsense. Developers use hardware as well as they understand within given project constraints.
Optimizing modern game engine to run fast is generally considered a non-trivial task. The more arbitrary the hardware platform, the harder it is to optimize.
Yes, if PC port had to target only a specific, known, hardware and software combination (say a specifiv i7 with gtx 1080) then they could probably optimize the shit out of it.
A console is a fixed, known target. Thus it takes much less resources to optimize for it - thus developers can reuse their understanding from project to project.
The AAA game scene is full of recent examples with crawling PC ports, such as Arkham Knight.
Nonsense. Developers use hardware as well as they understand within given project constraints.
Optimizing modern game engine to run fast is generally considered a non-trivial task. The more arbitrary the hardware platform, the harder it is to optimize.
Yes, if PC port had to target only a specific, known, hardware and software combination (say a specifiv i7 with gtx 1080) then they could probably optimize the shit out of it.
A console is a fixed, known target. Thus it takes much less resources to optimize for it - thus developers can reuse their understanding from project to project.
The AAA game scene is full of recent examples with crawling PC ports, such as Arkham Knight.
On which platform? I would LOVE some sources on this! (seriously! I would really appreciate it)
See https://www.khronos.org/conformance/adopters/conformant-prod...
(Search for Nintendo there).
They support Vulkan on the Switch, which shows that they now see benefits in using cross platform APIs.
(Search for Nintendo there).
They support Vulkan on the Switch, which shows that they now see benefits in using cross platform APIs.
<3 thank you! This makes me so much happier about my Switch preorder for gamedev purposes :)
For me personally, Nintendo is way too locked up and DRMed. I'm more interested in something like this: https://www.kickstarter.com/projects/smachteam/smach-z-the-h...
But it's good that they are pushing Vulkan forward.
But it's good that they are pushing Vulkan forward.
Beware all who are reading below this comment: it's aggressively misinformed. It starts with this comment, which is almost completely inaccurate. And then it continues from there. Wth HN...
> Is DirectX 12 still a thing?
Unfortunately, while MS will require DX for Xbox, it will remain a thing. It's not needed otherwise.
Unfortunately, while MS will require DX for Xbox, it will remain a thing. It's not needed otherwise.
So now all the "NDA" excuses for not releasing graphic drivers source code are gone?
Releasing source for graphics drivers has zero to do with this DirectX Shader Compiler going open source. This compiler just compiles from HLSL to DXIL. During run-time, the application submits DXIL to the IHV driver for compilation into machine bytecode. And that compiler is still closed-source, at least for most GPU use cases.
I don't understand what you thought you'd accomplish with your comment. It's almost a willful attempt at not understanding what the project/event is about.
I don't understand what you thought you'd accomplish with your comment. It's almost a willful attempt at not understanding what the project/event is about.
One really has nothing to do with the other in this case.
1. It never did exist
2. AMD has
3. Nvidia won't because their GPU does a lot of magic to fix DX9/DX10/DX11 screw ups some people shops who've partnered with Nvidia leave in their code.
2. AMD has
3. Nvidia won't because their GPU does a lot of magic to fix DX9/DX10/DX11 screw ups some people shops who've partnered with Nvidia leave in their code.
I’ve heard a bit about the last point but I’d like to know more. Can you elaborate?
I think the third point is about that testimony:
https://www.gamedev.net/topic/666419-what-are-your-opinions-...
https://www.gamedev.net/topic/666419-what-are-your-opinions-...
That gets linked every now and then and it's pretty much BS, coming from someone who was an intern for a few months.
Yes, there are workarounds and tweaks in the driver but it there was no other way back when games were shipped on a CD and updates were necessarily not applied. But even today it's not an option for AMD/NVidia/Intel to ship a driver update that will knowingly break Doom/Quake or any other shipping title. If a released product relies on a driver bug, the driver bug must be there indefinitely unless the game/app developer ships an update (which they might not do, the game might be years old and no longer supported).
If you got a driver update that broke your game or hindered performance, you would be upset.
Case in point: GLSL compilers which accept invalid input. That just can't be fixed without breaking some existing use.
Then there are different strategies how the driver might implement Direct3D/OpenGL feature X. If 98% of the cases Strategy A is better but for a popular game Startegy B is better, the driver will selectively enable strategy that for a specific game. This is typically done in collaboration with the game developer and the GPU driver developers.
Some years ago, cheating in benchmarks was rather common (and unsurprising). Benchmark results have disproportionate impact on sales and cheating, however dishonest, was a way to make a lot of sales with relatively little effort. I am under the impression that these days there are legally binding contracts between the manufacturers and benchmark companies that disallow this dubious practice.
But in reality, most of the driver workarounds/hacks are artifacts of closed source development and binary releases and almost everyone benefits from them. The customer gets better performance, the game developer doesn't have to do as many workarounds (although it's beneficial for them to have a working relationship with the GPU vendors) and the GPU company gets sales because your favorite game runs better.
I understand that this is giving some grief to indie developers and open source hackers. Not everyone can or wants to sign an NDA required for collaborating with GPU vendors.
Please stop re-posting that forum post. It does not accurately reflect the reality.
disclaimer: I'm a GPU driver programmer.
Yes, there are workarounds and tweaks in the driver but it there was no other way back when games were shipped on a CD and updates were necessarily not applied. But even today it's not an option for AMD/NVidia/Intel to ship a driver update that will knowingly break Doom/Quake or any other shipping title. If a released product relies on a driver bug, the driver bug must be there indefinitely unless the game/app developer ships an update (which they might not do, the game might be years old and no longer supported).
If you got a driver update that broke your game or hindered performance, you would be upset.
Case in point: GLSL compilers which accept invalid input. That just can't be fixed without breaking some existing use.
Then there are different strategies how the driver might implement Direct3D/OpenGL feature X. If 98% of the cases Strategy A is better but for a popular game Startegy B is better, the driver will selectively enable strategy that for a specific game. This is typically done in collaboration with the game developer and the GPU driver developers.
Some years ago, cheating in benchmarks was rather common (and unsurprising). Benchmark results have disproportionate impact on sales and cheating, however dishonest, was a way to make a lot of sales with relatively little effort. I am under the impression that these days there are legally binding contracts between the manufacturers and benchmark companies that disallow this dubious practice.
But in reality, most of the driver workarounds/hacks are artifacts of closed source development and binary releases and almost everyone benefits from them. The customer gets better performance, the game developer doesn't have to do as many workarounds (although it's beneficial for them to have a working relationship with the GPU vendors) and the GPU company gets sales because your favorite game runs better.
I understand that this is giving some grief to indie developers and open source hackers. Not everyone can or wants to sign an NDA required for collaborating with GPU vendors.
Please stop re-posting that forum post. It does not accurately reflect the reality.
disclaimer: I'm a GPU driver programmer.
https://github.com/Microsoft/DirectXShaderCompiler/blob/mast...
I'm sure it was a script, but this needs to be fixed, stat.
Sadly, not even the first time: https://github.com/Microsoft/WinObjC/issues/35
https://news.ycombinator.com/item?id=10024377
https://news.ycombinator.com/item?id=10018208 (which devolved into a licensing discussion)
It'd be nice if folks paid a little more attention, because for releases from large companies, stuff spreads quickly, which means a year from now, there are still likely to be "mit licensed" copies of this that are still wrong :(