Neuigkeiten zu DirectX 12 und Windows 10

[NoFake3D]

As a part of the Windows team, we’re super excited about the Windows 10 Technical Preview that was just released! The final version of Windows 10 will ship with DirectX 12, and we think it's going to be awesome.

We especially encourage gamers to help us make this release great for you by becoming Windows Insiders. Game developers who are part of our DirectX 12 Early Access program have even more incentive to join the Windows Insider program. These game developers will receive everything they need to kickstart their DX12 development, including: updated runtime, API headers, drivers, documentation, and samples, all of which will work with the Windows 10 Technical Preview

http://blogs.msdn.com/b/directx/archive ... ws-10.aspx

[NoFake3D]

Um Grafik-Debugging und Frame-Analyse in Windows 10 Technical Preview nutzen zu können, wird folgendes Update benötigt:


https://dev.windows.com/en-us/develop/g ... sis-update

Update for the Visual Studio Graphics Debugging and Frame Analysis feature



To use the Graphics Debugging and Graphics Frame Analysis feature of Visual Studio 2013 with Windows 10 Technical Preview, you must install the Windows 10 Technical Preview versions of D3D SDK layers DLLs. Note that this workaround will not be required in future releases.

To install the D3D SDK DLLs on your development PC, you need to extract the zip file below into the Windows directory on your PC. This will place files into your System32 and SysWow64 directories that are located in the Windows directory. You will need to do this from an account that is an administrator on the system.

MSFT - Bryan Langley

Thanks for the comments and questions. Here are the answers to the questions:

Great find Rasterizer: To obtain the Windows 10 Technical Preview version of the DirectX Debug Layer DLLs required to successfully use D3D11_CREATE_DEBUG_DEVICE or the Visual Studio 2013 Graphics Diagnostics feature, download it from http://aka.ms/w10sdkfix. This will get integrated in a future version of the Window SDK for the RTM release of Windows 10.

1) Which parts of DX11 are updated - there are few updates to DX11, mostly bugfixes. We've been focused on DX12

2) Which DX12 is present - DX12 isn't present in these bits, it requires early access at this time. There are a few related components (such as warp) which have been updated to work with DX12, which are present.

3) WDDM/DX11 changes - I can't comment on WDDM changes yet or any improvements to DX11. I will say that we have spent a lot of time listening to game developers and have done a lot of engineering work to deliver what they've asked for - so we are certainly taking it seriously. We're very focused right now on making DX12 awesome. And, DX12 will work on >50% of the cards gamers already have today (including the 600 series you asked about), so most gamers won't need new hardware to realize the benefits of DX12 for games which support it.

4) Questions about what is in early access program- I can't share details of exactly what drivers are in the early access program, but I can tell you that all 3 IHVs you mentioned are actively working on drivers. Early access contains 12 only, no updates to 11.

5) Is D3D12 on top of D3D11? No, it is a lower level API.

6) Public SDK - I can't comment on when the public SDK will be available, but DX12 will be there when it is

[NoFake3D]

Windows 7 erhält laut AMD kein DirectX 12:

http://www.computerbase.de/2014-11/wind ... irectx-12/

Das bedeutet dann höchstwahrscheinlich: DirectX12 wird es für Windows 8.1 und Windows 10 geben.

Gruß,
Daniel

[WraithOne]

Soweit ich das gelesen hab heisst es unter Windows 7 auch DirectX 11.3 und beinhaltet die änderungen zum geringeren Overhead.
Die neuen features bleiben DirectX 12 vorbehalten.

[Schrompf]

Das wäre ein Deal, mit dem ich leben kann.

[Spiele Programmierer]

Nein, laut Artikel genau andersrum.
Es werden einfach die neuen Features in DX 11 mitintegriert, die Performanceverbesserungen sind DX 12 vorbehalten.

Bis jetzt ist noch nicht einmal DirectX 9 wirklich vollständig abgelöst. Die Entscheidung es Windows 10 only zu machen, würde die Position von DirectX wahrscheinlich nicht gerade stärken. Ich traue es Micrsoft aber zu.

[Schrompf]

Oh. Hm. Vielleicht müssen sie dazu das Treibermodell mal wieder ändern, weswegen sie solche Sprünge nur mit neuen OS-Versionen machen können. Vielleicht ist Microsoft aber auch ganz einfach der Trottel, der es immer war.

[WraithOne]

