Pandora Hardware Capable Of Opengl (not Es)?

[hch]

sorry for opening a new topic but this kind of irks me. googling for the powervr i came across this forum thread today:
http://www.phoronix.com/forums/showthread.php?t=15206
it mainly discusses the intel side of things (linux drivers for the powervr sgx), but there was one statement (top of page 3) that the sgx is capable of full opengl 3.0 and only due to licensing issues the driver in the omap is restricted to opengl ES 2.0. it was also mentioned, that some pandora devs are workig on reverse engineering the chipset to write an open source driver.

i can hardly believe any of this, so i hope that maybe someone here can educate me whether any of this is true.

 

[conso]

The sgx may be capable of ogl 3.0, I'm not really sure about that. We will only have a ogl-es 1.1/2 driver in the start. I don't think that should be a licensing-issue.

Someone will try to reverse-engineer the sgx instructions, but he said he won't make a driver of the info he gains.

 

[fuzzypinkunicorns666]

Unfortunately, that's referring to a different SGX model. The GMA 500 is equivalent to the SGX 535, while the Pandora uses the SGX 530.

 

[hch]

Unfortunately, that's referring to a different SGX model. The GMA 500 is equivalent to the SGX 535, while the Pandora uses the SGX 530.

i thought the only difference between them was the number of cores?

 

[fuzzypinkunicorns666]

I have no idea. I tried googling for it, but didn't find anything meaningful.

 

[craigix]

The chipset is capable of full 2.0.

 

[BackAssward]

The chipset is capable of full 2.0.

Is licensing for the driver the hold back then, for why we have ES not full? If someone hacks the driver and makes it full 2.0 compliant, does that really help since it`s not in the NAND? (Of course, working with TI, I know you`d never advocate hacking the driver anyway, just a hypothetical question.)

 

[hch]

The chipset is capable of full 2.0.

thanks a lot for the info!

 

[Gautama]

My eyebrow has raised.

 

[drkIIRaziel]

Is licensing for the driver the hold back then, for why we have ES not full? If someone hacks the driver and makes it full 2.0 compliant, does that really help since it`s not in the NAND? (Of course, working with TI, I know you`d never advocate hacking the driver anyway, just a hypothetical question.)

Because ES is considered is better than the 'full' opengl ? Because it is more compact, and (hopefully) allows for faster and lighter drivers ?

From what i know the hardware is very capable.

 

[BackAssward]

QUOTE

Is licensing for the driver the hold back then, for why we have ES not full? If someone hacks the driver and makes it full 2.0 compliant, does that really help since it`s not in the NAND? (Of course, working with TI, I know you`d never advocate hacking the driver anyway, just a hypothetical question.)

Because ES is considered is better than the 'full' opengl ? Because it is more compact, and (hopefully) allows for faster and lighter drivers ?

From what i know the hardware is very capable.


I`m not sure I understand your response. Even if ES is more efficient than full opengl, I was asking why *both* might not be offered (btw, who considers ES better than "full opengl" as you have posited?). You can "hope" ES is faster and lighter than Full GL. That isn`t an honest response to my question.

