The question "are VBOs faster" is a very subjective one. I can answer the question "are VBOs faster for large amounts of static geometry" and the answer in my experience has been "yes, very much so, especially on first-gen devices."
For quads and such? No. In fact, it could actually be slower depending on the chip and implementation. VBOs are designed to reduce bus bandwidth usage for static geometry. If you're not pushing too much across that bus (as in the case of quads or very few, very low poly objects), they won't do much. If, on the other hand, you're actually running static scenes that are moving 5k polys per draw eg (7.5k verts, 7.5k normals, 15k indices, 7.5k UVs) = 270Kb, you will most likely see some sort of improvement, especially on chips like the qualcomms as they have fairly slow transfers. Just think, 270Kb @30fps = 8.1Mb of memory copying per second you're saving using VBOs. If you're rendering scenes that have REALLY large amounts of geometry (for mobile), such as 50k or 100k polys, you'll find that you'll be totally vert-bound on the first gen devices, so there's kind of that limit there as to how effective VBOs can be. The spots where they REALLY shine, like really high poly counts, can't ever be used on the first-gen phones because they are incapable of processing that many vertices with high efficiency anyway. High end devices running big scenes like that will really benefit from them because it's a whole lot of memory transfer savings. Anyone doing things like that will want to be using configurable LoD to support the first-gens while keeping things high quality on newer chips. I would be interested in a simple test that increases poly count frame by frame and graphs the FPS up from 0 to 100k polys. Running one pass textured and the other just colored would be a good way to discriminate between becoming fill-bound and memory or vert-bound. Seeing this data on an MSM7200, Cortex/PVR (Droid) and a snapdragon would be very useful for determining optimization targets. On Jun 20, 4:37 am, Navigateur <[email protected]> wrote: > No I'm not even using draw_texture. I'm comparing using VBOs to just > ordinary Buffers for the vertices (and no draw_texture). My test is > not near the max frame rate for my device. > > On Jun 20, 12:21 am, Miguel Morales <[email protected]> wrote: > > > > > Well, if you look at the talk google gave the developer gave a short > > note about > > it:http://code.google.com/intl/es-ES/events/io/2010/sessions/writing-rea... > > If memory serves me correct, you won't gain much of a speed gain from > > using VBOs as opposed to say draw_texture. > > This is because the FPS is capped at 30FPS for some devices, however I > > can't recall the details. > > > Miguel. > > > On Sat, Jun 19, 2010 at 3:01 PM, Navigateur <[email protected]> > > wrote: > > > I've been trying VBOs (3D) and I've seen no improvement at all on my > > > Motorola Dext over not using VBOs. > > > > I've tried all kinds of configurations, interleaved arrays, > > > bytebuffers instead of floatbuffers, both direct and indirect. > > > > My question is, has anybody got any measured improvement in frames per > > > second by using VBOs instead of exactly the same content without VBOs? > > > > If and only if so, what were your fps results? And can you therefore > > > show me the "proper" way of doing VBOs instead of not? > > > Has anybody else got exactly the same fps with and without VBOs? > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Android Developers" group. > > > To post to this group, send email to [email protected] > > > To unsubscribe from this group, send email to > > > [email protected] > > > For more options, visit this group at > > >http://groups.google.com/group/android-developers?hl=en > > > --http://diastrofunk.com,http://developingthedream.blogspot.com/,http:/..., > > ~Isaiah 55:8-9- Hide quoted text - > > > - Show quoted text - -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
