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.
 
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:
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:
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:
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:
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:
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:
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?
 
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:
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).
 
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:
Back
Top