From these forums, it is clear a lot of people would like full opengl (something to do with shaders, I believe I`ve read.). For ports or homebrew, a lot of people want the non-ES capabilities in a driver.

Really, I don`t see how your response answers my post.

 

[Butterman]

If we had OGL 2.0, porting shit would be a cakewalk.

 

[atomicthumbs]

So licensing is the only reason we have to use ES?

My eyebrow has raised.

 

[dflemstr]

Why would it be licensing problems?
The main reason why we don't have OGL2.0 is because the 3D driver is proprietary, only supports OGLES at the moment and we don't have anything else to use the 3D-chip with.

OK, you could call that licensing problems

 

[hch]

Why would it be licensing problems?
The main reason why we don't have OGL2.0 is because the 3D driver is proprietary, only supports OGLES at the moment and we don't have anything else to use the 3D-chip with.

OK, you could call that licensing problems

in the original thread i quoted it sounds like TI only licensed the ES part for their omap while intel licenced the full ogl for their gma 500 from imagination tech. and since all of this is binary only... well.

 

[BackAssward]

If we had OGL 2.0, porting shit would be a cakewalk.

Thanks, I think you made part of my point/question.

 

[Creature XL]

I`m not sure I understand your response. Even if ES is more efficient than full opengl, I was asking why *both* might not be offered (btw, who considers ES better than "full opengl" as you have posited?). You can "hope" ES is faster and lighter than Full GL. That isn`t an honest response to my question.

From these forums, it is clear a lot of people would like full opengl (something to do with shaders, I believe I`ve read.). For ports or homebrew, a lot of people want the non-ES capabilities in a driver.

Really, I don`t see how your response answers my post.

Just compare the OpenGl 3.0 API to the OpenGl ES 2.0 API. it is obvious that the stuff they stripped out on the move from openGL 2.0 to openGL 3.0 is the similar to the stuff which OpenGL ES 2.0 is missing. so MAYBE the Krohnos group thinks that the stuff is not needed any more?

Of course devs want full OpenGL 2.0. Because ALL apps are coded against the OpenGL 2.0 API and they wouldn't have to do nothing to port such an app to the Pandora if it would be offering OpenGL 2.0. Now, they have to change everything what is not supported by OpenGL ES 2.0

For example, you didn't have the primitive "quad "any more. No problem, you still have triangles. and a quad is made of 2 tris. BUT now YOU have the work to do, to put 2 tris in your array instead of one quad.
I want to display something which is made of rectangles. using full OGL I would just put quads in my array, now i have 4 lines of extra code to make it 2 tris. You see, they moved OUT some stuff from the driver, which can be done by the dude coding the app. Keeping in mind, that MOST stuff only needs triangles, they put the burden on the guy who wants to use quads

 

[BackAssward]

I`m not sure I understand your response. Even if ES is more efficient than full opengl, I was asking why *both* might not be offered (btw, who considers ES better than "full opengl" as you have posited?). You can "hope" ES is faster and lighter than Full GL. That isn`t an honest response to my question.

From these forums, it is clear a lot of people would like full opengl (something to do with shaders, I believe I`ve read.). For ports or homebrew, a lot of people want the non-ES capabilities in a driver.

Really, I don`t see how your response answers my post.

Just compare the OpenGl 3.0 API to the OpenGl ES 2.0 API. it is obvious that the stuff they stripped out on the move from openGL 2.0 to openGL 3.0 is the similar to the stuff which OpenGL ES 2.0 is missing. so MAYBE the Krohnos group thinks that the stuff is not needed any more?

Of course devs want full OpenGL 2.0. Because ALL apps are coded against the OpenGL 2.0 API and they wouldn't have to do nothing to port such an app to the Pandora if it would be offering OpenGL 2.0. Now, they have to change everything what is not supported by OpenGL ES 2.0

For example, you didn't have the primitive "quad "any more. No problem, you still have triangles. and a quad is made of 2 tris. BUT now YOU have the work to do, to put 2 tris in your array instead of one quad.
I want to display something which is made of rectangles. using full OGL I would just put quads in my array, now i have 4 lines of extra code to make it 2 tris. You see, they moved OUT some stuff from the driver, which can be done by the dude coding the app. Keeping in mind, that MOST stuff only needs triangles, they put the burden on the guy who wants to use quads


I still don`t see that the response was applicable to my post.

For games not needing heavy optimization, OGL "full" would be simpler for them (see the other`s posts). For games needing optimization, ES might be harder but make more sense (if you say so).

Really, there is no argument for NOT supporting both ES and Full in the driver than possibly licensing (which was my original post BTW).

I was not arguing the benefits of either, just the benefits of offering both. In fact, I wasn't arguing anything, just asking the reason why "full" wasn`t available.

 

[gruso]

I think HCH answered your question in post #15.

 

[BackAssward]

I think HCH answered your question in post #15.

If you are responding to me, then yes. He responded as to why it wasn`t possible, but not how it was better that way. CraigiX already responded that full 2.0 was possible, and a few others indicated of that possibility was desirable.

If you look at my previous post (the first one), I referred to the individual working on reverse engineering the original DSP driver, and how it might result in a *full* OGL 2,0 solution. And if it was desirable.