Ok, dann hab ich das falsch verstanden. Schade darum aber das ist wohl ein zu starkes Verkaufsagument für Windows 8/10.

[dot]

Oh. Hm. Vielleicht müssen sie dazu das Treibermodell mal wieder ändern, weswegen sie solche Sprünge nur mit neuen OS-Versionen machen können.

Da kannst du dir sicher sein. Ich wüsste nicht, wie eine API wie Direct3D 12 sinnvoll auf WDDM 1.x umsetzbar wäre, da das ganze Ressourcenmanagement völlig anders funktioniert. Der Grund, wieso DX 10+ nicht auf Windows XP lief, war die Notwendigkeit eines fundamental anderen Driver Models. So etwas lässt sich nicht einfach so mit einem Service Pack nachrüsten, zumindest wäre der Aufwand wohl enorm. Gleich wird es nun mit DX 12+ sein; wobei der Sprund zwischen XP und Vista noch ein paar Größenordnungen weiter war, als nun der zwischen Windows 8.x und 10 sein wird. Eine gewisse marketingtechnische Motivation ist natürlich nicht ganz von der Hand zu weisen, aber ich bin mir ziemlich sicher, dass die technischen Hürden hier der wesentliche Grund sind, insbesondere wenn man bedenkt, dass im Moment zumindest darüber spekuliert wird, dass Windows 10 möglicherweise als gratis Update zu Windows 8 released wird...

Ist wohl auch der Grund, wieso es, wenn ich das richtig verstanden hab, von der aktuellen Windows 10 Preview zwei Versionen gibt: Eine für das D3D12 early access program, die nur D3D12 supported und eine öffentlich zugängliche, die nur D3D11 supported...

[NoFake3D]

Windows 10: Für Besitzer von Windows 7, 8.1 und Windows Phone 8.1 kostenlos:

http://www.playnation.de/spiele-news/wi ... 58869.html

http://www.chip.de/news/Neues-Windows-1 ... 15348.html

[NoFake3D]

DirectX 12 wird es anscheinend, laut der folgenden Quellen, nur für Windows 10 geben:

DirectX 12 isn't coming to Windows 7 or 8

Aktuell existierende GPU's unterstützen anscheinend nur teilweise DirectX 12:

DirectX 12 does require a newer graphics card

Some existing hardware will be able to get some benefit out of the improved API but it's still unclear just how much

http://www.rockpapershotgun.com/2015/01 ... xbox-games
http://news.softpedia.com/news/DirectX- ... 0803.shtml
http://www.gamespot.com/articles/new-gr ... 00-6424846

[Ingrater]

Das ist wirklich ein trauerspiel. Wir müssen auf der Arbeit einen DX9 und DX11 Renderer pflegen weil viele unserer Kunden noch unter XP unterwegs sind. Wenn jetzt für DirectX 12 wieder ein Betriebssystem upgrade vorrausgesetzt wird sehe ich schon, dass wir entweder 3 Renderer pflegen müssen oder DirectX 12 gar nicht erst unterstützt wird...

[NytroX]

Ich verstehe die Leute nicht, XP kam vor 14 Jahren raus.
XP und Win 10 ist ein Unterschied wie Pacman und Warcraft 2... und damals ging die Entwicklung wesentlich langsamer voran.

Handy kauft man auch alle 2 Jahre neu, warum stellen die Leute sich bei PCs immer so an? Schmeißt doch den alten Mist endlich weg :D

DirectX funktioniert (seit Vista) so, dass Microsoft einen Teil der Programmierung übernimmt, damit die trotteligen Grafikkarten-Hersteller nicht wieder das ganze System mit halb-garen Kernel-Treibern lahmlegen.
Weil dann heulen wieder alle "Buhuuuuh, mein Windows kann nur blaue Bildschirme zeigen!"
Daher impliziert ein größeres DX-Update auch oft ein WDDM-Update, und dann ist die Kompatibilität halt futsch.

Aber ich verstehe nicht ganz warum ein WDDM-Update immer ein anderes OS braucht.
Ich meine, ist ja schon klar, dass man nicht mal eben das halbe System kurz neu kompiliert, wie bei Linux.
Bzw. macht man ja, aber man erhöht dabei halt die Minor-Versionsnummer und verkauft es als neues System :P

