DirectX 12
blogs.msdn.com
blogs.msdn.com
http://semiaccurate.com/2014/03/18/microsoft-adopts-mantle-c...
- reduce raw CPU work by increasing precompilation of state and data to native formats
- reduce communication from the CPU to the GPU, by increasing the flexibility of API calls
- reduce CPU <-> GPU dependencies by moving some forms of logic and flow into the GPU
All of them conspire to increase parallelism as well since there are in general fewer points where synchronization is needed.
Playstation developers have a long tradition of doing these things since the first model; Xbox developers not so much, but still a lot more than on PCs. Since the general goal is to reduce API surface, remove abstractions and match the metal more closely, it's natural for APIs to converge.
It's something of a Direct3D tradition to design the API around one hardware vendor's state of the art. Direct3D 9 was pretty much based on what the ATI Radeon 9700 could do. At the time this was a serious inconvenience to NVIDIA who had taken a different tack with the Geforce FX (I think it was -- it's been a while).
Out of all such rumor sites (Fudzilla and BSN being two other large ones), SA is the only one worth taking seriously.
You've always been able to get a lot more out of consoles considering their specs; the 360 was marginally better than the state of the art of PC hardware, for a few months, but being able to code right to the metal (not as much as on an Amiga or Nintendo, but relative to the PC) gave an efficiency that made the games unmatched for years.
AMD's recently released Mantle is the first exception on the PC, and DirectX 12 is reportedly quite similar. Bing it on your Zune for further reading.
Console games often look mediocre despite the above because console hardware is far cheaper, and thus simply less powerful, than the hardware in high end gaming PCs, despite the fact that consoles benefit from economies of scale, and are priced at a loss to boot. It is not fair to compare the way a game looks on a $2000 PC to the way it looks on a $400 console.
(I can't answer for the technical details, though. It reeds like hieroglyphics to me.)
1. Developers had no experience with the hardware during the initial years of the consoles.
They had to switch from an out-of-order and forgiving x86 to an in-order and unforgiving PowerPC that had substantially less cache (32k/32k vs 64k/2mb/8mb) than its PC counterparts of the day. Just ask any PC-gone-console developer of that age about LHS[1], or the off-the-wall Cell Broadband Architecture[2].
2. Developers had to manage 512MiB between the GPU and CPU.
Everything has to fit into that including the operating system... and I found 1GiB uncomfortable for PCs in 2006!
+ It was split on PS3, and you had to DMA into 256k for SPUs. + EDRAM was slightly too small to fit 1280x720x32x4 render targets.
3. Developers had no guarantee of permanent storage.
So everything had to be streamed from disk... which is unsavoury for various reasons.
Contortionist programming springs to mind[3].
4. PCs get upgraded.
'Nuff said.
[1]: http://www.gamasutra.com/view/feature/132084/sponsored_featu...
[2]: https://www.youtube.com/watch?v=bR8CVLVmKQs&t=4m
[3]: http://doublebuffered.com/2010/03/17/gdc-2010-streaming-mass...
(I'm assuming Gen 7, i.e., the Xbox 360 and PS3.)
No, but console OSes and Drivers are (well, compared to PC drivers).
There's an enormous amount going on between your code and the metal on a PC, even when writing C++ w/ OpenGL or DirectX. Driver overhead for graphics is HUGE (which is what this is about).
PC hardware comparable to PS3/Xbox360 performs significantly worse under real world conditions due to the way the graphics stack is set up and programmed against. The new Direct3d 12 (as well as AMD's Mantle) are attempts to tackle this.
I doubt the significant part. And even if this was true 7 years ago, it's definitely not true now. Comparable hardware would mean something like a GTX 760 (both the PS4's APU and the 760 have around 1800 GFLO/s). That card can do everything current consoles can.
Mantle is for lower end cards anyways, mid tier hardware like the GTX 760 and what's inside current consoles won't see a change that dramatic.
Which, incidentally, is the reason why the initiative came from AMD (also the strong emphasis on multithreading, since AMD sells cheap 8 core CPUs). If you can all of a sudden game on a weak CPU, then Intel chips will look less attractive in comparison.
Where you're seeing small improvement with higher end cards is that they're pumping the resolution, AA etc, with the same number of draw calls. If you instead ramp the draw calls up - for example by putting a ton more objects in your scene - you'll be able to get much more out of high end cards.
Mantle isn't going to help at all in the move to 4k, but it really will allow for much more complex games on the PC, akin to when Total War was released.
I'd also not take the launch titles as a good indication of what the hardware of these consoles is capable of. They're usually rushed, ported from other platforms, etc. The hardware is capable of much more.
This is a good demo that goes into lots of detail:
The reason Xbox APIs haven't given direct access to the GPU is for the same reason you wouldn't do this on Windows. The API gives a safe way, preferably with low overhead, to access resources that might be already being used. With the original Xbox, this was done to keep programming for the Xbox more or less the same as programming in DirectX on a Windows machine. Having comparable APIs makes porting significantly easier. The Xbox 360 maintained this paradigm.
If you consider the PIP type of gaming that Xbox One supports there's no way a game can have direct access because it would be fighting the kernel. Instead you are actually coding against a virtual device so that the kernel can decide what instructions can actually be executed.
Most of the studios use engines nowadays, so Mantle impact on studios besides AMD blessed ones, remains to be seen.
I honestly think DirectX is a great API. And let's be honest, by the time this is release in "Holiday 2015", it'll be at least until mid 2016 before anything comes out that uses it. Combine that with the rule about every other MS OS being good, and we should have a fairly decent Windows 9 to run these games on.
All you need is a good GL wrapper. If writing your own is painful, just use someone else's. But it's important to be able to write your own, because if you can't, then that's what weakens you.
A secondary reason to avoid DX is because gaming on windows has a high chance of being dead within the next decade. If that seems laughable, think of how laughable it would've sounded for anyone to say that about CDs for music in 2001.
I was under the impression that DX11 (and DX10 before it) actually do a decent job of exposing basically everything that's widely supported, and in a manner that can be made to work tolerably efficiently across a range of different hardware. But I was told this by some guy from MS so maybe I shouldn't have expected him to say anything else.
Assuming it's the case, perhaps I'm just cheating by not thinking of the leftovers as useful - not because the behaviour is useless, I mean, just because if you're targeting PC, you just have to accept that the underlying hardware could be anything. OpenGL extensions could provide you with more, but support can be a bit hit or miss. Reminds me too much of MS-DOS.
But I could have been misinformed, or my supposition is simply outdated, and the article suggests that could well have been the case, in which case my conclusion would be partly bogus too.
can't you just as well say that By restricting your worldview to OpenGl's predefined notion of what it should be, you'll never know the true extent of what you can do as a graphics programmer ? I probably don't have enough experience with it, but to me it seemds in the end both DirectX11 and latest OpenGL pretty much have equal capabilities apart from some details? Not like DirectX7 for instance, which obviously is capable of less.
http://aras-p.info/blog/2014/03/28/cross-platform-shaders-in...
(I've never worked on a cross-platform project where HLSL vs GLSL seemed to be a big deal.)
I have seen exactly zero good OpenGL wrappers. The stateful API makes it pretty much impossible to wrap in a way that would actually make it better.
I have also wasted a lot of time trying to implement some kind of a GL wrapper. I got something done that was fairly comfortable to use for my own needs but nowhere close to being an universal wrapper of any kind.
Have you got a decent GL wrapper to recommend?
As an OpenGL developer, not a day goes past without me wishing that the API was sensible like the DirectX API and not the state machine mess that it currently is.
I'm pretty sure any OpenGL programmer worth their salt will agree. Only some beginners with no practical experience think that OpenGL is a better API because it requires less boilerplate code to draw a triangle.
Only as long as nVidia and ATI keep releasing drivers for you. At some point XP will be abandoned.
Windows comes with an OpenGL implementation but it's an ancient version.
They are the running joke from graphics programmers.
I wouldn't worry about this.
MS's desire to ship their latest OS has hurt developers over the years. I hope people still chose Open GL over DX-whatever.
Older versions of FF are yes, but the latest is not supportedhttps://support.mozilla.org/en-US/kb/firefox-no-longer-works...
There's no reason they should be expected to put dev resources into an OS that's 12 years old.
Depending on the the prevalence of XP usage among their users, there might be one, actually.
Which means IE11 may be great, but we're stuck with it forever just like we're stuck with IE8, etc.
And if you code for DX12, you will be abandoning like >50% of your audience, so nobody will code for it. Just like DX11 is only now gaining real steam.
What do you mean? All new versions of all commercial software have new improvements/features. If they just released all of them for free on the previous version, they might as well just shut down their company.
> Not compatible with Windows XP, yet Chrome and Firefox is still.
Well IE since version 7 uses mandatory integrity control which is a kernel feature of Vista and above. XP only has DACLs. I believe what they did initially was just disable the protected mode feature when IE ran on XP.
Firefox is woefully behind other browsers in this particular aspect so it doesn't need to worry about it. Chrome does the same thing as IE on Vista+. They wrote their own sandbox because its a cross platform product which is why it works on XP.
So certainly, Chrome would be your choice if you want a single browser that runs on XP as well as Vista. That would matter only to businesses or computer labs or places where there is a large deployment of software across multiple OS versions. For home users, it doesn't matter. People just use whatever version of windows came with the PC.
We've seen studios release DX11/Vista+ games with fallbacks to work on DX10/XP.
And (almost) nobody's targeting just Microsoft devices, even developers who are paid for temporary exclusives. It's all about the cross-platform engines.
Mantle has the same CPU savings, and during discussions on that game developers have talked about how in many (most?) games, up to 50% of your CPU time is spent in the drivers. Considering how many games I've run into lately where single-core performance is the bottleneck, this doesn't surprise me at all.
Mantle and DX12 strip out a lot of layers, optimize a lot of what it keeps, and spread a good chunk of the remaining load over multiple threads, meaning that instead of trying to use 120% of core 0 and 15% of cores 1-3, you can use 60% of core 0 and 25% of cores 1-3 (just as a hypothetical made-up example).
This is why games like Left-4-Dead2 using OpenGL run substantially faster (More FPS) (http://www.extremetech.com/gaming/133824-valve-opengl-is-fas...)
It may be that the current example of open-source are faster than the current example of closed-source, and there may be very real advantages that the open-source approach brings about that pushes the status quo towards as you describe, but there's nothing mandating that. I'm not sure why you'd therefore assert that.
The assertion I was intending to make was that widely used open source applications tend to be analyzed and improved by a larger community and thus are more likely to be more steamlined/efficient ("faster" was also not a correct term here to describe efficient pipelines)
Although as someone stated further down, OpenGL is not actually open source, it's an open standard. So my original point is null and void as is.
I believe my hate for Microsoft had blinded me, forgive me.
Why are you comparing implementations and standards on a metric that's only application to implementations?