[android-developers] Re: Fil-rate workaround with FBOs?
I have a followup question, of course...
So, I am successfully rendering my scene to an FBO-texture, then using
that texture on a Quad in the background (so GPU renders to FBO
dimensions, and quad stretches it to screen dimensions). And it
works.
So, I thought, perhaps the OES drawTex function would be a faster way
of getting that FBO texture to the background than a normal quad.
So, after some hair-pulling wrt GL11Ext vs GL11ExtensionPackage, I get
that working. Which is to say I get drawTex working to render a
texture to the background, and it is faster than a quad, so I like it.
But while my FBO texture is clearly 'ok' (it renders fine as a quad)
and my drawTex code is 'ok' (it renders Joe Random Texture just fine),
when I try to use drawTex to draw the actual FBO texture, it's not
fine (not on my Moto Droid I at least). It renders all black.
Again, exact same code, only difference being which texture I bind,
renders great ('normal' textures) or renders black (FBO texture), and
I 'know' the FBO texture is filled with colorful goodness. And it's
really rendering black, not just 'not rendering'
All the explanations I can think of feel like they should be equally
true of the other texture.
I guess I should try it in the emulator
On Sep 15, 1:30 am, Samsyn wrote:
> Well, I ran the experiement...
>
> 1.) it does work, though apparently the FBO texture ends up upside
> down with relation to all my other textures, so I had to do a little
> correction for that
> 2.) it does increase the frame rate, but not substantially
> 3.) it does look worse (a 256x256 FBO is not too awful. 128x128 is
> horrid)
> 4.) it consumes extra memory (for the FBO buffer(s))
>
> on a Moto Droid I, my reference scene
>
> Without FBOs, rendering to full screen: about 20 fps
> With FBOs, rendering to 128x128: about 28.5fps
> With FBOs, rendering to 256x256: about 26.2fps
> With FBOs, rendering to 32x32: about about 30 fps (clearly unusuable,
> of course, unless you wanted a illusion of out of focus)
>
> 512x512 is not on the table as you get an out of memory condition with
> high regularity
>
> I still have to try it on the Eris (my problem phone), but overall, I
> don't think the result really justifies the feature.
>
> I'm pretty sure the fill rate I save with the smaller render target is
> lost with the render of the background quad with that texture on it.
> Perhaps if I had a clever way to jam the texture (and stretch it
> nicely) into the colorBuffer directly...
>
> On Sep 12, 1:12 pm, Samsyn wrote:> My apologies
> if this is a stupid question...
>
> > Might I get a net frame rate improvement if I did something like this:
>
> > * create an FBO of resolution less than the full phone screen
> > dimensions (user-selected quality vs speed option)
> > * do most of my scene rendering into that FBO
> > * then the 'real' (full screen) render would either use the FBO as the
> > starting background color buffer contents, or render it (probably
> > orthographically) as a single quad.
> > * then probably add UI/Text decoration on top of that, where the
> > resolutions really benefits.
>
> > And, is there some egl glue (I am a glSurfaceView kinda dood) that
> > would automagically do something like this in the first place?
>
> > Or am I being naive to think the GPU could do its work faster if it
> > was rendering to a lower resolution target?
>
> > And would the phone with the worst fill rate also be the phone that
> > doesn't support FBOs in the first place?
>
> > After reading the OpenVR info (thanks again, Lance) I think I might
> > get some improvement by breaking some huge triangles into smaller
> > ones. I have some (water layer, in particular) that are so large they
> > probably get processed by every tile of the screen.
>
> > Thanks for any insights,
>
> > - Dan
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Fil-rate workaround with FBOs?
Fill rate does seem to be the biggest issue with performance. I would make sure you have stuff like blending off to make the quad go as fast as it can. On 9/15/2010 4:30 AM, Samsyn wrote: Well, I ran the experiement... 1.) it does work, though apparently the FBO texture ends up upside down with relation to all my other textures, so I had to do a little correction for that 2.) it does increase the frame rate, but not substantially 3.) it does look worse (a 256x256 FBO is not too awful. 128x128 is horrid) 4.) it consumes extra memory (for the FBO buffer(s)) on a Moto Droid I, my reference scene Without FBOs, rendering to full screen: about 20 fps With FBOs, rendering to 128x128: about 28.5fps With FBOs, rendering to 256x256: about 26.2fps With FBOs, rendering to 32x32: about about 30 fps (clearly unusuable, of course, unless you wanted a illusion of out of focus) 512x512 is not on the table as you get an out of memory condition with high regularity I still have to try it on the Eris (my problem phone), but overall, I don't think the result really justifies the feature. I'm pretty sure the fill rate I save with the smaller render target is lost with the render of the background quad with that texture on it. Perhaps if I had a clever way to jam the texture (and stretch it nicely) into the colorBuffer directly... On Sep 12, 1:12 pm, Samsyn wrote: My apologies if this is a stupid question... Might I get a net frame rate improvement if I did something like this: * create an FBO of resolution less than the full phone screen dimensions (user-selected quality vs speed option) * do most of my scene rendering into that FBO * then the 'real' (full screen) render would either use the FBO as the starting background color buffer contents, or render it (probably orthographically) as a single quad. * then probably add UI/Text decoration on top of that, where the resolutions really benefits. And, is there some egl glue (I am a glSurfaceView kinda dood) that would automagically do something like this in the first place? Or am I being naive to think the GPU could do its work faster if it was rendering to a lower resolution target? And would the phone with the worst fill rate also be the phone that doesn't support FBOs in the first place? After reading the OpenVR info (thanks again, Lance) I think I might get some improvement by breaking some huge triangles into smaller ones. I have some (water layer, in particular) that are so large they probably get processed by every tile of the screen. Thanks for any insights, - Dan -- Leigh McRae www.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Fil-rate workaround with FBOs?
Well, I ran the experiement... 1.) it does work, though apparently the FBO texture ends up upside down with relation to all my other textures, so I had to do a little correction for that 2.) it does increase the frame rate, but not substantially 3.) it does look worse (a 256x256 FBO is not too awful. 128x128 is horrid) 4.) it consumes extra memory (for the FBO buffer(s)) on a Moto Droid I, my reference scene Without FBOs, rendering to full screen: about 20 fps With FBOs, rendering to 128x128: about 28.5fps With FBOs, rendering to 256x256: about 26.2fps With FBOs, rendering to 32x32: about about 30 fps (clearly unusuable, of course, unless you wanted a illusion of out of focus) 512x512 is not on the table as you get an out of memory condition with high regularity I still have to try it on the Eris (my problem phone), but overall, I don't think the result really justifies the feature. I'm pretty sure the fill rate I save with the smaller render target is lost with the render of the background quad with that texture on it. Perhaps if I had a clever way to jam the texture (and stretch it nicely) into the colorBuffer directly... On Sep 12, 1:12 pm, Samsyn wrote: > My apologies if this is a stupid question... > > Might I get a net frame rate improvement if I did something like this: > > * create an FBO of resolution less than the full phone screen > dimensions (user-selected quality vs speed option) > * do most of my scene rendering into that FBO > * then the 'real' (full screen) render would either use the FBO as the > starting background color buffer contents, or render it (probably > orthographically) as a single quad. > * then probably add UI/Text decoration on top of that, where the > resolutions really benefits. > > And, is there some egl glue (I am a glSurfaceView kinda dood) that > would automagically do something like this in the first place? > > Or am I being naive to think the GPU could do its work faster if it > was rendering to a lower resolution target? > > And would the phone with the worst fill rate also be the phone that > doesn't support FBOs in the first place? > > After reading the OpenVR info (thanks again, Lance) I think I might > get some improvement by breaking some huge triangles into smaller > ones. I have some (water layer, in particular) that are so large they > probably get processed by every tile of the screen. > > Thanks for any insights, > > - Dan -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