Bei DX12 macht das aber schon Sinn, dass auch ein Update her muss, weil es ja ganz anders funktioniert. Aber zwischen Vista und 8.1 ... genauer gesagt zwischen Windows 6.0 und Windows 6.3 ... wurde echt viel gefrickelt.
Daher kann ich auch die Leute ein wenig verstehen, die darauf gerne verzichten wollen.
Das waren ja mehr oder weniger Beta-Tests für Win10; wobei ich persönlich auch gerne mal Vorab-Versionen installiere (z.b. VS2015, Vivaldi, Linux...) :mrgreen:

[Krishty]

Ich verstehe die Leute nicht, XP kam vor 14 Jahren raus.

Ich verstehe nicht, wie man den ganzen neuen Scheiß kaufen kann. Seit Windows 98 geht die Benutzeroberfläche NUR bergab. Windows XP hat zumindest den technischen Unterbau so stark verbessert, dass man den MSN-AOL-Spam und das Klickibunti in Kauf genommen hat. Aber danach wurde echt nur alles schlimmer. Aber das ist ja nicht das Thema, sondern

Aber ich verstehe nicht ganz warum ein WDDM-Update immer ein anderes OS braucht.
Ich meine, ist ja schon klar, dass man nicht mal eben das halbe System kurz neu kompiliert, wie bei Linux.
Bzw. macht man ja, aber man erhöht dabei halt die Minor-Versionsnummer und verkauft es als neues System :P

Bei XP war die Begrenzung auf D3D9, wie du schon sagtest, wegen der großen WDDM-Umstellung nicht praktikabel. Das ergab völlig Sinn, weil für Vista und 64-Bit-Systeme eh überall neue Treiber her mussten und jetzt viel mehr im User Space lief als vorher. Für Windows 10 muss man aber nicht alle Treiber neu schreiben. Man muss auch nicht den kompletten Unterbau des Betriebssystems aktualisieren, bloß, weil der Grafiktreiber anders funktioniert. Man macht nicht das ganze System kaputt, indem man die Änderungen zurückportiert. Es ist nur Marketing, damit die Leute endlich von Windows 7 wegkommen.

Wir müssen auf der Arbeit einen DX9 und DX11 Renderer pflegen weil viele unserer Kunden noch unter XP unterwegs sind. Wenn jetzt für DirectX 12 wieder ein Betriebssystem upgrade vorrausgesetzt wird sehe ich schon, dass wir entweder 3 Renderer pflegen müssen oder DirectX 12 gar nicht erst unterstützt wird...

Ich mache das Beste draus: Damit der Aufwand nicht mit 32- und 64-Bit-Version explodiert, liefere ich eine 32-Bit-D3D9-Version (mit VS 2010 kompiliert) und eine 64-Bit-D3D11-Version (mit dem neuesten VS kompiliert). 32-Bit-Anwender haben eh keinen prallen Gamer-PC und wahrscheinlich noch Windows XP und das ist dann auch so zerschossen dass man da die Redistributables nicht installieren will weil sofort irgendwas kaputtgehen würde. 64-Bit-Anwender haben aktuelle Systeme und kriegen dann auch das Eye Candy.

[NoFake3D]

Aktueller DirectX 12-Status-Bericht:
http://www.anandtech.com/show/8962/the- ... star-swarm

[Krishty]

Super, da ist ja sogar die Rechtfertigung eines Microsoft-Mitarbeiters drin:

A classic example of this is the Direct3D 11.1 API Platform Update for Windows 7, where my team brought the 11.1 API from Windows 8 back to Windows 7. There was a lot of negative press about the 11.1 hardware features not being supported on Windows 7 in that platform update, along with a significant amount of speculation in the press that the hardware features were turned off to create a need to upgrade to Windows 8. The actual truth is my team engineered the platform update to have full support for the hardware features in feature level 11.1. Exposing those hardware features requires the runtime query a new WDDM version and function table from the user mode drivers. When my team went into testing for the platform update, a significant number of hybrid laptop drivers and unsupported wrapper drivers for things like USB displays behaved erratically when a new driver version was queried. After months of ordering more laptops and devices to test, I eventually pulled the plug on querying a new WDDM version to resolve the remaining driver compatibility issues. The cost was too great for the features being added.

