I'm not going to go into the specifics of graphics API's on Vita, PS3 or PS4 since I'm a registered developer for all of those. But you can probably find some info if you look around enough.

The Xbox 360 is actually pretty interesting in terms of the API's they provide. The API superficially resembles D3D9, and in fact you can treat it that way and directly compile D3D9 code meant for a PC and it will work. However unlike the PC version, it also exposes new functionality and additional data structures that control the low-level workings of the GPU. There's actually some Gamefest presentations you can find that go into some of the details, if you're interested. As for the XB1 I have no particular insight into what's being used on that console, but I would guess they're taking a similar approach to allow for easy porting of D3D11-based engines.

Thanks guys for the information shared!!

As linked above, you're talking about PSGL, not GCM. GCM is the native API. PSGL is a wrapper around GCM, which makes it look more like a GL-like API.

Humm thanks for the clarification! So, if I got it right... libGCM is the lowest level used on PS3... PSGL was derivated from OpenGL ES and call the LibGCM 'methods/functions/calls' to deal with PS3 hardware...

Whenever you're working with private SDKs, you have to sign a non-disclosure agreement, which basically means that in exchange for access to these tools, you have to treat them as being top-secret. Breaching the secrecy agreements will get your company's licence revoked, and/or yourself fired.

Humm I can imagine it... so, as I said, I hope someday I can find a place in game industry and be able to work with its tools...

AMD's upcoming Mantle API is supposed to bring many of these abilities to the PC-space

Never heard about it... will google it to see what I can find... Thanks for the info! ( I will give good shots on my feets for sure! )

There's actually some Gamefest presentations you can find that go into some of the details, if you're interested

