That's is a good point but it's still likely some kind of gain a the
driver can preprocess the vertices into a format it prefers.
Leigh
On 6/27/2010 6:08 PM, Lance Nanek wrote:
Do VBOs do anything on a device with unified memory? There is no
separate graphics memory on many of these devices, right?
On Jun 20, 9:51 pm, Robert Green<[email protected]> wrote:
Navigateur,
Performance is highly device-dependent. If you're not seeing any
performance differences, it would be helpful if you listed on which
device, what your FPS is with/without VBOs, etc..
It sounds like you're doing it right. I doubt it matters how you
partition the vertex attributes. You can do what you do or do what I
do which is have 3 separate VBOs for them. I would expect no
difference there. If you're not getting a performance improvement
then that's not a bottleneck for your app/game, but it's still
lightening the load on the bus so is a good thing overall. Most games
are fill-bound, not vert-bound.
On Jun 20, 11:46 am, Navigateur<[email protected]> wrote:
What is your approximate experimental fps improvement using exactly
the same content with and without VBOs? I'm testing with 3000 static
verts (GL_STATIC_DRAW) and I'm getting exactly the same frame rate
with and without VBOs, only the set-up time is longer with VBOs. What
are your results with and without? If you're sure there's an
improvement, then what might I be doing wrong with my VBOs? (I'm using
2 VBOs, one for the indices and the other for verts, normals and
texturecoords) And what's your way of doing it?
On Jun 20, 11:50 am, Robert Green<[email protected]> wrote:
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 -- Hide quoted text -
- Show quoted text -
--
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 [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
