Opengl 1.1+ & 2.0 Support


flatmush

Member
Joined
Feb 29, 2008
Messages
132
A lot of people are talking about needing to use openGL ES but the factsheet clearly states that all of the SGX series is capable of openGL 1.1+ and openGL 2.0 support. Now I'm wondering if anyone knows if we would have to pay for the conventional openGL support or if there's any reason we couldn't just run straight ogl.
The only imposed limitation is that the SGX530 will not run directx 9.1 or 10 but I don't think anyone here would lose any sleep over that, especially considering the wine project has proven an opengl wrapper can be made.
 

icurafu

The Hallucinogenic Elf
Joined
Sep 28, 2005
Messages
2,078
Location
Sydney, Australia
Website
gamesreborn.blogspot.com
flatmush said:
A lot of people are talking about needing to use OpenGL ES but the factsheet clearly states that all of the SGX series is capable of openGL 1.1+ and openGL 2.0 support. Now I'm wondering if anyone knows if we would have to pay for the conventional openGL support or if there's any reason we couldn't just run straight ogl.
The only imposed limitation is that the SGX530 will not run directx 9.1 or 10 but I don't think anyone here would lose any sleep over that, especially considering the wine project has proven an opengl wrapper can be made.
I spoke to PowerVR about this. You only get OpenGL ES 2.0 hardware that is compatible with 1.1. Also, you get DirectX 7 3D mobile. You don't get any hardware for Windows XP or Vista.

The next model up SGX 535 is nearly the same except with the DX9 hardware and OpenGL 2.0 hardware and will be found in the single core CentrinoNanos.
 
Last edited by a moderator:

Svartalf

Member
Joined
Mar 25, 2008
Messages
967
Location
Dallas, TX
Website
www.earlconsult.com
icurafu said:
I spoke to PowerVR about this. You only get OpenGL ES 2.0 hardware that is compatible with 1.1. Also, you get DirectX 7 3D mobile. You don't get any hardware for Windows XP or Vista.

The next model up SGX 535 is nearly the same except with the DX9 hardware and OpenGL 2.0 hardware and will be found in the single core CentrinoNanos.
I figured as much. To be sure, this is much less of a big deal than most people are making it out to be.

OpenGL > OpenGL ES. If you code for ES, your code will be largely OpenGL code to begin with. OpenGL ES is basically OpenGL with a few tweaks to accomodate things like fixed point data types and offering pre-compiled shaders, etc. 'ES' stands for "Embedded Subset". ES 1.1 is OpenGL 1.5 without shader support and immediate mode operations- with a few things like fixed point data types mixed in. ES 2.0 is intrinsically OpenGL 2.0, sans any fixed functionality support (pure programmable pipeline...) with precompiled shaders being the norm instead of inline compilation (many embedded systems won't have the resources available for JIT on that...).

If you're coding for the PS3, you're most likely going to be doing ES 2.0 coding anyhow.

The effort will be in taking hickeys out on code where it presumes immediate mode ops, fixed functionality, etc. If you're doing array ops and fixed functionality, you'll need to tie in 2.0 shader ops and make shaders to handle things. If you're doing shader based code anyhow, you'll be migrating to the minimal changes in ES SL from GLSL and moving your code largely over with only possibly fixed point changes. If you're moving a DX9/DX10 title, you'll make the DX to GL move and port your shaders over to GLSL from HLSL (with AMD's Open Source tool) and clean up accordingly. The effort, while present, isn't as bad as people keep making it out to be. It should be fine in most cases for most people. :D
 
Last edited by a moderator:

Xmas

Member
Joined
Sep 24, 2007
Messages
112
Some not-so-old desktop graphics cards fall back to software rendering when you request certain features. 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.


Svartalf said:
with precompiled shaders being the norm instead of inline compilation

I'm not so sure about binary shaders becoming the norm ("being" is the wrong word given that there are no devices supporting ES 2.0 yet ;)). At least when considering open platforms.

QUOTE
If you're coding for the PS3, you're most likely going to be doing ES 2.0 coding anyhow.

PSGL is based on OpenGL ES 1.1 with several extensions, most notably Cg shaders. Also, from what I've heard most developers don't use it.
 
Last edited by a moderator:

Svartalf

Member
Joined
Mar 25, 2008
Messages
967
Location
Dallas, TX
Website
www.earlconsult.com
Xmas said:
I'm not so sure about binary shaders becoming the norm ("being" is the wrong word given that there are no devices supporting ES 2.0 yet ;)). At least when considering open platforms.
Precompiled on the target. ES typically doesn't include shader compilation support in the driver layer- you have to pre-build in many cases. You'd provide source code to build them in the project. :D

Heh... I worked for one of the vendors of OpenGL/OpenGL ES hardware at one point- while I was only working on OpenGL, you ended up kind of steeped in the other when your boss is one of the people on the Khronos committee for ES... ;)

Xmas said:
PSGL is based on OpenGL ES 1.1 with several extensions, most notably Cg shaders. Also, from what I've heard most developers don't use it.
Hm... Caught that. So what ARE they using? I know that Haze didn't do anything other than OpenGL.
 
Last edited by a moderator:

ldesnogu

Very Active Member
Joined
Dec 26, 2006
Messages
1,049
Age
53
Location
France
Website
Visit site
Svartalf said:
OpenGL > OpenGL ES. If you code for ES, your code will be largely OpenGL code to begin with. OpenGL ES is basically OpenGL with a few tweaks to accomodate things like fixed point data types and offering pre-compiled shaders, etc. 'ES' stands for "Embedded Subset". ES 1.1 is OpenGL 1.5 without shader support and immediate mode operations- with a few things like fixed point data types mixed in. ES 2.0 is intrinsically OpenGL 2.0, sans any fixed functionality support (pure programmable pipeline...) with precompiled shaders being the norm instead of inline compilation (many embedded systems won't have the resources available for JIT on that...).

You make it seem as if OpenGL ES 2.0 is using fixed-point which is not the case (exception: vertex attribute arrays).

I am not saying you said ES 2.0 was using fixed-point, just that it was not clear :)
 
Last edited by a moderator:

Xmas

Member
Joined
Sep 24, 2007
Messages
112
Svartalf said:
Precompiled on the target. ES typically doesn't include shader compilation support in the driver layer- you have to pre-build in many cases. You'd provide source code to build them in the project. :D

I suppose you mean precompiled on the build platform, not on the target. But again, it's hard to tell what's going to be typical for a class of devices that doesn't even exist yet. I would actually expect most open platforms with OpenGL ES 2.0 (including Pandora) to support shader source compilation in the driver. Which of course doesn't mean they won't support precompiled binary shaders, too.
QUOTE
Heh... I worked for one of the vendors of OpenGL/OpenGL ES hardware at one point- while I was only working on OpenGL, you ended up kind of steeped in the other when your boss is one of the people on the Khronos committee for ES... ;)