Also waren in erster Linie billig-Treiber und ihre miese Code-Qualität schuld. Früher war das Argument gegen eine Nachricht „Dieses Programm funktioniert nicht weil Firma XYZ nicht programmieren kann“ immer: Ist ein Treiber defekt und schreibt wild in den Speicher, stürzt am Ende ein anderer Treiber ab und die Nachricht zeigt auf den Falschen. Jetzt, wo Grafiktreiber im User Mode laufen und offensichtlich schon beim Initialisieren kaputtgehen, dürfte dem doch nichts mehr im Wege stehen. Wie haben sie bei Microsoft nicht immer gelabert, dass Treiberqualität wichtig ist und alles zertifiziert sein muss und dass es immer an den Treibern liegt und nie am Betriebssystem. Und dann ziehen sie den Schwanz ein, wenn das Problem nicht ihr Fingerfummel-OS betrifft sondern das davor. Bah.

Even if my team managed to keep the driver query intact, some APIs like EnqueueSetEvent on DXGI wouldn't work without an update to the kernel or a change in design for Windows 7. Such APIs were left disabled in the platform update based on "bang for buck" of dev effort.

Dann aktualisiert den scheiß Kernel halt?! Was macht ihr denn jeden Dienstag mit Windows Update?!

[NoFake3D]

Mini-DirectX 12 Hardware-FAQ von einem Entwickler mit DX12-Alpha-Zugang:

Here is a simple FAQ:
- Is D3D12 require new hardware?
No! The API will works fine with the existing GPUs if the D3D12 driver exist for them. The actual hardware support already announced.
- What about the features?
Some feature will go, and some feature will come.
The low-level APIs will simplify the access to the hardware. In the past, many new features came to the API because the driver actually hid the GPU memory from the application. So every new thing had to be implemented in the API, and then a new driver introduced the support for it. After this the application can access the new feature. D3D12 will allow explicit access to the GPU memory so some earlier features will not accessible in D3D12 in their "traditional D3D11 form". But this is not a problem, because with explicit memory access all of these (and many more) can be implemented in the application. For example tiled resources will be gone in the actual form, but it is possible to write an own implementation for it.
The resource model will be also advancing, so for example Typed UAV Load will be a new feature.
- Are these new features will require new hardware?
The best answer is yes and no. This is a complicated question, and hard to answer it when the specs are not public. But let's say Typed UAV Load will require hardware support. The GCN based Radeons can support it, as well the Maxwell v2 (GM206/GM204) architecture. Maybe more hardware can access the feature from NVIDIA, but I don't know because they don't disclose what possible with Maxwell v1/Kepler/Fermi. Intel might support it, but I'm not familiar with these iGPUs.
But many of these new features can be... I don't want to say emulated, but some workaround is possible. So even if the hardware support is not present, the actual effect might be executable on all GPUs. Of course, these workarounds will have some performance hit.

These are the most important things to know.

There are some other important things like the binding model. I have read frequently that D3D12 is bindless. No it's not. Bindless is only possible with AMD GCN, and NV Kepler/Maxwell. D3D12 is a universal API, so bindless is not suitable for it. But this doesn't mean that the D3D12 binding model is bad. It's actually very nice.

