Opengl 2.0 - Not Es..?


Holokauston

Member
Joined
Apr 3, 2008
Messages
235
Age
60
Location
Lithuania
Website
will come as soon as i see fit
From the PowerVR SGX factsheet
QUOTE
Industry standard API and OS support

All POWERVR SGX cores share a rich feature set that
enables support for all major industry Application
Programming Interfaces (API) across a wide variety of
Operating Systems (OS).


POWERVR SGX family
2D support
PVR2D enabling BLTs, Alpha Blend BLTs,
ROP2/3/4s, Lines & Surface Rotation

Khronos 2D
OpenVG 1.0.1 & 1.1 enabling Flash and SVG

Khronos 3D
OpenGL 2.0, OpenGL ES 1.1 + Extension Pack
& OpenGL ES 2.0

Microsoft 3D
Direct3D Mobile (all)
& 9L (SGX535 only)
& 10.1 (SGX545 only)

OS support
Linux, Symbian OSTM, WinCE (all)
Microsoft Vista (SGX535 & SGX545 only)



Reading this the SGX should have standard OpenGL2.0 support? or am I missing something? Becuase OpenGL ES 2.0 is listed under 3D as well, in other words they are seen seperate.. And under Microsoft 3D you see that they announce if there isn't support in all versions, right?
 
Holokauston said:
hmm ok false marketing then :(
No. Did you read what I wrote in the other thread?

Xmas said:
So providing OpenGL 2.0 isn't really a question of the hardware supporting every last bit of functionality, but whether the chip manufacturer (in this case TI) is willing to offer and support the drivers for it.
 
Last edited by a moderator:
Holokauston said:
and according to icurafu's post they wont offer that

Edit: As I understand it, it will only be ES

Correct. That doesn't mean there is any false marketing, though.
 
Last edited by a moderator:
Xmas said:
Correct. That doesn't mean there is any false marketing, though.
If you say that it will have something but then it doesn't really have that I would call that a false statement?

it's like listing bluetooth as a function that Pandora has, by that I mean it's possible to install a bluetooth module in to it but it doesn't really have it as a feature, same with OpenGL 2.0, it might have the possibility to use it in theory but as long as you really can't then you can't say that it can.
 
Last edited by a moderator:
Holokauston said:
Xmas said:
Correct. That doesn't mean there is any false marketing, though.
If you say that it will have something but then it doesn't really have that I would call that a false statement?

it's like listing bluetooth as a function that Pandora has, by that I mean it's possible to install a bluetooth module in to it but it doesn't really have it as a feature, same with OpenGL 2.0, it might have the possibility to use it in theory but as long as you really can't then you can't say that it can.

I don't think you're getting the chain of responsibility here. Imgtec - the company that designed the GPU core - claims that the PowerVR SGX can handle full OpenGL 2.0. Texas Instruments - the company who is manufacturing the OMAP3530 which includes the SGX - is selling it with drivers and support for OpenGL ES 2.0 only.

Imgtec isn't lying. Their core is (as far as we know) capable of full OGL 2.0. Once they license the core to TI, TI can do pretty much whatever they want with it. That includes purposely limiting it's features for whatever reason. And as long as TI doesn't claim support for anything that they're not providing, they're in the clear too.

The closest analogy I can think of is cell phones in the US. Most cell companies here are complete bastards. They buy handsets from Japan and Korea with tons of great features (Bluetooth data transfer, simultaneous cell and wifi connectivity, native java support) and then proceed to disable all these features in firmware. There are probably reasons for it beyond "Cell providers are greedy douchebags", but I'm at a loss to think of what they might be. In any case, if LG sells a phone in Korea that can hotsync with a PC over bluetooth, but in the US that same phone requires a $40 cable, LG is not guilty of false marketing. They sold the fully functional phone to Verizon and Verizon dicked it up so they could make the extra $40 on the cable.

With cell phones there are often hacks to enable these vendor-crippled features. Sadly that is not likely to happen with OGL 2.0. We would need access to the "closely guarded industry secrets" that make up Imgtec's drivers. Who knows, maybe they'll have a change of heart and open them up. I wouldn't hold your breath though.

Besides, from what Svartalf has been saying, it doesn't sound like there's all that much difference between OGL 2.0 and OGL ES 2.0.
 
Last edited by a moderator:
Chip said:
Besides, from what Svartalf has been saying, it doesn't sound like there's all that much difference between OGL 2.0 and OGL ES 2.0.

One of the differences is huge in fact: no fixed pipeline. And it's the reason why going from standard OpenGL to OpenGL ES 2.0 is not trivial :)
 
Last edited by a moderator:
Holokauston said:
and according to icurafu's post they wont offer that

Edit: As I understand it, it will only be ES
Reality is, it's not as bad as you'd think being only ES...

Laurent said:
Chip said:
Besides, from what Svartalf has been saying, it doesn't sound like there's all that much difference between OGL 2.0 and OGL ES 2.0.

One of the differences is huge in fact: no fixed pipeline. And it's the reason why going from standard OpenGL to OpenGL ES 2.0 is not trivial :)
It's also not as difficult as you're making it sound. ;)

