While it's really nice they built this on open source compiler infrastructure, it's also too bad they took all the LLVM code and changed the license headers on it (additionally pretending to relicense it and changing the copyright string) when that's 100% not okay:
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.
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.
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.
> 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. :-)
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.
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.
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.
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.
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.
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.
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.
Middleware has already settled that question several years ago, only FOSS advocates without experience in the games industry keep wishing for a different outcome.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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...
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 :(