 | | | | | |
One thing I've forgotten to mention in my previous replies is that it's really
unfair to compare the performance of an editor (MBC) with a viewer (LDView),
even if both are running on the same machine. A viewer doesn't have to worry
about adding, removing, and moving pieces on the fly, so in theory can make
optimizations that can't be made in an editor.
As a consequence, despite how my previous posts may have appeared, I'm really
not trying to compare the performance between the two. However, having said
that, many optimizations are appropriate to both an editor and a viewer.
--Travis Cobbs
| | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.mac, Travis Cobbs wrote:
> One thing I've forgotten to mention in my previous replies is that it's really
> unfair to compare the performance of an editor (MBC) with a viewer (LDView),
> even if both are running on the same machine. A viewer doesn't have to worry
> about adding, removing, and moving pieces on the fly, so in theory can make
> optimizations that can't be made in an editor.
>
> As a consequence, despite how my previous posts may have appeared, I'm really
> not trying to compare the performance between the two. However, having said
> that, many optimizations are appropriate to both an editor and a viewer.
Since we seem to be talking about performance measurements, what do
you think about comparing the the current yardstick: l3lab? On my fairly
old 500Mhz PC with a TNT video card l3lab prints this for stats.
Timing:
Load: 1222 ms
Draw: 8442 ms
The load time seems pretty zippy compared to what we're hearing in this
thread. Is that because creating display lists in video memory is really
slow? The l3lab file loading source code is available. Maybe there's
an idea or two in there.
Travis, can you see if l3lab is any faster on your more modern hardware?
Don
| | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.mac, Don Heyse wrote:
> In lugnet.cad.dev.mac, Travis Cobbs wrote:
> > One thing I've forgotten to mention in my previous replies is that it's really
> > unfair to compare the performance of an editor (MBC) with a viewer (LDView),
> > even if both are running on the same machine. A viewer doesn't have to worry
> > about adding, removing, and moving pieces on the fly, so in theory can make
> > optimizations that can't be made in an editor.
> >
> > As a consequence, despite how my previous posts may have appeared, I'm really
> > not trying to compare the performance between the two. However, having said
> > that, many optimizations are appropriate to both an editor and a viewer.
>
> Since we seem to be talking about performance measurements, what do
> you think about comparing the the current yardstick: l3lab? On my fairly
> old 500Mhz PC with a TNT video card l3lab prints this for stats.
>
> Timing:
> Load: 1222 ms
> Draw: 8442 ms
>
> The load time seems pretty zippy compared to what we're hearing in this
> thread. Is that because creating display lists in video memory is really
> slow? The l3lab file loading source code is available. Maybe there's
> an idea or two in there.
>
> Travis, can you see if l3lab is any faster on your more modern hardware?
On my laptop with a Pentium-M 1.4GHz, 512MB RAM, ATI Mobility Radeon 9000:
Timing:
Load: 3325 ms
Draw: 3164 ms
On my desktop with a P4 3Ghz, 1GB DDR400 RAM, ATI Radeon 9800 Pro 128MB:
Timing:
Load: 2062 ms
Draw: 1204 ms
-Orion
| | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Orion Pobursky wrote:
> In lugnet.cad.dev.mac, Don Heyse wrote:
> > Since we seem to be talking about performance measurements, what do
> > you think about comparing the the current yardstick: l3lab? On my fairly
> > old 500Mhz PC with a TNT video card l3lab prints this for stats.
> >
> > Timing:
> > Load: 1222 ms
> > Draw: 8442 ms
>
>
> On my laptop with a Pentium-M 1.4GHz, 512MB RAM, ATI Mobility Radeon 9000:
> Timing:
> Load: 3325 ms
> Draw: 3164 ms
>
> On my desktop with a P4 3Ghz, 1GB DDR400 RAM, ATI Radeon 9800 Pro 128MB:
> Timing:
> Load: 2062 ms
> Draw: 1204 ms
Well, for what it's worth, here are my numbers on a P4 2.4GHz, ATI 9700 Pro
128MB:
Load: 3437 ms
Draw: 1907 ms
It's worth noting that if I load the file a second time, the load portion drops
to 313 ms, so the only way to be sure that disk cache isn't playing havoc with
your numbers is to reboot and do it first thing.
--Travis Cobbs
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.mac, Travis Cobbs wrote:
> In lugnet.cad.dev.mac, Orion Pobursky wrote:
> > In lugnet.cad.dev.mac, Don Heyse wrote:
> > > Since we seem to be talking about performance measurements, what do
> > > you think about comparing the the current yardstick: l3lab? On my fairly
> > > old 500Mhz PC with a TNT video card l3lab prints this for stats.
> > >
> > > Timing:
> > > Load: 1222 ms
> > > Draw: 8442 ms
> >
> >
> > On my laptop with a Pentium-M 1.4GHz, 512MB RAM, ATI Mobility Radeon 9000:
> > Timing:
> > Load: 3325 ms
> > Draw: 3164 ms
> >
> > On my desktop with a P4 3Ghz, 1GB DDR400 RAM, ATI Radeon 9800 Pro 128MB:
> > Timing:
> > Load: 2062 ms
> > Draw: 1204 ms
>
> Well, for what it's worth, here are my numbers on a P4 2.4GHz, ATI 9700 Pro
> 128MB:
>
> Load: 3437 ms
> Draw: 1907 ms
>
> It's worth noting that if I load the file a second time, the load
> portion drops to 313 ms, so the only way to be sure that disk cache
> isn't playing havoc with your numbers is to reboot and do it first
> thing.
Ah, that explains my mysteriously low load time. I did the measurement
on the 2nd try.
So, I'd say anything drawing in the fps range is certainly getting some
benefit from the opengl acceleration.
Don
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.mac, Travis Cobbs wrote:
> One thing I've forgotten to mention in my previous replies is that it's really
> unfair to compare the performance of an editor (MBC) with a viewer (LDView),
> even if both are running on the same machine. A viewer doesn't have to worry
> about adding, removing, and moving pieces on the fly, so in theory can make
> optimizations that can't be made in an editor.
>
> As a consequence, despite how my previous posts may have appeared, I'm really
> not trying to compare the performance between the two. However, having said
> that, many optimizations are appropriate to both an editor and a viewer.
>
> --Travis Cobbs
Travis,
Generally I have to agree with you:
According to the Apple literature non-OpenGL aware graphics cars (such as the
Rage128) gain significant benefit from vertex arrays but with OpenGL aware
graphic cards (such as the 9000Pro ) this isn't necessary. My internally defined
parts don't use vertex arrays.
All OpenGL drawing calls are to GL_QUADS, GL_LINES and GL_TRIANGLES. To minimise
the number of OpenGL calls in the list I internally resolve all vertexes into
thier final coordinates then call OpenGL with these coordinates.
I agree that the most efficient way of displaying a model is to make 1 big list
and fire it at OpenGL but as you say, if you're going to edit the model, then
this just isn't practical.
I elected to define each brick with its colour in order to minimise as much as
possible the OpenGL calls during rendering. It would be necessary to define each
colour in a different list.
Likewise, I've read that calling OpenGL lists from within an OpenGL list isn't
as efficient as drawing the object directly, so therefore I don't cull and
define primitives as lists during parsing. This means that each time a primitive
is referenced (which is not internally defined) it is re-accessed from disk and
reparsed. If I was to pre-cache the primitives internally in my application,
then it is likely that I could shorten loading times significantly.
To be honest, I'm not overly concerned with the load times, they should be
shortened but this is a one-time event, the inconvienence is minimal.
Actually most of my view is in the rendering where faster systems have very
little real advantage over slower ones. When I've run performance measuring
tools on the application during rendering, OpenGL accounts for about +95% of the
system usage. Based on this, calling the bricks, loading and defining the
matricies then calling the display list isn't much of a resource hog.
Right now, I genuinly wonder if I'm getting hardware acceleration in OpenGL.
Andrew...
| | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Andrew Allan wrote:
> Right now, I genuinly wonder if I'm getting hardware acceleration in OpenGL.
Maybe you're running into one of those weird oddities of the Apple opengl
drivers. For example rendering to the GL_FRONT buffer really renders to
a hidden back buffer. There are times where this setup causes you to use
triple buffering, which eats up lots of video memory. Once you're out
of video memory your display lists have to get swapped in from system RAM.
You find out this stuff by monitoring the Apple opengl mailing list...
Don
| | | | | | |