All one needs to add the fixed functionality paths is to generate a shader for those features and apply them appropriately and not ask for them in the way you used to in the old code. I've went scrounging for the source code to ShaderGen from 3D Labs for this purpose and I've scraped up the 3.0 source dump for the application- it's not compilable in it's current form, but it looks like that problem's easily fixed. Once you have that, you just re-work it to use the shaders (applying the shaders for the effect instead of turning on fog, etc...) and the vertex, texture, etc. coding largely stays the same.

If you're coding for 2.0, you're very likely NOT relying on the fixed functionality paths and if you are, you're not actually using "fixed functionality" anyhow- the driver swaps in a precompiled shader at the right times under the right conditions that accomplishes the "fixed functionality" path for you...

It's the people that're using pre 1.5 coding that'll have a bit of work ahead of them. Pity me- I've got a few I'm wanting to make happen and they're definitely 1.4 version coded. ;)
 
Last edited by a moderator:
Svartalf said:
It's the people that're using pre 1.5 coding that'll have a bit of work ahead of them. Pity me- I've got a few I'm wanting to make happen and they're definitely 1.4 version coded. ;)
It would probably be easier to port those apps to OpenGL ES 1.1 then.
 
Last edited by a moderator:
Svartalf said:
It would. The problem is, unfortunately, we're not likely to have 1.1 available to us. So, it's a modifying I go. ;)
I think it's actually very likely.
 
Last edited by a moderator:
Chip said:
I don't think you're getting the chain of responsibility here. Imgtec - the company that designed the GPU core - claims that the PowerVR SGX can handle full OpenGL 2.0. Texas Instruments - the company who is manufacturing the OMAP3530 which includes the SGX - is selling it with drivers and support for OpenGL ES 2.0 only.

Imgtec isn't lying. Their core is (as far as we know) capable of full OGL 2.0. Once they license the core to TI, TI can do pretty much whatever they want with it. That includes purposely limiting it's features for whatever reason. And as long as TI doesn't claim support for anything that they're not providing, they're in the clear too.

The closest analogy I can think of is cell phones in the US. Most cell companies here are complete bastards. They buy handsets from Japan and Korea with tons of great features (Bluetooth data transfer, simultaneous cell and wifi connectivity, native java support) and then proceed to disable all these features in firmware. There are probably reasons for it beyond "Cell providers are greedy douchebags", but I'm at a loss to think of what they might be. In any case, if LG sells a phone in Korea that can hotsync with a PC over bluetooth, but in the US that same phone requires a $40 cable, LG is not guilty of false marketing. They sold the fully functional phone to Verizon and Verizon dicked it up so they could make the extra $40 on the cable.

With cell phones there are often hacks to enable these vendor-crippled features. Sadly that is not likely to happen with OGL 2.0. We would need access to the "closely guarded industry secrets" that make up Imgtec's drivers. Who knows, maybe they'll have a change of heart and open them up. I wouldn't hold your breath though.

Besides, from what Svartalf has been saying, it doesn't sound like there's all that much difference between OGL 2.0 and OGL ES 2.0.
Ah ok yes you're right I didn't know that TI where the ones blocking :) sucks but io that fact sheet doesn't apply to Pandora but towards TI, and TI strangles the functions and doesn't use it there for ES is the only one working on pandora :)
Thx, this should be on the FAQ as stated :)
 
Last edited by a moderator:
Xmas said:
Svartalf said:
It would. The problem is, unfortunately, we're not likely to have 1.1 available to us. So, it's a modifying I go. ;)
I think it's actually very likely.

You have more info than us, can you share them or are you under NDA? :)
 
Last edited by a moderator:
Laurent said:
Xmas said:
Svartalf said:
It would. The problem is, unfortunately, we're not likely to have 1.1 available to us. So, it's a modifying I go. ;)
I think it's actually very likely.

You have more info than us, can you share them or are you under NDA? :)

maybe he douse http://www.imgtec.com/forum/member_profile.asp?PF=7

i remembered that have read somewhere that the OMAP3 also support OpenGL ES 1.1
i cant just membered were i read it ;)
edit here is something
http://focus.ti.com/docs/prod/folders/print/omap3530.html
Industry Standard API Support: OpenGL ES 1.1 and 2.0, OpenVG1.0 and B)
 
Last edited by a moderator:
Back
Top