New DirectX Shader Compiler Based on Clang/LLVM Open-Sourced(blogs.msdn.microsoft.com) |
New DirectX Shader Compiler Based on Clang/LLVM Open-Sourced(blogs.msdn.microsoft.com) |
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 :(
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
... 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.
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.
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.
Unfortunately, while MS will require DX for Xbox, it will remain a thing. It's not needed otherwise.
https://www.gamedev.net/topic/666419-what-are-your-opinions-...
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.
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.
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.
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"
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. :-)
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 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.
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
> 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.
> 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...
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.
> 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.
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.
(Search for Nintendo there).
They support Vulkan on the Switch, which shows that they now see benefits in using cross platform APIs.
But it's good that they are pushing Vulkan forward.
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.
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.
It's pretty easy to check what's supported by the driver and decide whether to use some optional feature.
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.
> 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.
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.
Not according to pjmlp apparently, who tried to claim lock-in doesn't even exist, except in the mind of FOSS developers.
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.
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.
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.
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.
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.
> 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".
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.
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.
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.
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.
> The AAA game scene is full of recent examples with crawling PC ports, such as Arkham Knight.
Poor quality games isn't an good example of proper hardware usage. There was a time when AAA meant quality. Today it can mean any junk as long as it's funded by big publisher.
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.
If you want to evolve your API together with the hardware, you need some extension mechanism.
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?
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.