OpenGL ES 3.0?

Taken from semiaccurate (for my sins):

"All members of the Series6 family support all features of the latest graphics APIs including OpenGL ES ‘Halti’, OpenGL 3.x/4.x, OpenCL 1.x and DirectX10 with certain family members extending their capabilities to full WHQL-compliant DirectX11.1 functionality"

Does the fact that Rogue can do OpenGL 4.x indicate that OpenGL ES Halti can do tessellation, or is it really Halti really only a streamlined version of the OpenGL 3.3 feature set?

On a slightly different note, given how infrequently ES is updated it seems backwards to standardise on a hardware feature set that equates to an api that was never very popular from a development PoV (i.e. DX10), when there is a very popular api that is rapidly gaining traction in studios the world over!

 

DX11 is expensive in terms of transistors, and in the markets our customers want to address it doesn't make sense to have those transistors in every graphics IP we ship in the Rogue generation. If we were only shipping into the PC market then I'd agree, but we address so much more than that.

 

Cheers.

That would seem to make it official then, OpenGL ES 3.0 targets the feature set of OpenGL 3.3.

So we get geometry shaders, and possibly the ability to call external API's like OpenCL?

 

If not all Rogue GPU's support DX11 (inc tessellation), then shouldn't the quote above read instead:

“All members of the Series6 family support all features of the latest graphics APIs including OpenGL ES ‘Halti’, OpenGL 3.x OpenCL 1.x and DirectX10 with certain family members extending their capabilities to full WHQL-compliant DirectX11.1 & OpenGL 4.x functionality”

 

It may not have come across very well, but it has been confirmed that all of them will not have DX 11.1, not everyone needs it and as RYS has pointed out it is expensive for IMG TECH to include it.

 

Is it likely then that there will be an 'optional' extension to ES 3.0 to include tessellation, perhaps called ES 3.1 or something similar?

I ask because it would seem logical for Sony to continue using OpenGL ES for the PS3 just as they do with the PS3 today, but I cannot see any PS4 arriving without support for that feature.

Either that, or Sony jumps ship to full-fat OpenGL which doesn't appear to make much sense given that full-fat anything is unnecessary for a games console.....

 

There's only a GL on the PS3 for bringup and debugging purposes. Nobody uses it to ship games.

 

ah, cheers.

 

The de facto standard library used on PS3 is libGCM which is much more performant than PSGL. Having "OpenGL hardware" in something doesn't necessarily mean that people use OGL APIs to build applications: it's worth remembering that OpenGL ES is as much an API as it is a set of features hardware is required to support. This also means that it's possible to have extra functionality in hardware that's not covered by the specification and be able to access that. PS4 could include OGL ES 3.0 compliant hardware and enable tessellation at the same time.

 

That is incorrect, it has been shipped in at least one game.
(But probably in no more games than you can count on a single hand though ^^.)

 

Boxed or downloadable?

 

http://www.gamesindustry.biz/articles/digitalfoundry-strangers-wrath-hd-remasters?page=2

I just remembered that the Oddworld HD remake uses PGSL to maintain as much commonality with the PC OpenGL version. Although, they're now moving the PC version over to DirectX since they're tired of waiting for ATI to fix bugs in their OpenGL drivers and Intel and OpenGL unsurprisingly don't mix well.

 

so does that mean that any hardware that are capable of handling PSGL can be use for PS4 and they don't have to go with nVidia gain for full PS3 BC?

 

No, unless said hardware can also handle G7x binary shaders.

 

quick question:

is there anything that the 554MP2 architecture lacks in order to be compliant, presuming PowerVR create the relevant drivers, with OpenGL ES 3.0?

just curious, because i am presuming 3.0 is going to drop this year in which case the Omap5 may look unattractive for 2013 designs.....

do we have to wait for Rogue before we'll see 3.0 support from PowerVR?

 

I'm not sure but I think OGL_ES3.0/Halti will be give or take on DX10 level. If true then all existing generation small form factor GPUs are going to lack to varying degrees some functionalities Halti might have. Else the question would rather be if you'd have to wait for Rogue, T6xx, Wayne etc to see Halti compliance from about everyone involved in the market.

Just because an API gets released at timeframe X it doesn't necessarily mean that all of the sudden the majority of platforms will have compliant hw integrated. Even for desktop hw starts typically in small amounts and scales up from there as time goes by.

 

i was curious as to whether the 5xx series PowerVR unified-shader cores were capable of operating as geometry shaders just as they can with pixel and vertex shader operations.......?

from an inexpert outsiders view that would appear to be the biggest architectural hitch, not quite the same as requiring a hardware implementation of a tessellation engine were DX11 the target.

 

powervr (at least the ones in the new iphone) dont even support opengl es2.0 fully, I discovered this the other day, I cant do an occlusion test and return number of samples that pass the depth/stencil.
there is a extention from apple though that goes -> bool didanysamplepass()

 

Halti doesn't actually support geometry shaders. I'm not sure I can comment on whether SGX supports Halti, but since SGX544/554 is a superset of DX9_3, there's not that much missing if it doesn't (in which case how much of that gets exposed depends on extensions).

I'm pretty sure occlusion queries aren't in the ES2 spec at all...

 

Where can I find Halti specs ?