I will take a look at ( https://www.microsoftgamefest.com/pastconferences.htm ) and see what I can find! thanks a lot!

another nice read:

http://www.psdevwiki.com/ps3/RSX

Yeah, ";-)" was because that was the cheeky answer.

To be less cheeky:

It is true though that it's very hard to play modern games on a PC that's as old as the consoles are -- every time I see a new game come out, I'm truly amazed at the technical skill that's enabled these teams to produce such amazing results on such crappy, crappy old hardware.

If they've made a PS3 version though, then in theory it should be capable of running on a 2006 PC (maybe not at 30Hz though)... but in practice, most devs simply don't support PC's with graphics cards that old any more, because they're too slow and aren't capable enough. Plus CPU's that old are pretty terrible compared to the CPU-power available in the PS3 (provided that the code is written specifically for the PS3, and not just ported directly from PC).

Less API abstraction isn't something that you can easily sum up as giving you x times more performance. Sure, there's less overhead in a lot of things -- e.g. when calling a D3D or GL function, there's quite a few layers of calls, and/or double-indirections (virtual/COM/function-pointer,etc) that occur, which themselves are micro-inefficiencies. Over enough calls, these micro-inefficiencies might add up to a few milliseconds, compared to the direct access that's afforded by the consoles lack of abstraction and direct hardware access.

There's also plenty of other micro-inefficiencies, like having an unpredictable OS and an unpredictable number of background applications/services stealing an unpredictable amount of CPU/GPU time away from your game.

A bigger factor is that having a fixed hardware spec, and much less abstracted access to that hardware enables a different class of algorithms than in D3D. For example, when managing your own resources, you could create an R8G8 texture, and an R16F texture which are allocated in the exact same memory area -- this is called memory aliasing, or in D3D11 it's kind of represented by having different "views" of a resource. In D3D9 though, it's impossible to implement resource aliasing at all.

Simply having this ability might allow a developer to halve the memory requirements of their render-target pool (and they might then use up that saved memory by increasing texture resolution on their models), or it might allow them to achieve a 4x improvement in the throughput of their post-processing effects, etc, etc...

That is, individual algorithms might be able to be implemented in ways that are otherwise impossible, and these individual algorithms could be anywhere from having the same performance, to an order of magnitude better performance...

Because the boosts vary from system to system, it's impossible to quantify in the general case. You can only look at specific cases and compare specific optimized implementations.

There's all sorts of tricks of endless kinds that console folks can pull off, that aren't applicable to the generic desktop world.

e.g. if you've got a fixed GPU that you can talk to directly, then instead of calling graphics API functions at all, you can pre-compute the stream of packets of bytes that you would be sending to this hardware device and you can create a big buffer containing these bytes ahead of time, in a tool... then at runtime you can load that file of bytes, and start streaming them through to the GPU directly. It will behave as if you were calling all the right API functions, but with virtually zero CPU usage... That's only applicable if your rendering commands are static, so in one situation this might give a 100x saving, whereas in another situation it gives no savings.

So, if I got it right... libGCM is the lowest level used on PS3... PSGL was derivated from OpenGL ES and call the LibGCM 'methods/functions/calls' to deal with PS3 hardware...

Almost, but not quite. GCM is the lowest level, but it's also available for direct use. So as a developer you don't have to use PSGL, you can use GCM itself and completely bypass the GL layer.

The "OpenGL Everywhere" people can frequently be seen claiming that using OpenGL allows you to target the PS3, but that's not actually true as nobody who wants performance will actually use PSGL - it's just too slow. Instead, developers will use GCM itself.

e.g. if you've got a fixed GPU that you can talk to directly, then instead of calling graphics API functions at all, you can pre-compute the stream of packets of bytes that you would be sending to this hardware device and you can create a big buffer containing these bytes ahead of time, in a tool... then at runtime you can load that file of bytes, and start streaming them through to the GPU directly. It will behave as if you were calling all the right API functions, but with virtually zero CPU usage... That's only applicable if your rendering commands are static, so in one situation this might give a 100x saving, whereas in another situation it gives no savings.

honestly, I'm glad I don't ever work on projects where stuff like this is necessary. I watched this keynote with John Carmack talking about the texture strategy they used to get Rage to run well on the console - he talked a lot about how he hoped the graphics card companies would release driver sets for closer access to the hardware for pcs - basically saying that its so much easier to optimize code for the consoles because of the closeness the API has to the hardware

I personally do not enjoy this type of programming at all though - its interesting to read about but I hate the idea of writing code to correctly swap memory in and out of here and make sure the data is being sent as fast as possible there.. gosh how much of a headache that sounds like

APIs usually convert simple hardware calls into complex layers of abstract API calls. It always sounds like 'high level apis' make life easier, but in reality, it's the opposite. hardware can do so much more and so much faster if you talk directly to it and its way simpler. e.g. the now coming 'hipster' marketing buz of HUMA and unified architecture and what not, that's the fact if you work directly on the hardware. if you want, you can have just one memory allocator for the whole thing. allocating a texture is as simplle as

myTexture = new uint32_t[width*height];

and there it is (ok, in reality you have to allocate with some alignment etc. but I think you get my point here.

you want to fill it with data?

memcpy(myTexture,pTextureFromStreaming,width*height*sizeof(uint32_t));

you do HDR tonemapping and you want to read the downsampled average tone, and you don't care if it's from the previous frame or even n-2, as you don't want to stall on this call (e.g. if someone has 4x SLI, you don't want stalling even on the n-2 frame as you'd effectivelly kill the SLI parallelization.

vec4 Tone=myHDRTexture[0];

and there are tons of not obvious things, e.g. a drawcalls on PC goes through several security layers until your driver is called. the driver now has to figure out what states you've changed, what memory areas touched that should be synced to the some particular rendering device and finally it has to queue up the work and eventually add some sychronization primitives, as you might want to lock some buffer that are midway of the whole big commandbuffer it created.

on console a drawcall at the lowest level is simply

myCommandBuffer[currentIndex++]=DrawCommand;
GPUcurrentIndex=currentIndex;

that's why an old PS2 can push more drawcalls than your super high end PC. On consoles, nobody is really drawcall count limited, simply because the hardware consumes a commandbuffer fast enough to be limited at other places if you don't do ridiculous stuff like making a drawcall per triangle. on PC and especially on phones (iOS/Android) you are frequently limited by drawcalls. a 333MHz PSP can draw more objects than your latest 2GHz quadcore cellphone that has a gpu close to x360/ps3 performance.

APIs make sense to keep stuff compatible, but I somehow doubt they make anything easier. they have in a lot of cases ridiculous limitations and a lot of times people just try to work around those. e.g. we had some register limits for shaders which made it necessary to introduce pixelshader 2.0a and 2.0b which essentially was one version for ATI and one for NV as they could not hack around in drivers work around the API limitation as they so frequently do in other cases.

it's no different nowadays, modern hardware can use 'boundless resources', which means, you can just set pointers to textures etc. and use those. nvidia supports some extensions which in combination allow you to draw the whole scene with very few drawcalls. but it's an extension, it will take time till maybe directx supports it and in reality, it's again just a work around for the APIs. on console you won't need that kind of multidraws, as you can simply get to the HW limit by pushing individual drawcalls.

and if someone doesn't like to just send drawcalls, then I suggest those person should not want to fizzle around with ogl/d3d, it's so much easier to get some engine that deals with that for you. you can still modify all aspects, but you don't have to and at that point, you'd not care what the engine does beneath. actually, you'd maybe want it to be directly on hardware, otherwise you build a level, it's very low poly, yet it becomes slow and you get told (even as an artist) "well, you cannot have more than 2500visible objects on the screen, it's slow, yes, I know you have all those tiny grass pieces that should render in a millisecond, but those are 2k drawcalls, go and combine those, but don't make them too big, we don't want to render all invisible grass either... huf fun with that instead of building another fun map"