opengl es 2.0 at 3000 polys too slow?

[Peabrain]

hello,


i'vw got a little problem. i'm programming a opengl es 2.0 application.


but 3000 polgygons are too much for the pandora. or isn't it?


i use the cdev-tools on pandora and the libGLESv2, libEGL for linking.


perhaps i forgot some compilerdefines? or is this the wrong sdk?


i use normal bumpshader.


please help me.


best regards,


Peabrain

 

[Exophase]

I think you'll have to be more specific in order to get any help. You say 3000 polygons are too much - what does that mean exactly? They only render at a rate of 3000 per second (or some other unit of time?) and you expect more? Or you're drawing 3000 and it doesn't work? And if it's 3000 per second. what kind of polygons? If they're 20 pixels each then of course that'd seem way too slow, but if they're 10,000 pixels then maybe not.

 

[Peabrain]

I think you'll have to be more specific in order to get any help. You say 3000 polygons are too much - what does that mean exactly? They only render at a rate of 3000 per second (or some other unit of time?) and you expect more? Or you're drawing 3000 and it doesn't work? And if it's 3000 per second. what kind of polygons? If they're 20 pixels each then of course that'd seem way too slow, but if they're 10,000 pixels then maybe not.

i have a fullscreenapplication. that means, that 3000 polygones on the screen. and i have 10 fps.that means that 384000 pixels will be rendered. backface culling is on. but i don't know how much faces will be skipted.


but it must be possible to render 384000 pixels in 50 fps.


or not?


and check this out


http://en.wikipedia.org/wiki/PowerVR


its specs are really good. but perhaps the libOGLESv2 from open pandora is a softwareemulation.

 

[Exophase]

i have a fullscreenapplication. that means, that 3000 polygones on the screen. and i have 10 fps.

Okay, so 30,000 polygons per second.

that means that 384000 pixels will be rendered.

So your polygons are on average 128 pixels each?

backface culling is on. but i don't know how much faces will be skipted.
but it must be possible to render 384000 pixels in 50 fps.


or not?


and check this out


http://en.wikipedia.org/wiki/PowerVR


its specs are really good. but perhaps the libOGLESv2 from open pandora is a softwareemulation.

It's not software emulation. But without seeing the actual source code no one could even begin to guess as to why your code isn't as fast as you expect it to be. You claim you're drawing a little under 4 million pixels per second, with an unknown amount of overdraw. Pandora can handle about 220 million cycles of fragment shading per second, and 110 million texture accesses. If you're not careful with your fragment shaders they can use many cycles. And if you use discards in them it can cut your speed in half, even if the discards are conditional and rarely executed.

 

[_wb_]

It's probably better to share some example code, if you're lucky someone will find the bottleneck for you.

 

[Peabrain]

i have a fullscreenapplication. that means, that 3000 polygones on the screen. and i have 10 fps.

Okay, so 30,000 polygons per second.

that means that 384000 pixels will be rendered.

So your polygons are on average 128 pixels each?

backface culling is on. but i don't know how much faces will be skipted.
but it must be possible to render 384000 pixels in 50 fps.


or not?


and check this out


http://en.wikipedia.org/wiki/PowerVR


its specs are really good. but perhaps the libOGLESv2 from open pandora is a softwareemulation.

It's not software emulation. But without seeing the actual source code no one could even begin to guess as to why your code isn't as fast as you expect it to be. You claim you're drawing a little under 4 million pixels per second, with an unknown amount of overdraw. Pandora can handle about 220 million cycles of fragment shading per second, and 110 million texture accesses. If you're not careful with your fragment shaders they can use many cycles. And if you use discards in them it can cut your speed in half, even if the discards are conditional and rarely executed.

ok, thank, i will check something. but first, i can say, that the diffuse shader is much faster, then my bumpshader. by the way, my shader compiler doesn't know the command "float max(float,float)". but opengl es 2.0 does.

It's probably better to share some example code, if you're lucky someone will find the bottleneck for you.

