9 ms·

DirectX 11 vs. DirectX 12 oversimplified

112 points by snake_case 12y ago

quonn 12y ago
> Cloud computing is, ironically, going to be the biggest beneficiary of DirectX 12. That sounds unintuitive but the fact is, there’s nothing stopping a DirectX 12 enabled machine from fully running VMs on these video cards. Ask your IT manager which they’d rather do? Pop in a new video card or replace the whole box. Can someone please comment on that? Everything I know about GPUs suggests that even if it would be possible to run VMs on them, performance would be terrible. All those tiny GPU cores are not designed to do much branch prediction, all the fancy out-of-order execution, pre-fetching etc. and your average software will totally depend on that.
- muizelaar 12y ago
  I believe the author is referring to accessing the GPUs from VMs. i.e. if you have 16 core machine with a 1024 core GPU you can split it up so it looks like 4 machines with 4 cores and 256 core GPU. The sentence that you snipped seems to refer to this. "Right now, this isn’t doable because cloud services don’t even have video cards in them typically (I’m looking at you Azure. I can’t use you for offloading Metamaps!)"
  - wtallis 12y ago
    It's already possible to partition GPUs to share them across multiple VMs. Intel's got modified versions of Xen and KVM to support this for Haswell and later IGPs, and AMD and NVidia both have proprietary solutions. Furthermore, this has nothing to do with rendering APIs; it's all in the driver and hypervisor.
    - muizelaar 12y ago
      I have no doubt. I was just trying to clarify what the original author may have been intending to say.
      - lmeyerov 12y ago
        Yes, running the VM would be silly, but machine learning etc. is awesome. We get acces and time sharing across resources much easier (at all) now. At Graphistry, we are using AWS G2 instances for previously impossibly big interactive data visualizations and streaming into stock browsers. It's pretty ridiculously cool :) Always happy to chat about GPU clouds and related fun things.
  - EpicEng 12y ago
    Perhaps, but that's not what the author said: "there’s nothing stopping a DirectX 12 enabled machine from fully running VMs on these video cards."
- duckingtest 12y ago
  Modern GPUs have 32-64 independent cores, each can run different code path. Then each core runs the same code path on several different inputs in parallel. It's probably not possible with current tools, but architecture-wise completely dividing the cores between VMs should be doable.
  - quonn 12y ago
    I know they have different cores, but, as I pointed out, these cores are very slow for most code that would normally run on a CPU. That is precisely the reason why so many cores fit - a CPU uses the available space to get around the memory wall. muizelaar's comment pointed out that the author probably wanted to say that the GPU can't be reasonably accessed _from_ VMs, yet. That makes much more sense.
  - vardump 12y ago
    The GPU on the card (Geforce GTX 970) mentioned in the article has 13 independent SMM cores. Each of them has 128 marketing "cores", for a total of 1664.
- kllrnohj 12y ago
  If you managed to run a VM on a GPU it would perform like ass. GPUs are incredibly slow at doing the sort of work that a CPU does. If they were fast at doing general purpose work, then CPUs would be doing the same things. GPUs are extremely fickle with memory access patterns, branches, etc... It takes a lot of care to get them to run fast on a given workload, and that workload better be identically parallel (as in, every "thread" takes the same branches, with memory access in a uniform offset+thread-id order, etc..).
bronz 12y ago
Do you need to pay royalties to Microsoft in order to use DX12/DX11 in a commercial game?
- tedajax 12y ago
  No
- bhouston 12y ago
  Soft of, it only runs on Windows.
snake_case 12y ago
With the performance gains of Mantle and DirectX 12, where does OpenGL exactly fall within all of this?
- muizelaar 12y ago
  A next generation API comparable to Mantle and D3D12 is being developed inside the Khronos Group: https://www.khronos.org/news/press/khronos-group-announces-key-advances-in-opengl-ecosystem https://www.khronos.org/news/press/khronos-group-announces-k...
  - pjmlp 12y ago
    Everyone is hoping that it doesn't turn out into another Longs Peak.