In this PDF you can see the resource binding tiers at page 39 (if you don't want to download the file than here is an image). This is the D3D12 binding table, and the GPUs must support one of these tiers.
Most of the GPUs support the first tier or TIER1.
Maxwellv2 (GM206 and GM204) support the second tier or TIER2.
All GCN-based Radeons support the third tier or TIER3.
I'm expect that all future hardware will support TIER3.

One more thing. We all know that D3D12 is built for efficiency. Yep, this is true, but Microsoft only talk about the batch performance. Everybody knows the advantages, it will mostly! eliminate the limitations on the CPU side.
There are two other features in D3D12 that will eliminate the limitations on the GPU side! These will help to speed up the rendering even when the application seems to be limited by the GPU.
These optional features are called asynchronous DMA and asynchronous compute. Simple definitions:
- Asynchronous DMA will allow data uploads without pausing the whole pipeline. It will need two active DMA engines in the GPU so this feature is supported by all GCN-based Radeons or Maxwellv2(GM206/GM204)-based GeForce. Most modern NVIDIA GPUs use two DMA engines, but one of these disabled on the GeForce product line, so in the past this was a professional feature. On the GM206/GM204 GPUs the two DMA not just present in the hardware but activated as well.
- Asynchronous compute allow overlapping of compute and graphics workloads. Most GPUs can use this feature, but not all hardware can execute the workloads efficiently. The GCN-based Radeons with 8 ACEs! are very good at this in my own tests.

I can't tell you more, because there is an embargo for some infos.

http://forums.anandtech.com/showthread.php?t=2422223

Und ein etwas älteres DirectX 12-PDF von Intel: Microsoft Direct3D 12: New API Details and Intel Optimizations:

http://api.viglink.com/api/click?format ... this%20PDF

Gruß,
Daniel

[NoFake3D]

Die ersten Game Developers Conference 2015-Videos:

http://channel9.msdn.com/Events/GDC/GDC ... erformance
http://channel9.msdn.com/Events/GDC/GDC ... Windows-10
http://channel9.msdn.com/Events/GDC/GDC ... ectX-Tools
http://channel9.msdn.com/Events/GDC/GDC ... Windows-10
http://channel9.msdn.com/Events/GDC/GDC ... -DirectX12


http://channel9.msdn.com/Events/GDC/GDC ... Core-World
http://channel9.msdn.com/Events/GDC/GDC ... le-devices
http://channel9.msdn.com/Events/GDC/GDC ... Developers
http://channel9.msdn.com/Events/GDC/GDC ... Windows-10
http://channel9.msdn.com/Events/GDC/GDC ... -Ecosystem
http://channel9.msdn.com/Events/GDC/GDC ... Windows-10

Empfehlenswert:

Advanced DirectX12 Graphics and Performance
Developing Games for Windows 10
Solve the Tough Graphics Problems with your Game Using DirectX-Tools
PC Games for Windows 10
Better Power, Better Performance: Your Game on DirectX12


Gruß,
Daniel

[NoFake3D]

Laut Intel soll man keine 32-Bit-DirectX 12-Anwendungen/Spiele erstellen und ausliefern:

Efficient Rendering with DirectX 12 on Intel Graphics - Seite 32:

Memory-related public service announcement:

– Don’t make/ship 32-bit (CPU) D3D12 applications!
– Even if it works today…
– Thank me later 

https://software.intel.com/sites/defaul ... aphics.pdf


Gruß,
Daniel

[Krishty]

Das ist aber ein wenig aus dem Kontext gerissen: Unter D3D 11 konnte ein 32-Bit-Prozess eine 1-GiB-Textur im VRAM anlegen und hat kein Bisschen mehr Adressraum verbraucht, weil sie ja nur via Handle erreichbar war. Weil D3D 12-Ressourcen jedoch im selben Adressraum sitzen wie dein Prozess, bedeutet das, dass sich deine 32-Bit-Anwendung die 4 GiB an verfügbaren Adressen mit den GPU-Ressourcen teilen muss. Damit dir dann nicht ganz fix der Adressraum ausgeht oder kaputtfragmentiert, sollst du lieber direkt einen 64-Bit-Adressraum nutzen.

[NoFake3D]

Das ist aber ein wenig aus dem Kontext gerissen: Unter D3D 11 konnte ein 32-Bit-Prozess eine 1-GiB-Textur im VRAM anlegen und hat kein Bisschen mehr Adressraum verbraucht, weil sie ja nur via Handle erreichbar war. Weil D3D 12-Ressourcen jedoch im selben Adressraum sitzen wie dein Prozess, bedeutet das, dass sich deine 32-Bit-Anwendung die 4 GiB an verfügbaren Adressen mit den GPU-Ressourcen teilen muss. Damit dir dann nicht ganz fix der Adressraum ausgeht oder kaputtfragmentiert, sollst du lieber direkt einen 64-Bit-Adressraum nutzen.

Danke für die Erklärung!
Die Intel-Empfehlung bedeutet für mich, dass ich nur 64-Bit-DirectX 12-Anwendungen/Spiele erstelle, sobald ich zu DirectX 12 wechsle.

[David_pb]

Weil D3D 12-Ressourcen jedoch im selben Adressraum sitzen wie dein Prozess, bedeutet das, dass sich deine 32-Bit-Anwendung die 4 GiB an verfügbaren Adressen mit den GPU-Ressourcen teilen muss.

Woher hast du diese Information denn? D3D12 kann kein unified memory gewährleisten, wo die Resourcen physikalisch liegen hängt von der Hardware ab, die ein System verwendet. Viele Konfigurationen verwenden nach wie vor dediziertes VRAM, dort landen dann auch Resourcen, je nach Resource-Typ natürlich. Dinge wie CPU Backingstore legt D3D12 auch nicht an (z.B. für dynamische Resourcen o.Ä.), das bleibt der Anwendung überlassen. Resourceheaps können im Hauptspeicher hinterlegt werden, da sind allerdings auch keine Resourcedaten hinterlegt, sondern lediglich alle Descriptoren die eine Anwendung zum Zugriff benötigt.

[Krishty]

Aus dem Paper, aus dem auch das Zitat oben ist, Folie 28:

GPU Virtual Addresses in WDDM 2.0

• Directly exposes per-process GPU virtual addresses
  • Can do pointer arithmetic, store in data structures, etc.
  • GPU virtual addresses allocated at resource allocation
  • Guaranteed to remain at the same address until release
  • Eliminates physical address patching overhead
• Haswell has a limited GPU virtual address space (~2GB)

[…]

Haswell GPU Virtual Address Limit

• Not quite the same as limited GPU physical memory
  • Limit on the amount of DRAM visible to the GPU at once
  • All GPU-visible memory counts (upload/read-back heaps, …)
  • Even non-resident memory counts
• […]
• GPU VA exhaustion will fail at resource allocation
  • Again, please handle this gracefully! :-)

