View Single Post
Old Jun 19, 2013, 03:14 PM   #10
Join Date: Sep 2003
Posts: 1,877
bobvodka once won a refrigerator on 'The Price is Right'bobvodka once won a refrigerator on 'The Price is Right'bobvodka once won a refrigerator on 'The Price is Right'bobvodka once won a refrigerator on 'The Price is Right'bobvodka once won a refrigerator on 'The Price is Right'bobvodka once won a refrigerator on 'The Price is Right'


Originally Posted by Qb2k5 View Post
I think BobV answered this in a thread a while back. This is a question that only he or someone qualified in 3D programming could answer.

First up, no console uses OpenGL - the PS3 had an OpenGL|ES wrapper but it was dog slow and anyone caught using it would likely have been sniggered at.

On the PS3 there was libGcm, on the PS4 there is another custom API used called Gnm.
(X360 used a slightly modified version of D3D9 without most of the driver layer. Xbox One will use an extended form of D3D11 with extra functionality for the hardware.)

As for the effect on graphics when going between consoles; previously between the X360 and the PS3 there were 'issues' because one GPU outclassed the other and given the target platforms were DX9-class PC graphics either had a completely different path or were effectively DX9-class even when running on the D3D11 API.

Now, the GPUs themselves are basically identical (numbers and internal customisations not withstanding) which means the effects are going to be identical for the most part, adjustments between PS4 and Xbox will just take into account hardware differences - the shaders themselves, which dictate the effects will likely be written in common code and then compiled for each platform separately.

When it comes to driving the GPU itself things work in layers; your game talks to an abstraction layer which then talks to hardware specific code which then talks to the APIs (be it Gnm, D3D or OpenGL). Unless you are a company which works exclusively on one platform of course in which can you can tightly couple things a bit more. By having this layered system it means we can write code exclusively for one platform and work to its strengths; game facing API aside the code for the D3D11 and PS4 versions of our renderer are nothing alike.

As we can now target a common level (D3D11-class) of feature sets the effects between the 3 major platforms (PC, Xbox and PS4) are largely going to be the same and no one will 'suffer'.
(Interestingly out of the 3 the PC will 'suffer' the most because both the PS4 and Xbox expose functionality which exists in the hardware but not in the PC APIs or at most as an AMD OpenGL extension.)

This is where 'to the metal' programming comes; because we know the hardware we are working to we can make assumptions about things you simply can't on the PC.

Compute shaders are a good example; on the consoles the number of threads working in lock-step at once is fixed and always will be for the life of the console so assumptions can be made to get the best from it. On the PC you either have to dynamically compile shaders, ship multiple copies and select or just accept you are going to be either under using the hardware or suffering stalls due to having to do things safely.

There are other advantages such as being able to line up memory directly for GPU consumption and do finer levels of scheduling for shaders than a driver can do because you know the workloads involved.

However we still use a graphics API on the consoles; it's not as heavy as the PC (which means a lot of work the driver does we have to do ourselves, which makes you appreciate the driver writers a bit more I can tell you!) but there is still a layer to construct the command buffers for you - you can go around these functions in places too if you know what you are doing, although this tends not to be in the first year of the console's life unless things prove a real problem.

And one final note on OpenGL's "speed" vs D3D as reported by Valve.
While I can believe the numbers this was largely a PR stunt to some degree by Valve and NV - the Source engine is/was very D3D9 centric due to when it was written, which means best practises then might well not work as well now. D3D9 is known to have a higher per-draw call over head so this speed difference wasn't the surprising. A lot of what the engine does and how it does it can have an impact on speed simply due to how they interact with the API.

Show me a D3D11 vs OpenGL4 test and I might care a bit more but OpenGL's problem has never been one of 'speed' it's always been one of poor tools, poor driver support (AMD still lacking 4.3 support) and a brain-dead programming model which needs to go and die somewhere frankly.

That's not to say D3D11's way of doing things is The Best Way Evah! but in my opinion as a (published) ex-OpenGL programmer it is the best PC API we have right now.
(And some of that is in part down to the ARB not being able to find its own arse given a map, detailed instructions, GPS coordinates and a picture - I don't trust them to get the job done, say what you like about MS but if we had relied on the ARB to push things forward we'd probably still be looking at graphics of around the 2006 era.)
bobvodka is offline   Reply With Quote