
New DirectX Shader Compiler Based on Clang/LLVM Open-Sourced - xamlhacker
https://blogs.msdn.microsoft.com/directx/2017/01/23/new-directx-shader-compiler-based-on-clangllvm-now-available-as-open-source/
======
DannyBee
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:

[https://github.com/Microsoft/DirectXShaderCompiler/blob/mast...](https://github.com/Microsoft/DirectXShaderCompiler/blob/master/include/llvm/IR/Instruction.h#L5-L7)

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://github.com/Microsoft/WinObjC/issues/35)

[https://news.ycombinator.com/item?id=10024377](https://news.ycombinator.com/item?id=10024377)

[https://news.ycombinator.com/item?id=10018208](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 :(

~~~
pjc50
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/)

~~~
karim
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.

~~~
jpgvm
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.

------
shmerl
Hopefully it will be of some help for this effort:
[https://github.com/KhronosGroup/glslang/issues/362](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.

~~~
dtech
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.

~~~
wolfgke
> 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...](https://en.wikipedia.org/w/index.php?title=Shared_Source_Common_Language_Infrastructure&oldid=722315020)

So don't do a corruption of historical facts.

~~~
josephcooney
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.

~~~
krylon
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.

~~~
my123
.NET Core on Linux runs on guess what... Rotor. Rotor has been relicensed to
MIT

------
pitaj
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.

~~~
wolfgke
> 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.

------
faragon
So now all the "NDA" excuses for not releasing graphic drivers source code are
gone?

~~~
valarauca1
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.

~~~
john_reel
I’ve heard a bit about the last point but I’d like to know more. Can you
elaborate?

~~~
blencdr
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-on-
dx12vulkanmantle/#entry5215019)

~~~
exDM69
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.

------
frik
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?

~~~
pjmlp
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.

~~~
shmerl
Revisit this topic when graphics APIs lock-in age will come to an end.

~~~
pjmlp
Middleware has already settled that question several years ago, only FOSS
advocates without experience in the games industry keep wishing for a
different outcome.

~~~
shmerl
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.

~~~
pjmlp
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.

~~~
shmerl
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"?

~~~
pjmlp
> 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.

~~~
shmerl
_> 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_...](https://en.wikipedia.org/wiki/Criticism_of_Microsoft#Vendor_lock-
in)

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.

~~~
pjmlp
> 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.

~~~
shmerl
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".

~~~
pjmlp
> 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.

~~~
shmerl
OpenGL wasn't portable enough to be performant at the same time, for several
reasons. I'm talking about Vulkan, not about OpenGL and its troubles in the
past. Vulkan addresses the issues which you mentioned.

~~~
royjacobs
Vulkan still has extensions. The whole reason game developers want to have
lock-in is so that you can squeeze the maximum possible quality out of a known
set of hardware.

Once you start abstracting that away you are falling behind other companies
who may be able to draw slightly more particles at slightly higher frame rates
at slightly higher resolutions.

The whole reason Nintendo is still saying "we have Vulkan" is because they are
the only console manufacturer were raw graphical performance was never the
system seller.

~~~
tinus_hn
Lock-in doesn't cause you to be able to 'squeeze performance' out of the
hardware. It causes you to specialize your code to the platform so much you
can't port it to another.

It's the other way around. Developers don't care much about portability. The
care about APIs that allow them to build performant programs. For them, a bad
side effect of such APIs is vendor lock-in.

Why would a game developer want to limit his audience?

~~~
wolfgke
> Lock-in doesn't cause you to be able to 'squeeze performance' out of the
> hardware.

Let's assume GPU X supports some feature that GPU Y does not. Then you either
use an (say OpenGL or Vulkan) extension to use it to squeeze out performance
(lock-in) or you eschew the lock-in, don't use the feature and ignore the
performance advantage. Now multiply this with lots of features and also
consider that the graphic APIs of consoles offer some rather unique features
that don't map directly to, say, DirectX11 or OpenGL.