Broadwell GPU Virtual Addresses

• Good news: no longer an issue on Broadwell
  • Large GPU virtual address space (same as CPU)
• Memory-related public service announcement:
  • Don’t make/ship 32-bit (CPU) D3D12 applications!

Also: Das wandert alles in den Adressraum des Prozesses. Bei Haswell hat man architekturbedingt höchstens 2 GiB des Adressraums für GPU-Kram zur Verfügung; bei Broadwell so viel, wie die CPU-Architektur erlaubt. Also bei 32-Bit-Anwendungen nicht viel mehr als vorher – darum soll man keine kompilieren.

P.S.: Das gilt natürlich nur für Intel-Grafikprozessoren! Bezieht sich nicht auf D3D 12 generell. Das hätte ich vielleicht besser hervorheben sollen … alles Intel-only.

[NoFake3D]

Vorläufiges, und noch unvollständiges, Direct3D 12-Programmier-Handbuch:

https://msdn.microsoft.com/en-us/librar ... s.85).aspx

Inklusive ebenfalls unvollständigem Mini-Direct3D 12-Tutorial:

https://msdn.microsoft.com/en-us/librar ... s.85).aspx

Gruß,
Daniel

[NoFake3D]

Anscheinend kann man jetzt mit Hilfe von Windows 10 Technical Preview Build 10041, Visual Studio Tools for Windows 10 Technical Preview, Windows SDK for Windows 10 und Visual Studio 2015 CTP 6 eingeschränkt anfangen mit Direct3D 12:

http://www.gamedev.net/topic/666986-dir ... ow-public/

A quick confirmation/update on my earlier post. You can indeed build and run applications that use the D3D12 header/lib installed with the Windows SDK for Windows 10, by using VS2015 CTP6, on Windows 10 Tech Preview March Update (build 10041).

The Windows SDK only installs the headers/libs, but not the debug runtime, so a really important addition worth getting is the "Visual Studio Tools for Windows 10 Technical Preview" from the same page I linked for the Windows SDK (it's the download above the SDK on that page). That will install the D3D12 debug layer (and warp driver etc.), which is incredibly useful considering the WIP nature of the documentation.

The docs are a bit patchy, as Alessio1989 was good to point out, but it seems the outdated parts of the docs aren't too bad to correct for, using the newer reference section of the docs or the installed header definitions, from the half hour I've spent so far. Enough to create a valid device, swapchain, and command queue/list, at least.

http://windows.microsoft.com/en-us/wind ... pdate-1503
http://dev.windows.com/en-us/featured/h ... view-tools

Aktuell zumindest für AMD-Grafikkarten:

WDDM 2.0 drivers should be available through Windows Update (at least for AMD GPus), however driver status is still a "work in progress": Some features may not work correctly or may not work at all as far I tested.

Gruß,
Daniel

[NoFake3D]

Microsoft Build 2015-Konferenz-Live-Daten-Strom (3 Tage Konferenz vom 29.04.2015 bis 01.05.2015):
http://channel9.msdn.com/?wt.mc_id=build_hp

Advanced DirectX12 Graphics and Performance (Speakers: Max McMullen - Date: April 30, 2015 from 2:00PM to 3:00PM):
http://channel9.msdn.com/Events/Build/2015/3-673