Video Boards
21 messages in this thread
> NONE of the boards mentioned in the original message in this thread are best
>for 3DS, though they are very good for Windows. 3DS is not a Windows program,
>and does not benefit from a Windows accellerator chipset. Nor is it AutoCAD,
>and so does not benefit from a line-drawing accellerator chip. 3DS is a simple
>SVGA program that uses VGA and SVGA functions only.
I'll have to disagree here. Run two machines side by side, one
with a line draw and BLT engine, and one without, and do a couple
of redraws and real-time camera moves. I'm 110% positive you'll
see that 3DS can benefit immensely from an accelerated card.
> Here's the kicker: nearly ALL of the Windows accellerator chipsets out
>actually SLOW DOWN non-Windows SVGA programs such as 3DS! As a rule of thumb,
>the faster the chip is under Windows, the SLOWER it is for 3DS! For instance,
>the Matrox MGA I (I don't know about the II) is a screamer under Windows,
>especially in 24-bit mode compared to its competition. But it is THE SLOWEST
>board for 3DS (at least until Matrox does a driver that implements real-time
>Gouraud shading for Z-buffer-equipped MGAs, which the last I heard they said
>they weren't gonna do).
Matrox isn't going to write a driver for real-time Gouraud shading
that 3DS will use for rendering because 3DS does all of its rendering
internally and sends the driver scanlines.
>The Weitek Power 9000 (aka the P9000) used in the >Diamond Viper and some
other cards is 2nd-fastest under Windows (fastest of >in 256-color modes), and
second-SLOWEST for 3DS!
Where did you get this assumption?
>All of the S3 chips, >including the vaunted 89C928, also slow down DOS VGA
programs such as 3DS. >Ditto for the IIT AGX XGA chips, the Western Digital
chips, the ATI Mach8 and >Mach32 chips, the Cirrus Logic chips, etc.
Hold your horses, it sounds like you are saying all of these things
slow does 3DS UNDER THE VGA DRIVER. That is probably true, the VGA
support on alot of Windows accelerators isn't all that great. But
all of the boards you mentioned have special drivers for 3DS that
take advantage of their various features.
-Chris
Panacea
Thanks, Chris.
I don't know why this person keeps spreading dis-information about a lack of
3DS performance with a WP9000 processor, but my previous messages have
evidently been ignored.
Thanks for the clear thinking in this matter.
-Alan
Just ignore ignorance…
The most common element in the universe is hydrogen. The second most common
element in the universe is stupidity. (Paraphrasing Harlan Ellison.)
I'm going to print that in type 200 and hang in my office. I swear it! This is
great. <g>
Really.
That's good advice, Gus (as usual).
-Alan
Chris, sorry, but I don't believe that's quite true. Line draw
and BLT engines only work if the program calls them. If the program
just stuffs data into the video buffer, or (worse) calls the VGA INT
10 AH=13 calls to manually set pixels one at a time, no engine in the
world will speed that up. 3DS does not, to the best of my knowledge,
detect and call engines that may be on an SVGA chipset.
As for my "assumption," I got it from hard data in several
comparative reviews in magazines ranging from InfoWorld to Windows
Magazine to PC Magazine and Byte and others, both Ziff-Davis and
non-Ziff-Davis. These chips really do slow down programs which don't
call their engines. And not just by a little bit.
On your "hold your horses" paragraph, you answered your own
question earlier when you said, "3DS does all of its rendering
internally and sends the driver scanlines." Since 3DS doesn't send
bitblocks, nor does it send display lists for drawing lines in bulk
like AutoCAD, there is no way I can see that a driver can make use of
the BLT or line-draw engines. The drivers, so far as I can tell,
merely know how to call the correct graphics modes as requested, and
put pixels on the screen as requested.
Now, for AutoCAD, I know these drivers can give tremendous
benefits, primarily because of display lists accessing line-draw
engines. But 3DS just doesn't work that way. I wish it did.
You might be interested to know that Chris, the fellow you're
lecturing on graphics boards and drivers, is one of the handfull of
programmers in this country who writes driver software for AutoCAD,
3D Studio, and Windows. He knows his stuff, big time. At this
point, you'll save further embarassment by retreating.
Well said, Evan. I hope this person takes your advice…
-Alan
Some technical data is needed here. First of all, no board "slows
down" DOS access. Assuming no speed increase equals 0 gain. There
can't be a negative gain. For a 0 gain I would consider an 8 bit
(memory access) bank switched VGA (like the original IBM VGA) running
on a 6 MHz bus. Anything better than that ought to have a greater
than zero gain. Including "all" of the SVGA boards out there. A
"dumb" frame buffer (non CPU assisted, accelerated board) works as a
memory area where the application sends preprocessed image (raster)
information directly to it's image buffer. The access method will
determine the speed. All of these cards are at least 16 bits and able
to operate in bus speed of at least 8Mhz. That's already a 2.6 gain.
As most of these accelerated boards are 32 bits and operate at the
CPU data bus speed (60 Mhz in my case) that represents a 40 gain. And
that's without "any" CPU assisted acceleration. There are other
factors that makes this gain even greater. "Normal" VGA boards have a
tiny 64k memory window where data has to be sent in blocks and banks
of 64k memory switched back and forth. 32 bit SVGA boards have a 1,
or 2 (or whatever it may be) megabyte window. Both Vibrant and
Panacea drivers access those buffers directly and in 32 bit protected
mode. That will give a gain of 3 on top of the already gain of 40
(120 total).
Your statement are unfounded and based on invalid data. PC Magazine
(or any other rag you mentioned) isn't, and won't ever be, the right
source of information for this kind of research. They are based on
how the average unsophisticated user ( that's stupid in plain English)
uses his or her computer and how the average business application (
that's stupid applications in plain English) perform under those
circumstances. Both totally unrelated and biased for any valid use in
this [3DS] context.
Be better prepared before such bold statements next time.
>>the average business application ( that's stupid applications in plain
English)<<
Yeah! I was going to say that a couple messages ago (Cyrix M1
thread), but had a horrible attack of politeness <g>. I'm not
alone… <g>
Thanks, Gus.
Just wanted to say to all that I think the primary reason we are
taking issue with these statements is that we consider this forum a
*great* place to get good, sound advice regarding software *and*
hardware purchases, especially with regards to their performance with
3D Studio, and other associated packages. I would hate to see someone
skipping over a perfectly good (and affordable) set-up for their 3DS
system because of dis-information gathered here on ASOFT.
So it's nothing personal. We (folks like Gus, Chris, myself and many
others) just want to keep hard-to-argue technical issues like this
one straight.
The best situations, IMHO, are when *everyone* learns from this
forum.
I've learned alot over the years, and thank everyone for that.
-Alan Iglesias
I have to agree but I think that gentle tact with someone who doesn't
know the players is in order. This is really important because we
don't want ASOFT to get a reputation as slamming people who aren't as
knowlegeable as the Gang of 10, not that I'm pointing any fingers and
especially not at you. Typically you show a fair amount of diplomacy.
Just something for all to keep in mind. Its one thing for "us" to go
at it quite another for the occasional visitor, no matter how
misguided.
I also think that we might want to take it easy on the occasional
visitor. I think we should welcome there input. We could be
constructive in correcting those that are mistaken. There is a
positive side to the heated discussions among the regulars. I
personally get many questions answered without even asking them.
Scott – I agree there IS a positive side to the heated discussions
among the regulars and I also feel that these forays by the
occasional visitor can be just as illuminating. Otherwise the forum
becomes too closed in its perspective. Its also a matter of common
decency to listen to other's views as long as they're not personally
offensive.
I also don't find derogatory remarks concerning an individuals
sources compelling. The facts as they are known speak for themselves.
I also don't relate to the tendency for three or four people to jump
on the bandwagon. Kinda like mob rule. History has proven that the
individual can be correct when the majority believes otherwise, and
vice versa. Everyone deserves a chance to express their views or
understanding without concern for being chastised. Even if they
express those opinions less than humbly. Unless of course its one of
us regulars, in which case, all's fair I guess. <G>
John:
Let's not get opinions and fact mixed up. This thread related to fact – the
performance of graphics accelerators with 3DS. Granted, it is a complex
subject, but it is based on fact, not opinion.
Evan
Whose facts Evan, Chris's, whom I also acknowledge as an expert in his
field, or PC Magazine's facts or Marion's interpretation of the
facts? I used the word opinion to imply each persons "facts".
Opinions, in theory, are based on fact. I have read more than a few
articles which while factual, left out important details which
created an erroneous conclusion on the part of the reader. Maybe
Marion has been sloppy with his details, but on the other hand it is
possible that he believes he is being factual based on what he has
read. I get your point, but it implies that my statement should have
read "I think everyone should be able to express their own facts",
which is a contradiction to the meaning of the word. And I did say
that I thought the facts should stand for themselves.
And while we're on the subject of facts maybe you'd be willing to
clarify a point if you know the "facts". In a networking environment
with file transfers and disk access etc. which is going to manage the
traffic faster a 386/40 or a 486/33 all else being equal? (No
applications running in the background, same drives RAM etc. )
I'm very interested to hear your answer especially as you place such
high regard for the facts. <g>
John:
I intentionally left that last message short. I could have written a 10,000
character message on the issue. And I'm trying to avoid that now.
The problem is that the facts are all rather low level. For example,
we know that VGA boards use 64K memory mapped banks with I/O mapped
control registers to get to the frame buffer. And we know that P9000
boards us direct memory mapped frame buffers. We also know that I/O
operations on X86 processors are slow compared to memory operations.
And we know that the graphics drivers for 3DS are written by
independent developers, who have the choice of implementing them any
way they like.
These are all facts. Beyond this, it's all interpretation. A person
who is not intimate with *all* the relavent facts might make an
incorrect interpretation. The problem is that magazines such as PC
present a limited set of facts, and relate their interpretations
based on them. Readers, such as Marion, tend to go with these
interpretations, even if they were intended to be only narrowly
construed.
Regarding the performance of a 386/40 versus a 486/33 as a network server –
there are too many factors to make a flat statement. But, to generalize, the
system will be I/O bound by the network (at 10 Mb/s) and the hard disk.
Further, the ISA bus will be a factor. All things being the same, I'd *guess*
that the higher raw clock rate of the 386/40 would be overcome by the improved
pipelining of the 486/33, and both would be ovecome by the limited speed of the
ISA bus. In the end, I suppose it wouldn't make much difference which you use.
Of course, I could be wrong, and probably am.
Evan
Evan –
>>Readers, such as Marion, tend to go with these interpretations, even
if they were intended to be only narrowly contstrued. <<
I agree, and that may have been the problem. Also, in my comments regarding the
handling of Marion, they weren't directed at you per se. Just the appearances
of the overall situation.
So enough said, thanks for the explanation.
-JE
Evan,
PMJI, but there was one point in this thread that you made that I felt
compelled to expound upon. I'm NOT disagreeing, just adding additional
info….
>> Regarding the performance of a 386/40 versus a 486/33 as a network server –
there are too many factors to make a flat statement. <<
DEFINITELY, and one _major_ factor will be the NOS.
In Lantastic (or other peer-to-peer) the network can have a tendency
to very processor bound. The major reason for this is the foreground
task, and it's impact on the NOS in the background. Want proof, load
an AutoCAD drawing on a Lantastic print/plot server and watch your
spool times go through the roof!
However, on a 32-bit NOS (such as Novell), you can't get fast enough I/O. We
have several 486/33 Novell servers (serving AutoCAD networks) that run 5% to
10% on _processor_ utilization, and at the same time are 90% to 100% on I/O and
packet exchange (disk, bus, and ethernet card!).
Just wanted to add this for those following the thread!
Chuck
You're amazing Gus. Great message.
Dave Mennenoh