[osg-users] Tips for low-end GPUs?
robert.osfield at gmail.com
Wed Nov 4 01:01:26 PST 2009
I'm afriad getting low end performance from low end graphics hardware
is something we have to live with and do our best to work around. In
some cases app developers can recommend to their end users they use
more suitable hardware, I know even in some cases they have bought
graphics hardware for their clients just to avoid issues with
performance and driver quality.
If you are stuck having to support low end hardware then you'll need
to work out what the bottlenecks are and address them accordingly.
The same principles will work for all hardware - are you CPU limited?
GPU limited? Fill limited or transform limited? Lots of questions
and there will be even more answers. Performance optimization is a
*huge* topic covered many times on osg-users so I recommend you do
searches on this this topic.
On Tue, Nov 3, 2009 at 9:38 PM, Cyril Brulebois
<cyril.brulebois at kerlabs.com> wrote:
> I've been very happy developing using OSG but unfortunately, even
> “simple” graphics¹ tend to result in very low performance on Intel
> GPUs (which happen to be very common on wide-spread desktops and
> laptops); while I ACK that well, there are better GPUs available, it'd
> still be nice to be able to somehow run the app I've developed on
> other machines without having to upgrade them, so I've been wondering
> whether there are some guidelines to help getting things “easier” on
> the GPU.
> Random thoughts:
> - dimensions/resolutions (maybe some “native” screen/window size are
> better than others in order to limit resizing overhead)?
> - texture blending modes (how transparency is handled, etc.)?
> - level of detail (there is even osg::LOD for that)?
> - use a tree-like scene-graph (rather than a flat one) to ensure osg
> will do its job properly?
> - checking compositing on X's side (forgot to mention: running Linux
> machines)? acceleration type (EXA et al.)?
> I know there's also the “stats” display that might be of some help,
> and it indeed shows that most of the time is spent during “Draw”.
> I should mention I've tested with both OSG 2.4 and 2.8 on both
> desktops and laptops, and it looks like versions don't have much
> impact on performances, only GPUs do. (To give an idea, I'm at
> 100-150+ FPS with Nvidia, limited to either 60 or 75 via vblanc sync,
> and around 10-15 FPS with Intel.)
> Hardware is like Intel Core 2 Duo, 2 GB RAM. The application isn't
> eating more than a few MB so RAM clearly isn't the bottleneck. A
> single CPU out of 2 seems to be used, around 50%, so that probably
> isn't the bottleneck either.
> So, if you have any rules of thumb to share about how to get a better
> framerate on low-end GPUs, I'll be very pleased to read them. :)
> Cyril Brulebois
> ¹: That is some dozens/hundreds of geometrical forms (boxes, spheres
> with uniform textures), a few of them being transparent somehow,
> only colours/sphere radius/positions of some spheres change; using
> a single camera; and with some texts as overlay, HUD-like.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> -----END PGP SIGNATURE-----
> osg-users mailing list
> osg-users at lists.openscenegraph.org
More information about the osg-users