I can understand the texturing/filling takes power but could it really be as bad as dragging it down to 2,5%? Sounds really, really bad but I have been thinking a bit about this and come up with a two other things that might also play big roles in pulling down the amount; First off, (and this is a big thief I would guess) using float values instead of fixed-point for the OpenGL stuff since this means it will have to simulate the float calculations; Second, I thought about this about JNI, the overhead is fairly big since it occurs every time you make a GL (and not sure but would guess the float sim is also native? in that case it's extra load + extra overhead for every calculation?) call so trying to limit them by using other methods of culling for ex. before you even get to rendering might help avoid a few calls?
Would be really great to get this number up to at least a steady FPS with ~ 20000 polys / frame and I feel it should be possible ARM 11 Qualcomm MSM7200A 528 MHz with 256 MHz ARM9 2nd core, Hardware 3D graphics support with up to 4 million 3D triangles per second, and 133 million 3D textured pixels per second fill rate, OpenGL ES- compliant 3D graphics 4 million 3D triangles per second and 133 million 3D textured pixels per second fill rate Feels weird that there is no "real world" way to get even 10-15% of that on the phones? On Nov 10, 8:17 pm, Robert Green <rbgrn....@gmail.com> wrote: > Jni is not really a big factor in this. In my experience, if you use > vbos, you're not nearly as triangle bound as you are fill bound. If > you're only filling half the screen and you use vbos with no normals > and no index, I imagine you could get up there with vert count. > > Here's a little test to see where the texel unit has limits and > optimizations... make a quad that's bigger than the viewport and > texture it. Rotate it so that it faces the lookat directly, so that > there is no skew or distortion. It will render very quickly. Now > rotate it just a degree away from the lookat about any axis. You'll > see the framerate drop significantly. > > This shows that no matter how few or many triangles you have on > screen, you will always be limited by the texture unit. > > On Nov 10, 1:36 am, Patrick Årman <nemon...@gmail.com> wrote: > > > Ok so no where near the chips full potential then, sad to hear, did you use > > buffers and minimized glcalls? I'm guessing you used only Java and no native > > code? Though the JNI might be the bottleneck? > > > On Nov 10, 2009 7:44 AM, "Jeremy Slade" <jeremy.g.sl...@gmail.com> wrote: > > > 4-5k polys per frame seems about right from my experience on a G1 > > > On Nov 9, 1:42 pm, Patrick <nemon...@gmail.com> wrote: > Well I've been > > searching for this informa... > > -- > > 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<android-developers%2Bunsubs > > cr...@googlegroups.com> > > For more options, visit this group > > athttp://groups.google.com/group/android-developers?hl=en -- 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