- Havoc 12y ago
  One step behind as usual sadly. Not far behind...but behind. And in a two horse race that's a difficult pitch...
gambiting 12y ago
It really is oversimplified. "Creating dozens of light sources simultaneously on screen at once is basically not doable unless you have Mantle or DirectX 12. Guess how many light sources most engines support right now? 20? 10? Try 4. Four. Which is fine for a relatively static scene. " For my Masters degree project at uni I had a demo written in OpenGL with over 500 dynamic lights, running at 60fps on a GTX580. Without Mantle, or DX12. How? Deffered rendering, that's how. You could probably add a couple thousand and it would be fine too. "Every time I hear someone say “but X allows you to get close to the hardware” I want to shake them. None of this has to do with getting close to the hardware. It’s all about the cores" Also not true. I work with console devkits every single day and the reason why we can squeeze so much performance out of relatively low-end hardware is that we get to make calls which you can't make on PC. A DirectX call to switch a texture takes a few thousand clock cycles. A low-level hardware call available on Playstation Platform will do the same texture switch in few dozen instruction calls. The numbers are against DirectX, and that's why Microsoft is slowly letting devs access the GPU on the Xbox One without the DirectX overhead.
- pfisch 12y ago
  I think he meant that most shaders only receive four light sources. However I am not a low level graphics guy but my understanding is that deferred or not most shaders will only receive four light sources.
  - gambiting 12y ago
    a "light source" is nothing else than a collection of variables when passed in to the shader. Vector3 for the position, a float for the intensity, Vector3 for the colour and so on. Each one of them can be passed in as a uniform - with OpenGL 3.0 you should be able to pass in at the very least 1024 uniforms, but in most implementations the limit is much higher. So if you were only passing in the position of the light, you should be able to give at least 1024 lights to any shader.
  - mattnewport 12y ago
    This hasn't been true for a long time and DX12 doesn't really change anything here. DX11 was already able to handle very large numbers of constants. The limit on how many lights you support in a shader is largely a factor of controlling the shader cost rather than one of constant space limits these days. Deferred renderers are very popular these days as well and don't really handle lights in the same way anyway. DX12 does offer some potential CPU side performance benefits when it comes to updating large numbers of constants efficiently which may well help performance when dealing with lots of dynamic lights but it's not adding any new capabilities beyond what DX11 offers.
jra101 12y ago
"Last Fall, Nvidia released the Geforce GTX 970. It has 5.2 BILLION transistors on it. It already supports DirectX 12. Right now. It has thousands of cores in it. And with DirectX 11, I can talk to exactly 1 of them at a time." That's not how it works, the app developer has no control over individual GPU cores (even in DX12). At the API level you can say "draw this triangle" and the GPU itself splits the work across multiple GPU cores.
- kllrnohj 12y ago
  Moreover the actual GPU doesn't work like that either. GPUs do not have the capability to run more than one work-unit-thing at a time. They have thousands of cores, yes, but much more in a SIMD-style fashion than in a bunch of parallel threads. They cannot split those cores up into logical chunks that can then individually do independent things. The whole post isn't just oversimplified, it's just wrong. Across the board wrong wrong wrong. The point of Mantle, of Metal, and of DX12 is to expose more of the low level guts. The key thing is that those low level guts aren't that low level. The threading improvements come because you can build the GPU objects on different threads, not because you can talk to a bunch of GPU cores from different threads. The majority of CPU time these days in OpenGL/DirectX is in validating and building state objects. DX12 and others now lets you take lifecycle control of those objects. Re-use them across frames, build them on multiple threads, etc... Then talking to the GPU is a simple matter of handing over an already-validated, immutable object to the GPU. Which is fast. Very fast.
  - mattnewport 12y ago
    Yeah, I'd have to agree it's hard to describe this post in more generous terms than just flat out wrong. DX12 is making it more efficient to spread CPU side rendering work across multiple cores but it's not about letting individual CPU cores talk to individual GPU cores. That isn't even really a coherent concept. The whole digression on lighting is mostly just wrong too. Deferred renderers have been rendering with 100s of dynamic lights for years. DX12 may make it a bit more efficient to deal with the large amount of constant data that needs to be updated when dealing with 100s of dynamic lights but it isn't introudcing any fundamental changes to dynamic lighting.
