| Object graphics under Linux: are they supposed to be that slow? [message #29066] |
Sun, 27 January 2002 15:23  |
Mark Hadfield
Messages: 783
Registered: May 1995
|
Senior Member |
|
|
Hi guys
I have recently been considering a switch to from Windows to Linux for
various reasons that I won't go into here. I have set up a dual-boot system
on my PC and, as of today I have IDL running on both OSes. I'm afraid it's
been a disappointment. I mean, I've used IDLDE on another Unix system so I
wasn't expecting too much of it. (I planned to use IDLWAVE in any case). But
object graphics rendering on the Linux side is unusably slow! For example I
have an object-graphics animation example program that presents a series of
25 x 25 IDLgrSurface objects. It runs along at a tolerable 15 frames per
second on Windows but barely manages 2 frames per second under Linux. Using
software rendering on Linux seems to speed things up slightly, but not much.
The PC has a Pentium 3 800 Mhz processor with an Intel 815 built-in graphics
controller. I run 16 colours, 1280 x 1024 on both OSes. The Windows OS is
Windows 2000 and the Linux one is Redhat 7.2 (kernel 2.4.7-10). The system
has oodles of RAM and disk space.
Is there anything I can do to improve OG performance under Linux?
---
Mark Hadfield
m.hadfield@niwa.co.nz http://katipo.niwa.co.nz/~hadfield
National Institute for Water and Atmospheric Research
|
|
|
|
| Re: Object graphics under Linux: are they supposed to be that slow? [message #29076 is a reply to message #29066] |
Thu, 31 January 2002 18:16  |
Mark Hadfield
Messages: 783
Registered: May 1995
|
Senior Member |
|
|
In the posting that started this thread, I said that IDL was *much*
slower (~ a factor of 10) in an object-graphics animation application
under Linux than under Windows. The various benchmarks presented since
then suggest that IDL for Linux *is* slower at object graphics on this
machine, but not by a factor of 10. So the original result was a
mystery.
Well I've solved it. It was caused by setting the window's RETAIN
property to 2 (system provides backing store). Here are some numbers
(where "-" means this property doesn't affect performance):
OS RENDERER RETAIN Time per frame
Windows 0 - 0.035 s
Windows 1 - 0.043 s
Linux - 1 0.052 s
Linux - 2 0.330 s
BTW the animation is part of my "Motley" library at
http://katipo.niwa.cri.nz/~hadfield/gust/software/idl/
The animation itself is in mgh_example_animate.pro, or you can get
almost the same thing with the command
mgh_new, 'mgh_surface_movie', /EXAMPLE
Anyone wants to try it out is welcome. But I'd be the first to admit
this library is a bit...shall we say...bloatish. (Though not as bad as
Microsoft Office or KDE.) I'd certainly be interested in any bug
reports.
---
Mark Hadfield
m.hadfield@niwa.co.nz http://katipo.niwa.co.nz/~hadfield
National Institute for Water and Atmospheric Research
|
|
|
|
| Re: Object graphics under Linux: are they supposed to be that slow? [message #29098 is a reply to message #29066] |
Thu, 31 January 2002 09:55 |
Rick Towler
Messages: 821
Registered: August 1998
|
Senior Member |
|
|
These threads always seem to lead to the same place. Benchmarking is tricky
business. There are many factors that play into these results most of which
aren't included in the posts. Processor speed. Bus speed. Amount of RAM,
type, and speed. Video driver revision. Video driver settings (vsync,
texture depth, anti-aliasing). OS. OpenGL revision...
The one thing that we can take away from this is that modern video cards are
implementing more openGL features on the silicon and are quickly rendering
the software renderer obsolete. From the posts, Mark and Karl have video
chipsets that are about 3.5 and 2.5 years old respectively and they perform
quite poorly in many of the benchmarks. David's card is newer and does
significantly better vs. the software renderer. My card is one generation
newer still and it does even better.
I think a solid OG benchmark is long overdue. Karl touched on the key
issue, how do you write a general benchmark that produces results useful to
the wide range of IDL OG users? I push polygons all day and want a card
that can drive huge polygon numbers and handle many lights. Someone else
may be doing image processing and could care less about triangle setup and
lighting. What are people doing with OG and what information is key in
helping them make that next hardware purchase?
-Rick
"Karl Schultz" <karl_schultz@yahoo.com> wrote in message
news:e415b359.0201301023.731ceffa@posting.google.com...
> David Fanning <david@dfanning.com> wrote in message
news:<MPG.16c12aa8f85252b59897e1@news.frii.com>...
>> Mark Hadfield (m.hadfield@niwa.co.nz) writes:
>>
>>> The configurations are:
>>>
>>> * IDL 5.5 on Windows 2000 using RENDERER=0 (hardware)
>>> * IDL 5.5 on Windows 2000 using RENDERER=1 (software)
>>> * IDL 5.5 on Linux. This uses RENDERER=0 but, as is obvious from
>>> the DeviceInfo string, the rendering is carried out by the Mesa
>>> software library and does not access any hardware acceleration
>>>
>>> The geometric-mean elapsed time figure provides a rough ranking of the
>>> configurations:
>>>
>>> Windows RENDERER=0 4.58 s
>>> Windows RENDERER=1 3.11 s
>>> Linux 5.55 s
>>
>> Just to give you something to chew over, Mark. Here are
>> my results with IDL 5.5 on Windows 2000, with a 32MB
>> NVIDIA GeForce 2GTS graphics card. Screen resolution
>> is 1280 by 1024 at 32 bits True-Color.
>>
>> Windows RENDERER=0 0.71 s
>> Windows RENDERER=1 1.34 s
>>
>> That graphics card was a couple of hundred bucks, as
>> I recall. :-)
>>
>> Cheers,
>>
>> David
>
> Here's another data point:
>
> PIII 750Mhz Windows NT 4.
> nVidia RIVA TNT2 AGP SSE. 32 bits/pixel
>
> I'd characterize this graphics card as a medium-low range card today.
> The driver uses the AGP port, which is good, and apparently leverages
> the Intel SSE instructions, which is also good.
>
> Windows RENDERER=0 9.41 s
> Windows RENDERER=1 2.72 s
>
> The hardware was MUCH slower at image operations. (GL is generally
> not a good image processor) In fact, I had to disable the image
> STRETCH test because it was taking way too long. The hardware really
> only beat out the software at texture-mapped polygons. I suppose that
> this hardware/driver package was tuned for the Quake-like games :-).
> (I should check for a driver update)
>
> While this is a great benchmark, it may not be representative of
> typical IDL application usage of graphics. For example, I might think
> that this test is a little heavy on images. This program was written
> to monitor the object graphics performance during development and
> later modification and so hits most aspects of object graphics.
> Therefore this program probably isn't the best means to select a card
> or even in deciding between hardware and software rendering. Looking
> at the individual test results can help a bit more if you know what
> sort of things you are drawing a lot.
>
> For example, in this case, removing the image tests would probably
> bring the hardware and software numbers closer together. And that
> would be important to me if my programs didn't use IDLgrImage very
> much.
>
> Karl
> RSI
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
