 | | | | | | |
| |
|
In lugnet.cad.dev.mac, Travis Cobbs wrote:
> Just out of curiosity, do you cache pieces once they have been loaded, so they
> only get loaded once? If not, you can speed things up rather enormously by
> doing so.
>
> --Travis Cobbs
Yes,
When loading I make a list of all the unique bricks in the model (colour and
type) these are then cached as OpenGL lists of so when drawing, I then just call
the various OpenGL lists.
For the imperial star destroyer, this means even a 400MHz computer can render
the 3104 bricks in 10 seconds or say 300 bricks per second. For comparison I
also have access to an IBM PC with a genuine PIII running at 450MHz using
Windows 98, MLCAD 3.0 requires 1:21 to load this file and can do a redraw in
about 9 seconds.
I don't wish to enter into a Mac vs PC comparison here, so lets just say both
systems seem to perform similarly.
There is a caveat with respect to speed though;
* Only bricks defined either internally (very fast) or in the "Parts" directory
are cached, inline or file defined bricks (eg 4696.dat, 32531.dat etc) are drawn
"on the fly" this gives quite heavy performance hits in MBC. I noticed this when
recompling Orion's original file (this behavior is deliberate). However as a
consolation, where a brick is subsequnetly added to the parts directory this
will be used in preference to the file listed part, thus giving an automatic
speed increase.
James has now informed me that a Dual 2GHz G5 loads in about 44 seconds and
renders the model in about 5 seconds. Likewise elsewhere on this thread Tom has
also indicated his findings.
What has my interest is two things,
1. As indicated before, load speeds seem to he restriced by the hard disc speed,
as the files are quite small, the critical item is access speed here rather than
transfer speed.
2. Redrawing is far more interesting as all drawing is handled by OpenGL using
OpenGL lists. To draw a part I load the part orientation matrix into OpenGL and
then call the list. Originally I theorised that more recient graphic cards with
OpenGL hardware acceleration would have loaded the lists into the RAM memory
present on the card and then drawn them directly, big speed advantage. But
practice isn't bearing this out since there seems to be very little drawing
speed differences. So I need to figure how Apple handles OpenGL with respect to
lists.
Andrew...
| | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.mac, Andrew Allan wrote:
> Yes,
>
> When loading I make a list of all the unique bricks in the model (colour and
> type) these are then cached as OpenGL lists of so when drawing, I then just call
> the various OpenGL lists.
I have a few comments--based on my experience writing LDView--that I think could
improve your load performance. First of all, I believe what you are saying
above (and a little later in your post) is that you only cache complete bricks.
If this is the case, you should be able to improve your load performance
substantially by caching the decoded version of every single file. Note, this
is the version in your own internal memory format, prior to the file being
compiled into a display list.
LDView does this, and the model takes about 20 seconds to load and compile on a
2.4GHz P4. Only about 10 seconds of that is loading, the rest is compiling the
display list. And the current LDView doesn't do a very good job there, since
after loading the model it flattens it into one single huge list of geometry,
copying the internal versions of every brick as it goes. It then creates one
giant display list for the entire model.
The next version of LDView that I'm working on is a lot more reasonable, doesn't
do any of that, and loads the model in around 6 seconds. Memory usage is rather
remarkably different between the two LDView versions, also. The current one
uses around 600 megs for the model, the next one uses quite a bit less than 100
megs (I don't remember how much, just that it was well under 100 megs).
One other thing can be done to cut down on memory usage, but it's a lot harder.
That is to only have one set of display lists per part, instead of having one
display list for each color of each part. In order to make this work, you have
to split the part into up to at least 3 display lists. One contains all the
color 16 geometry, another contains all the color 24 geometry, and the third
contains all the other geometry.
--Travis Cobbs
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.mac, Andrew Allan wrote:
> 2. Redrawing is far more interesting as all drawing is handled by OpenGL using
> OpenGL lists. To draw a part I load the part orientation matrix into OpenGL and
> then call the list. Originally I theorised that more recient graphic cards with
> OpenGL hardware acceleration would have loaded the lists into the RAM memory
> present on the card and then drawn them directly, big speed advantage. But
> practice isn't bearing this out since there seems to be very little drawing
> speed differences. So I need to figure how Apple handles OpenGL with respect to
> lists.
Your expectation is certainly justified. I don't know what the driver
architecture is on the Mac, but I suspect that the video hardware manufacturers
are responsible for the OpenGL implementation for their own hardware, just like
on the PC. If this is the case, then it is ATI that's responsible for doing the
right thing with the data (or not doing the right thing).
I can say that on the PC side, it appears that at the very least the geometry
encompassed by the display lists gets downloaded into video RAM. If I turn off
conditional edge lines, the model renders reasonbly fast (on the order of 10fps,
IIRC) in my next-gen LDView. (Yes, that's fps, not spf.) The current LDView
has memory issues that slow it down, and I'm not sure what its speed is.
Just out of curiosity, how are you drawing your geometry? On ATI hardware on
the PC, I think vertex arrays are faster than OpenGL 1.0 glVertex calls, even
when encapsulated inside a display list. This doesn't seem to be the case on
nVidia hardware on the PC. (It might also not be the case with recent ATI
drivers.)
--Travis Cobbs
| | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.mac, Travis Cobbs wrote:
> Your expectation is certainly justified. I don't know what the driver
> architecture is on the Mac, but I suspect that the video hardware manufacturers
> are responsible for the OpenGL implementation for their own hardware, just like
> on the PC. If this is the case, then it is ATI that's responsible for doing the
> right thing with the data (or not doing the right thing).
>
> Just out of curiosity, how are you drawing your geometry? On ATI hardware on
> the PC, I think vertex arrays are faster than OpenGL 1.0 glVertex calls, even
> when encapsulated inside a display list. This doesn't seem to be the case on
> nVidia hardware on the PC. (It might also not be the case with recent ATI
> drivers.)
Travis
Having done some experiments and research over the last couple of days, it seems
that to get very fast drawing in OpenGL generally, vertex arrays are necessary.
OpenGL has specific commands such as glBufferDataARB that will explicitly
transfer the info into the graphic card's RAM (only availible on newer cards)
and likewise MacOS X also has commands that give the graphic card DMA access to
the Mac's RAM (again only for newer cards).
Based on some crude and unsophisticated tests there does appear to be hardware
acceleration with respect to drawing in that the cards seem to be able to decode
and render OpenGL commands (for example, a command like gluCylinder draws
noticeably faster than creating the same object from a series of vertex normals
and quads or quad strip). The OpenGL lists themselves seem to be stored in the
client (ie in Computer RAM) and therefore each time a list is called, the
commands contained within the list are passed from the client to the graphic
card so reducing the size of the list does have tangible benfits.
This means two things, I need to learn how to make vertex arrays and I need to
reduce the info being transferred when drawing.
Don,
You mentioned that MacOS X is effectively triple buffered when using double
buffering in OpenGL. This is true, but I'm not sure how MacOS X achieves this. I
believe that it takes a bitmap copy of the display buffer, so there should be
minimal impact on the drawing time. One great thing about this though is when
you move or bring the model window to the foreground, MacOS X uses its buffer
and therefore makes instant screen updates.
Andrew...
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.mac, Andrew Allan wrote:
> Having done some experiments and research over the last couple of days, it seems
> that to get very fast drawing in OpenGL generally, vertex arrays are necessary.
> OpenGL has specific commands such as glBufferDataARB that will explicitly
> transfer the info into the graphic card's RAM (only availible on newer cards)
> and likewise MacOS X also has commands that give the graphic card DMA access to
> the Mac's RAM (again only for newer cards).
Just as a note, I found that Vertex Buffer Objects (VBOs) would crash my ATI
card in Windows when used inside a display list. As far as I can tell, this
isn't supposed to happen. Regular vertex arrays work fine inside a display
list. General consensus on the OpenGL.org discussion forum was that even if it
didn't crash it wouldn't speed things up, since a display list is supposed to
automatically figure out how to draw the geometry as fast as possible.
Also, it really sounds like something is causing your app to be running in
software mode, not hardware. I don't know how OpenGL windows are created in Mac
OS X, but you might want to make sure you aren't requesting any features that
force software rendering. I know on Windows it's relatively easy to request
something not supported by the video hardware, and this causes it to create a
software-rendered OpenGL window, instead of a hardware-rendered one. (I realize
this is a long shot, because Mac OS X is a whole lot easier to program than
Windows, but I thought I'd at least mention it.)
--Travis
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.mac, Travis Cobbs wrote:
> In lugnet.cad.dev.mac, Andrew Allan wrote:
> > Having done some experiments and research over the last couple of days, it seems
> > that to get very fast drawing in OpenGL generally, vertex arrays are necessary.
> > OpenGL has specific commands such as glBufferDataARB that will explicitly
> > transfer the info into the graphic card's RAM (only availible on newer cards)
> > and likewise MacOS X also has commands that give the graphic card DMA access to
> > the Mac's RAM (again only for newer cards).
>
> Just as a note, I found that Vertex Buffer Objects (VBOs) would crash my ATI
> card in Windows when used inside a display list. As far as I can tell, this
> isn't supposed to happen. Regular vertex arrays work fine inside a display
> list. General consensus on the OpenGL.org discussion forum was that even if it
> didn't crash it wouldn't speed things up, since a display list is supposed to
> automatically figure out how to draw the geometry as fast as possible.
>
> Also, it really sounds like something is causing your app to be running in
> software mode, not hardware. I don't know how OpenGL windows are created in Mac
> OS X, but you might want to make sure you aren't requesting any features that
> force software rendering. I know on Windows it's relatively easy to request
> something not supported by the video hardware, and this causes it to create a
> software-rendered OpenGL window, instead of a hardware-rendered one. (I realize
> this is a long shot, because Mac OS X is a whole lot easier to program than
> Windows, but I thought I'd at least mention it.)
Yeah, watch out for that software rendering on the Mac. It sneeks up on
you. I know it can switch you over while your program is running, but I
don't know what causes it to happen other than resizing a window. You
might want to query it about the driver as you build up your display lists
to see if it switches you over to software rendering at some point.
Don
| | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Don Heyse wrote:
> Yeah, watch out for that software rendering on the Mac. It sneeks up on
> you. I know it can switch you over while your program is running, but I
> don't know what causes it to happen other than resizing a window. You
> might want to query it about the driver as you build up your display lists
> to see if it switches you over to software rendering at some point.
Actually, the same thing can happen in Windows if you resize a window too big
(say 1600x1200) on an older video card. However, I'm not sure you can tell that
it has switched to software mode on Windows, because as far as I know it is
still being rendered by the video card's OpenGL driver. I can't see how it
could possibly switch drivers mid-stream because different drivers support
different extensions. That would mean that an extension that you had been told
was present could disappear.
--Travis
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Travis Cobbs wrote:
> In lugnet.cad.dev.mac, Don Heyse wrote:
>
> > Yeah, watch out for that software rendering on the Mac. It sneeks up on
> > you. I know it can switch you over while your program is running, but I
> > don't know what causes it to happen other than resizing a window. You
> > might want to query it about the driver as you build up your display lists
> > to see if it switches you over to software rendering at some point.
>
>
> Actually, the same thing can happen in Windows if you resize a window too big
> (say 1600x1200) on an older video card. However, I'm not sure you can tell that
> it has switched to software mode on Windows, because as far as I know it is
> still being rendered by the video card's OpenGL driver. I can't see how it
> could possibly switch drivers mid-stream because different drivers support
> different extensions. That would mean that an extension that you had been told
> was present could disappear.
>
> --Travis
I think this is what Don is refering to.
Using Don's ldgliteargs to 800x537 on my aging 8 MB VRAM machine so
ldglite would launch using the ATi renderer.
GL_VENDOR ='ATI Technologies Inc.'
GL_RENDERER ='ATi Rage 128 Pro OpenGL Engine'
GL_RGBA_BITS: (8, 8, 8, 8)
GL_DEPTH_BITS = 24
GL_STENCIL_BITS = 8
But if I make my window bigger the Apple software renderer kicks in
GL_VENDOR ='Apple'
GL_RENDERER ='Generic'
GL_RGBA_BITS: (8, 8, 8, 8)
GL_DEPTH_BITS = 32
GL_STENCIL_BITS = 8
If I go back to the original size, the ATi driver takes over again.
One of the odd observations is that the screen redraw takes the same
amount of time regardless of the window size (6 s for my caboose
http://users.rcn.com/cjmasi/caboose_m.dat) but rotating the model is
_much_ smoother when the ATi driver is active. Maybe it is just a window
size thing, but I don't think so. It only takes a few pixels bigger to
get the drivers to switch. You know what the nonprogramer* is
thinking... in ldglite (maybe MBC too) redrawing the model is not
hardware accelerated on my Mac (maybe yours too) even when the hardware
renderer is active.
The GL stuff that is quoted above is taking from my console window.
With MBC the the size of the window does not effect the smoothness of
the rotation nearly as much, but I have no way of know where the
rendering is occuring.
Chris
*That is me if it wasn't clear enough.
| | | | | | | | | | | | | | | | | |
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
| | | | | | |
