"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.
> 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.
Indeed. For fixed function forward rendering you do have those limitations, though. However it's nowhere as low as 4: you can expect at least 8 and most often 16 lights. The catch is that DirectX 12 will do nothing for that limitation.
At the end of the day all that this comes down to is decreasing the cost of one thing:
Draw()
Which has immense amounts of CPU overhead due to abstractions. Anything else DX12 might do is really just a bonus.
This type of direct access is fine on a console, but DirectX is primarily designed as an abstraction layer on top of arbitrary hardware. PC hardware isn't as predictable as the Xbox One, and yeah, it adds clock cycles. On PC you don't want to get that deep into the hardware: it has the potential to break compatibility, and because dev teams generally don't have the ability to test 5,000 different combinations of CPUs, GPUs and drivers, you try to keep as much compatibility as you can.
Even without deferred rendering, why the limitation? I am sure there is a limit in the standart pipeline but can't I just pass as much as light info to shaders now, the result is just slightly longer shaders
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.
Is this a direct effect of the design of PC hardware, or could we theoretically build a PC OS that would let you do a texture switch as efficiently as on PS/XBOX/etc?
>For my Masters degree project at uni I had a demo written in OpenGL with over 500 dynamic lights,
I don’t know what kind of 3D engine you wrote, but as a FPS gamer I have quite a bit of experience with 3D engines. From Doom 3 to Alan Wake, some of the worst performance hits occur in scenes with heavy use of dynamic lights. Did OpenGL 4/DX11 fix this?
Which of the modern APIs have you actually used? How do Mantle, DX12, Metal, and OpenGl Next compare?
EDIT: "as a non-3D graphics programmer, who's tried to build FPS levels for fun and familiar with all the modern engines". This article is for those of us with interest but not experts in the field, right?
"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.
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.
> 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.
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..).
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!)"
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.
But OpenGL is also targeting and benefiting from these advances. Also, since the article is mindboggingly dumb, watch this: http://gdcvault.com/play/1020791/ (It might be that the DX12 announcement the author read was the source of misinformation, but anyway, this submission should have been flagged hours ago.)
OpenglES 2 (which is what mobile runs) and WebGL are DirectX 9 equivalent. And on windows at least chrome implements WebGL on top of Directx and not OpenGl substrate https://code.google.com/p/angleproject/
With feature parity latest DirectX can be compared only to desktop OpenGL (although OpenGL ES 3.0 is up and coming)
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.
"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.
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.
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?
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.
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.
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.
[+] [-] gambiting|11 years ago|reply
"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.
[+] [-] zamalek|11 years ago|reply
> 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.
Indeed. For fixed function forward rendering you do have those limitations, though. However it's nowhere as low as 4: you can expect at least 8 and most often 16 lights. The catch is that DirectX 12 will do nothing for that limitation.
At the end of the day all that this comes down to is decreasing the cost of one thing:
Which has immense amounts of CPU overhead due to abstractions. Anything else DX12 might do is really just a bonus.[+] [-] exelius|11 years ago|reply
[+] [-] sippeangelo|11 years ago|reply
[+] [-] shultays|11 years ago|reply
[+] [-] pfisch|11 years ago|reply
[+] [-] fnordsensei|11 years ago|reply
[+] [-] lbenes|11 years ago|reply
I don’t know what kind of 3D engine you wrote, but as a FPS gamer I have quite a bit of experience with 3D engines. From Doom 3 to Alan Wake, some of the worst performance hits occur in scenes with heavy use of dynamic lights. Did OpenGL 4/DX11 fix this?
Which of the modern APIs have you actually used? How do Mantle, DX12, Metal, and OpenGl Next compare?
EDIT: "as a non-3D graphics programmer, who's tried to build FPS levels for fun and familiar with all the modern engines". This article is for those of us with interest but not experts in the field, right?
[+] [-] jra101|11 years ago|reply
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|11 years ago|reply
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.
[+] [-] quonn|11 years ago|reply
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.
[+] [-] kllrnohj|11 years ago|reply
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..).
[+] [-] muizelaar|11 years ago|reply
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!)"
[+] [-] duckingtest|11 years ago|reply
[+] [-] nawitus|11 years ago|reply
[+] [-] pas|11 years ago|reply
But OpenGL is also targeting and benefiting from these advances. Also, since the article is mindboggingly dumb, watch this: http://gdcvault.com/play/1020791/ (It might be that the DX12 announcement the author read was the source of misinformation, but anyway, this submission should have been flagged hours ago.)
[+] [-] Havoc|11 years ago|reply
Ogl is busy winning some ground but on the level the article is talking about... Slow gains.
[+] [-] pjmlp|11 years ago|reply
EDIT: Rephrased it better.
[+] [-] kyberias|11 years ago|reply
[+] [-] fsloth|11 years ago|reply
With feature parity latest DirectX can be compared only to desktop OpenGL (although OpenGL ES 3.0 is up and coming)
[+] [-] tehaugmenter|11 years ago|reply
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_Direct...
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] EpicEng|11 years ago|reply
[+] [-] agapos|11 years ago|reply
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-|11 years ago|reply
[+] [-] jokoon|11 years ago|reply
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|11 years ago|reply
[+] [-] jawngee|11 years ago|reply
https://developer.apple.com/library/mac/documentation/3DDraw...
[+] [-] Impossible|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] patrickfl|11 years ago|reply
[+] [-] pas|11 years ago|reply
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://www.slideshare.net/tlorach/opengl-nvidia-commandlista...
[+] [-] jsheard|11 years ago|reply
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.
[+] [-] selter01|11 years ago|reply
[+] [-] snake_case|11 years ago|reply
[+] [-] Havoc|11 years ago|reply
[+] [-] muizelaar|11 years ago|reply
[+] [-] bronz|11 years ago|reply
[+] [-] bhouston|11 years ago|reply
[+] [-] tedajax|11 years ago|reply
[+] [-] netsurfer912|11 years ago|reply
oh wait it only runs on "windows"
[+] [-] louhike|11 years ago|reply
[+] [-] wtallis|11 years ago|reply
[+] [-] bhouston|11 years ago|reply