yes, thats a great idea. but how can i do this?

 

[_wb_]

Depends how small you can make it while still compiling and showing the slow behavior you want to improve. If it's small enough, just put it in a

Spoiler

spoiler code block like this

or else make a .zip file and attach it to a forum message. Or put it in a public cvs/svn/git repository, and point to that.

 

[Peabrain]

ok, i have it now as .zip file. but i don't know how to send it or attach it. when i click on MyMedia i must have a Medialibrary here. but how?


damned. :/

 

[Tramb]

If you don't mind your code being open, I'd advise to learn git and use github, you'll share your code easily and you'll gain many many benefits for yourself.

 

[Linux-SWAT]

ok, i have it now as .zip file. but i don't know how to send it or attach it. when i click on MyMedia i must have a Medialibrary here. but how?


damned. :/

Use the full editor from the "more reply options".

 

[Peabrain]

ok, i thin, i got it.


https://github.com/Peabrain/OpenPandoraGLTest.git


forgive me for the bad makefiles. but i'm beginner in makefile. ok, you go to Sources and do the make. you can also go to all dirs and do the makefile on your own


if all is done, the program is in "Bin/" . its the "launcher". the control are easy. only the left nub to control the direction and die shoulderbutton to control the movement.


i hope you can do it


best regards,


peabrain

 

[Peabrain]

And here as zip.

OpenPandoraGLTest.zip

 

[sebt3]

Using highp is no good idea. change that to mediump (or lowp) to at least double your frame rate.


For more information, see http://boards.openpandora.org/index.php?/topic/5261-scale2x-scale3x-shaders/

 

[Exophase]

Your fragment shader is really pretty complex, even games running on high end phones don't tend to use such expensive techniques as per-pixel bump-mapping and phong shading, and those GPUs can be several times faster than Pandora's. The SGX530 in OMAP3530 really doesn't have a lot of fragment shading grunt, you have to lower your expectations a lot. I expect those highp vec3 normalize functions to be costing you at least 6-7 cycles each (FADD, 2 FMADDs, one reciprocal square root, three multiplications by the reciprocal). I see 3 of those, a highp vec3 dot (FADD + 2FMADDs), 3 loose highp FMADDs, 3 loose highp FMULs, 1 loose highp FADDs and 5 FMAX. So right off the bat that's like 33 cycles minimum assuming there are no tricks I don't know about, posisbly far more cycles if it has some weaknesses. There are also cycles needed to perform interpolation and texture sampling but you'd expect those could happen in parallel with the shader cycles, although enough texture cache misses may give you problems. It may also cost you extra shader cycles just passing the sampler coordinates through highp variables. More cycles as well if there's alpha blending (you don't glEnable it so I assume not).


If you are 100% shader limited and getting 3.84m pixels per cycle, if you have zero overdraw with those pixels, that'd mean about 57.3 cycles per pixel (assuming the SGX clocks are running at the correct 110MHz speed). Part of that would be for vertex shading, which takes more cycles than your fragment shader, but since you only have 3000 polygons it'd be a small fraction. So my rough calculation for a minimum isn't a huge amount off from the theoretical peak. This is assuming two things: that something else isn't causing an even bigger bottleneck and that the shader engines can always stay busy. Your code is really abstracted and I don't really know what the scene is like so it's hard for me to even give a good guess.


Definitely follow sebt3's advice, that will make a huge difference, especially with lowps, but even then I don't think it'll get you as fast as you want to be. The only optimizations I can think of are to bake the * 2.0 - 1.0 that you perform on samplerNormal into the texture itself, and that unless you're using alpha for anything there's no point calculating bTex.w.

 

[Peabrain]

Thank you very much. that was a great help. i don't know such details about the gpu. thats awesome


i will try my best to simplify my shaders

 

[Lazrhog]

Also, cut down on the number of times you switch texture maps (I haven't looked at your code). Switching textures too often is a common cause of slowdown

 

[ibisum]

It would be great to see a new version, eh? I'm finding the details in this thread very interesting, as well ..