#Graphic Card Review
5 messages in this thread
Ken…
I disagree, speed tests are important. I agree that if you are only doing a
series of commands and timing them overall, that does not show much. But if
your benchmark breaks down the test by entity type, % of screen size, and a
good curve on the results then you might find out something.
With GRPERF I found out that many ADI drivers fall all over themselves with
0 width polylines. If I had not done the test then I would not have found
this out and gotten programmers to fix it. I asked one programmer of a
company that did terrible on 0 width plines how could they put out an ADI
driver that did so badly, his response was that his job was programming not
drawing. Lame response. But it points out that some companys never really
test their drivers before shipping.
I've also found that if a company does test it's drivers, it usually uses
the San Diego Benchmark test. A major company spent two months testing
their new card against the market using BM-ACAD. What a waste.
I agree that some cards will not benchmark well. But AutoCAD users, ADI
developers and magazine editors <grin> all want speed tests. My two tests
are the result of my experience with ADI drivers and 6 months of
development between me and TonyT. I feel they do a pretty good job of
testing ADI drivers.
Robert
Ahem….
Robert,
I agree that benchmarks such as GRPERF are wonderful to diagnose peformance
of drivers and cards. Your 0 width polyline example is a good one. As you
noted, you would not have found this problem without your test. Doesn't this
reflect how little the user notices such things? I don't view a graphics
card a something that *helps* to get things done, but rather something that
gets in the way. If I have to wait for *anything* during the design phase,
the computer is getting in the way. A good board is one that doesn't cause
me to wait on it. So, if the board draws 0 width plines slow, thats ok, as
long as it gets finished before I'm ready.
The biggest problem I have with benchmarks is they hurt a productive tool
which might be 'fast enough' while helping a faster, but poorly implemented
product.
I'm rather PO'ed at one board maker that promised a slow menu system on a
beta I tested was already fixed. Later, I discovered they failed to fix
the shipping software. I would have burned them on the review, but now its
too late. So, an end user might decide I'm a real jerk because I didn't
mention the slow menu system. Or worse. Does this happen to you or did they
just single me out….<g>
Ken <getting a *little* smarter every day> ///
Ken…
For 0 width plines, some guys' ADIs were way too slow to be acceptable.
Until I pointed out the problem they did not know that it existed. Only by
getting performance information could the manufacturer go back and improve
his work.
I disagree–the drafter knows when his driver is slow. His only choice
after purchase is to live with it. I agree that if the board finishes a
command before you do, that speed is acceptable. Benchmarks are as much for
the board manufacturer as the CAD draftsman.
Cadalyst has a policy of only reviewing shipping products. Otherwise you
can get caught by the difference between beta and shipping product. I've
had a few attempts to end run the reviewer myself. Not fun.
Robert
Robert,
One point on which I believe we both agree. If the draftsman perceives the
card as slow, its slow. If he's happy, well….<g>
Ken /// CAD Masters