patrickfl 12y ago
Not a hardware guy so don't know a ton about this, the oversimplification was a bit necessary for me. With that, I'm very excited for DX12, is it available for download on Windows7-64 yet?
- selter01 12y ago
  No, and it won't be.
- jsheard 12y ago
  There's a private preview for big name developers (Unity already has DX12 implemented) but it's not going to be public until Windows 10 launches. Also, it's going to be exclusive to Windows 10. Not the end of the world since 7 and 8 owners get a free upgrade.
- pas 12y ago
  It's about redesigning the current idiotic graphics pipeline API, so the driver and the application doesn't have to use the inefficient abstractions, that are already outdated on both ends. (The GPU is much more complex and sophisticated than what it used to be. It's not just a fancy framebuffer with a few megabytes of RAM so you can do z-culling and a 3D to 2D projection. And nowadays with virtual texturing and megatextures, with the bottleneck being the latency of pushing these abstract objects to the GPU, which are getting replaced by in-driver compiled shader programs anyway, the whole thing is ripe for a bit of fundamental change.) Take some time to watch these. I'm also not a hardware guy, but these problems are far-far from the hardware, and the solutions are very educational from a distributed systems standpoint. http://gdcvault.com/play/1020791/ http://gdcvault.com/play/1020791/ http://www.slideshare.net/tlorach/opengl-nvidia-commandlistapproaching-zerodriveroverhead http://www.slideshare.net/tlorach/opengl-nvidia-commandlista...
nawitus 12y ago
How relevant is DirectX11/12 these days now that OpenGL is so successful thanks to mobile and web?
- pjmlp 12y ago
  No games console has first class support for OpenGL. EDIT: Rephrased it better.
  - xfalcox 12y ago
    You know that thw biggest esport game (as in prize money) runs fine with openGL on Linux? With valve developing source2, having ported almost all source games, and other AAA titles like Borderlands with first class Linux support, openGL it's very alive in gaming.
    - pjmlp 12y ago
      The keyword was consoles.
- tehaugmenter 12y ago
  I too would like to know the relevance. From a wiki article [1] In general, Direct3D is designed to virtualize 3D hardware interfaces. Direct3D frees the game programmer from accommodating the graphics hardware. OpenGL, on the other hand, is designed to be a 3D hardware-accelerated rendering system that may be emulated in software. These two APIs are fundamentally designed under two separate modes of thought. [1] http://en.wikipedia.org/wiki/Comparison_of_OpenGL_and_Direct3D#Comparison http://en.wikipedia.org/wiki/Comparison_of_OpenGL_and_Direct...
  - jsheard 12y ago
    You can run Direct3D in software, Microsoft even provides a software implementation of DX11 (albeit the subset that works on DX10.1 hardware). https://msdn.microsoft.com/en-us/library/windows/desktop/gg615082(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/gg6...
jokoon 12y ago
and here I am, barely managing to find a decent, simple 3D C++ rendering library to run on a mac with XCode. Edit: 3D It's pretty crazy how weird it is that there's no dead simple 3D rendering library that supports just bare polygons. When I look at an opengl tutorial I just flee when I see how much boiler plate code is necessary to make the mouse move a camera.
- jstanek 12y ago
  Check out SDL, Allegro, or SFML. http://libsdl.org/ http://libsdl.org/ http://alleg.sourceforge.net/ http://alleg.sourceforge.net/ http://sfml-dev.org/ http://sfml-dev.org/
  - jokoon 12y ago
    I meant 3D
    - gambiting 12y ago
      SDL supports OpenGL. So you can have SDL handle all the boring stuff with window handles, keyboard and mouse movement, system events etc, and you are given an empty OpenGL context so you can draw literally anything you want in it. It doesn't get much simpler than that.
      - jokoon 12y ago
        nah, still need to use opengl when using SDL, to make a projection matrix, VBO, all those fun things.
        gambiting 12y ago
        "a decent, simple 3D C++ rendering library " - 3D rendering doesn't really get any more simple than a blank OpenGL context window. If you want "simple" as in "easy to use" then Unity/Unreal Engine are both very easy to use.
louhike 12y ago
Everybody seems to be really critical about the article. But he does say that it is an "extreme oversimplification". And he is a video game developer. Maybe he is mostly working as the CEO at Stardocks now (maybe not) but I have difficulties to think that it is just "wrong". I felt the criticisms were unfairs. But I'm a web developper so maybe I just miss it completely.
- bhouston 12y ago
  I am a 3d dev and this article makes my head hurt. It has a bit of right and a lot of wrong.
- wtallis 12y ago
  An extreme oversimplification can be expected to get the technical details wrong but the conclusion right. This article gets the high-level consequences wrong too, and claims that there will be benefits to things that are completely unrelated.
agapos 12y ago
"There is no doubt in my mind that support for Mantle/DirectX12/xxxx will be rapid because the benefits are both obvious and easy to explain, even to non-technical people." Except that this won't only depend on the programmers, but on the management too, and seeing what those guys do at EA, UbiSoft, Activison, etc, I am not sure it will be properly utilized for the first wave of Dx12 games.
- SG- 12y ago
  EA's "big" engine which is now Frostbite from Dice already has Mantle support, it will likely be able to implement the DX12 side of it pretty quickly.
deleted 12y ago
[deleted]
netsurfer912 12y ago
nice oh wait it only runs on "windows"

112 points by snake_case 12y ago

quonn 12y ago

> Cloud computing is, ironically, going to be the biggest beneficiary of DirectX 12. That sounds unintuitive but the fact is, there’s nothing stopping a DirectX 12 enabled machine from fully running VMs on these video cards. Ask your IT manager which they’d rather do? Pop in a new video card or replace the whole box. Can someone please comment on that? Everything I know about GPUs suggests that even if it would be possible to run VMs on them, performance would be terrible. All those tiny GPU cores are not designed to do much branch prediction, all the fancy out-of-order execution, pre-fetching etc. and your average software will totally depend on that.

muizelaar 12y ago
I believe the author is referring to accessing the GPUs from VMs. i.e. if you have 16 core machine with a 1024 core GPU you can split it up so it looks like 4 machines with 4 cores and 256 core GPU. The sentence that you snipped seems to refer to this. "Right now, this isn’t doable because cloud services don’t even have video cards in them typically (I’m looking at you Azure. I can’t use you for offloading Metamaps!)"
- wtallis 12y ago
  It's already possible to partition GPUs to share them across multiple VMs. Intel's got modified versions of Xen and KVM to support this for Haswell and later IGPs, and AMD and NVidia both have proprietary solutions. Furthermore, this has nothing to do with rendering APIs; it's all in the driver and hypervisor.
  - muizelaar 12y ago
    I have no doubt. I was just trying to clarify what the original author may have been intending to say.
    - lmeyerov 12y ago
      Yes, running the VM would be silly, but machine learning etc. is awesome. We get acces and time sharing across resources much easier (at all) now. At Graphistry, we are using AWS G2 instances for previously impossibly big interactive data visualizations and streaming into stock browsers. It's pretty ridiculously cool :) Always happy to chat about GPU clouds and related fun things.
- EpicEng 12y ago
  Perhaps, but that's not what the author said: "there’s nothing stopping a DirectX 12 enabled machine from fully running VMs on these video cards."
duckingtest 12y ago
Modern GPUs have 32-64 independent cores, each can run different code path. Then each core runs the same code path on several different inputs in parallel. It's probably not possible with current tools, but architecture-wise completely dividing the cores between VMs should be doable.
- quonn 12y ago
  I know they have different cores, but, as I pointed out, these cores are very slow for most code that would normally run on a CPU. That is precisely the reason why so many cores fit - a CPU uses the available space to get around the memory wall. muizelaar's comment pointed out that the author probably wanted to say that the GPU can't be reasonably accessed _from_ VMs, yet. That makes much more sense.
- vardump 12y ago
  The GPU on the card (Geforce GTX 970) mentioned in the article has 13 independent SMM cores. Each of them has 128 marketing "cores", for a total of 1664.
kllrnohj 12y ago
If you managed to run a VM on a GPU it would perform like ass. GPUs are incredibly slow at doing the sort of work that a CPU does. If they were fast at doing general purpose work, then CPUs would be doing the same things. GPUs are extremely fickle with memory access patterns, branches, etc... It takes a lot of care to get them to run fast on a given workload, and that workload better be identically parallel (as in, every "thread" takes the same branches, with memory access in a uniform offset+thread-id order, etc..).

bronz 12y ago

Do you need to pay royalties to Microsoft in order to use DX12/DX11 in a commercial game?

tedajax 12y ago
No
bhouston 12y ago
Soft of, it only runs on Windows.

snake_case 12y ago

With the performance gains of Mantle and DirectX 12, where does OpenGL exactly fall within all of this?

muizelaar 12y ago
A next generation API comparable to Mantle and D3D12 is being developed inside the Khronos Group: https://www.khronos.org/news/press/khronos-group-announces-key-advances-in-opengl-ecosystem https://www.khronos.org/news/press/khronos-group-announces-k...
- pjmlp 12y ago
  Everyone is hoping that it doesn't turn out into another Longs Peak.
Havoc 12y ago
One step behind as usual sadly. Not far behind...but behind. And in a two horse race that's a difficult pitch...

gambiting 12y ago

It really is oversimplified. "Creating dozens of light sources simultaneously on screen at once is basically not doable unless you have Mantle or DirectX 12. Guess how many light sources most engines support right now? 20? 10? Try 4. Four. Which is fine for a relatively static scene. " For my Masters degree project at uni I had a demo written in OpenGL with over 500 dynamic lights, running at 60fps on a GTX580. Without Mantle, or DX12. How? Deffered rendering, that's how. You could probably add a couple thousand and it would be fine too. "Every time I hear someone say “but X allows you to get close to the hardware” I want to shake them. None of this has to do with getting close to the hardware. It’s all about the cores" Also not true. I work with console devkits every single day and the reason why we can squeeze so much performance out of relatively low-end hardware is that we get to make calls which you can't make on PC. A DirectX call to switch a texture takes a few thousand clock cycles. A low-level hardware call available on Playstation Platform will do the same texture switch in few dozen instruction calls. The numbers are against DirectX, and that's why Microsoft is slowly letting devs access the GPU on the Xbox One without the DirectX overhead.

pfisch 12y ago
I think he meant that most shaders only receive four light sources. However I am not a low level graphics guy but my understanding is that deferred or not most shaders will only receive four light sources.
- gambiting 12y ago
  a "light source" is nothing else than a collection of variables when passed in to the shader. Vector3 for the position, a float for the intensity, Vector3 for the colour and so on. Each one of them can be passed in as a uniform - with OpenGL 3.0 you should be able to pass in at the very least 1024 uniforms, but in most implementations the limit is much higher. So if you were only passing in the position of the light, you should be able to give at least 1024 lights to any shader.
- mattnewport 12y ago
  This hasn't been true for a long time and DX12 doesn't really change anything here. DX11 was already able to handle very large numbers of constants. The limit on how many lights you support in a shader is largely a factor of controlling the shader cost rather than one of constant space limits these days. Deferred renderers are very popular these days as well and don't really handle lights in the same way anyway. DX12 does offer some potential CPU side performance benefits when it comes to updating large numbers of constants efficiently which may well help performance when dealing with lots of dynamic lights but it's not adding any new capabilities beyond what DX11 offers.

jra101 12y ago

"Last Fall, Nvidia released the Geforce GTX 970. It has 5.2 BILLION transistors on it. It already supports DirectX 12. Right now. It has thousands of cores in it. And with DirectX 11, I can talk to exactly 1 of them at a time." That's not how it works, the app developer has no control over individual GPU cores (even in DX12). At the API level you can say "draw this triangle" and the GPU itself splits the work across multiple GPU cores.

kllrnohj 12y ago
Moreover the actual GPU doesn't work like that either. GPUs do not have the capability to run more than one work-unit-thing at a time. They have thousands of cores, yes, but much more in a SIMD-style fashion than in a bunch of parallel threads. They cannot split those cores up into logical chunks that can then individually do independent things. The whole post isn't just oversimplified, it's just wrong. Across the board wrong wrong wrong. The point of Mantle, of Metal, and of DX12 is to expose more of the low level guts. The key thing is that those low level guts aren't that low level. The threading improvements come because you can build the GPU objects on different threads, not because you can talk to a bunch of GPU cores from different threads. The majority of CPU time these days in OpenGL/DirectX is in validating and building state objects. DX12 and others now lets you take lifecycle control of those objects. Re-use them across frames, build them on multiple threads, etc... Then talking to the GPU is a simple matter of handing over an already-validated, immutable object to the GPU. Which is fast. Very fast.
- mattnewport 12y ago
  Yeah, I'd have to agree it's hard to describe this post in more generous terms than just flat out wrong. DX12 is making it more efficient to spread CPU side rendering work across multiple cores but it's not about letting individual CPU cores talk to individual GPU cores. That isn't even really a coherent concept. The whole digression on lighting is mostly just wrong too. Deferred renderers have been rendering with 100s of dynamic lights for years. DX12 may make it a bit more efficient to deal with the large amount of constant data that needs to be updated when dealing with 100s of dynamic lights but it isn't introudcing any fundamental changes to dynamic lighting.

patrickfl 12y ago

Not a hardware guy so don't know a ton about this, the oversimplification was a bit necessary for me. With that, I'm very excited for DX12, is it available for download on Windows7-64 yet?

selter01 12y ago
No, and it won't be.
jsheard 12y ago
There's a private preview for big name developers (Unity already has DX12 implemented) but it's not going to be public until Windows 10 launches. Also, it's going to be exclusive to Windows 10. Not the end of the world since 7 and 8 owners get a free upgrade.
pas 12y ago
It's about redesigning the current idiotic graphics pipeline API, so the driver and the application doesn't have to use the inefficient abstractions, that are already outdated on both ends. (The GPU is much more complex and sophisticated than what it used to be. It's not just a fancy framebuffer with a few megabytes of RAM so you can do z-culling and a 3D to 2D projection. And nowadays with virtual texturing and megatextures, with the bottleneck being the latency of pushing these abstract objects to the GPU, which are getting replaced by in-driver compiled shader programs anyway, the whole thing is ripe for a bit of fundamental change.) Take some time to watch these. I'm also not a hardware guy, but these problems are far-far from the hardware, and the solutions are very educational from a distributed systems standpoint. http://gdcvault.com/play/1020791/ http://gdcvault.com/play/1020791/ http://www.slideshare.net/tlorach/opengl-nvidia-commandlistapproaching-zerodriveroverhead http://www.slideshare.net/tlorach/opengl-nvidia-commandlista...

nawitus 12y ago

How relevant is DirectX11/12 these days now that OpenGL is so successful thanks to mobile and web?

pjmlp 12y ago
No games console has first class support for OpenGL. EDIT: Rephrased it better.
- xfalcox 12y ago
  You know that thw biggest esport game (as in prize money) runs fine with openGL on Linux? With valve developing source2, having ported almost all source games, and other AAA titles like Borderlands with first class Linux support, openGL it's very alive in gaming.
  - pjmlp 12y ago
    The keyword was consoles.
tehaugmenter 12y ago
I too would like to know the relevance. From a wiki article [1] In general, Direct3D is designed to virtualize 3D hardware interfaces. Direct3D frees the game programmer from accommodating the graphics hardware. OpenGL, on the other hand, is designed to be a 3D hardware-accelerated rendering system that may be emulated in software. These two APIs are fundamentally designed under two separate modes of thought. [1] http://en.wikipedia.org/wiki/Comparison_of_OpenGL_and_Direct3D#Comparison http://en.wikipedia.org/wiki/Comparison_of_OpenGL_and_Direct...
- jsheard 12y ago
  You can run Direct3D in software, Microsoft even provides a software implementation of DX11 (albeit the subset that works on DX10.1 hardware). https://msdn.microsoft.com/en-us/library/windows/desktop/gg615082(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/gg6...

jokoon 12y ago

and here I am, barely managing to find a decent, simple 3D C++ rendering library to run on a mac with XCode. Edit: 3D It's pretty crazy how weird it is that there's no dead simple 3D rendering library that supports just bare polygons. When I look at an opengl tutorial I just flee when I see how much boiler plate code is necessary to make the mouse move a camera.

jstanek 12y ago
Check out SDL, Allegro, or SFML. http://libsdl.org/ http://libsdl.org/ http://alleg.sourceforge.net/ http://alleg.sourceforge.net/ http://sfml-dev.org/ http://sfml-dev.org/
- jokoon 12y ago
  I meant 3D
  - gambiting 12y ago
    SDL supports OpenGL. So you can have SDL handle all the boring stuff with window handles, keyboard and mouse movement, system events etc, and you are given an empty OpenGL context so you can draw literally anything you want in it. It doesn't get much simpler than that.
    - jokoon 12y ago
      nah, still need to use opengl when using SDL, to make a projection matrix, VBO, all those fun things.
      - gambiting 12y ago
        "a decent, simple 3D C++ rendering library " - 3D rendering doesn't really get any more simple than a blank OpenGL context window. If you want "simple" as in "easy to use" then Unity/Unreal Engine are both very easy to use.

louhike 12y ago

Everybody seems to be really critical about the article. But he does say that it is an "extreme oversimplification". And he is a video game developer. Maybe he is mostly working as the CEO at Stardocks now (maybe not) but I have difficulties to think that it is just "wrong". I felt the criticisms were unfairs. But I'm a web developper so maybe I just miss it completely.

bhouston 12y ago
I am a 3d dev and this article makes my head hurt. It has a bit of right and a lot of wrong.
wtallis 12y ago
An extreme oversimplification can be expected to get the technical details wrong but the conclusion right. This article gets the high-level consequences wrong too, and claims that there will be benefits to things that are completely unrelated.

agapos 12y ago

"There is no doubt in my mind that support for Mantle/DirectX12/xxxx will be rapid because the benefits are both obvious and easy to explain, even to non-technical people." Except that this won't only depend on the programmers, but on the management too, and seeing what those guys do at EA, UbiSoft, Activison, etc, I am not sure it will be properly utilized for the first wave of Dx12 games.

SG- 12y ago
EA's "big" engine which is now Frostbite from Dice already has Mantle support, it will likely be able to implement the DX12 side of it pretty quickly.

deleted 12y ago

[deleted]

netsurfer912 12y ago

nice oh wait it only runs on "windows"