Who was your boss then? I guess I might know him... :)


QUOTE
Hm... Caught that. So what ARE they using? I know that Haze didn't do anything other than OpenGL.

I have to admit I don't know, but I'm pretty sure that if devs have low-level access it's under NDA.
 
Last edited by a moderator:

barzoule

Still Fresh
Joined
Sep 19, 2006
Messages
79
so if i understand well, an opengl ES application would compile and run ok on, say, a windows xp desktop, but to go from a win32 ogl app to make it compile and run on pandora, i'd have to cut and replace parts of it, right?

then is there any OpenGL ES lib for Win32 (or useful doc?) that i could use to help me have my code Pandora-ready for when it's available?
 

Svartalf

Member
Joined
Mar 25, 2008
Messages
967
Location
Dallas, TX
Website
www.earlconsult.com
barzoule said:
then is there any OpenGL ES lib for Win32 (or useful doc?) that i could use to help me have my code Pandora-ready for when it's available?
The "emulator" wedge that Imagination Technologies is offering should offer that ability- keep in mind that you need an OpenGL 2.0 capable device and a driver that properly supports OGL 2.0 to use the thing. It should work on Windows and Linux. Right now, there's a few decent tools on the Windows side and less on the Linux side (You'd have to do some manual steps right now...) but there's a few tools that once they're brought to more modern terms will provide much of the infrastructure on the Linux side.
 
Last edited by a moderator:

hybrid_irr

Still Fresh
Joined
Mar 20, 2008
Messages
25
The emulator works pretty well under Linux. Nothing needed besides the usual build tools.
An OpenGL-ES application won't run under Windows or Linux without special support, such as the OpenGL-ES emulator. It won't even compile because the ogl-es library is needed for linking. The other way, i.e. porting an OpenGL app to OpenGL-ES is muc more work, though, depending on the amount of fixed function usage (at least for ogl-es 2).
 

Svartalf

Member
Joined
Mar 25, 2008
Messages
967
Location
Dallas, TX
Website
www.earlconsult.com
hybrid_irr said:
The emulator works pretty well under Linux. Nothing needed besides the usual build tools.
An OpenGL-ES application won't run under Windows or Linux without special support, such as the OpenGL-ES emulator. It won't even compile because the ogl-es library is needed for linking. The other way, i.e. porting an OpenGL app to OpenGL-ES is muc more work, though, depending on the amount of fixed function usage (at least for ogl-es 2).
The only gotchas are the toolchains for doing ES stuff is sparse on Linux right at the moment. No shader development tools to make life easier, etc. As for the fixed function usage, heh... It's going to be a minor pain, but I'd think once you generated a fixed functionality shader "library" for GLSL/ESSL you'll have less pain involved.
 
Last edited by a moderator:
Top