R520 article typos

[Dave Baumann]

Please note any errors in the R520 article here:

 

[Geo]

Arch drawing doesn't come up (box with red x in it instead) when you click to enlarge.

use of a new extension to DirectX know[n] as Render to Vertex Buffer.

Shader ALU's by breaking the tasks down into smaller, chunks that can be interleaved more effectively.

extraneous comma alert.

a more optimal method of High Dynamic Range blending, something that ATI's part have not been able to to previously.

ATI's engineers state that they have place[d] a lot of emphasis on being able to run with high quality options on.

 

[Joe DeFuria]

One note on editing:

The release dates for the 1800 XL and 1800 XT are reversed on the chart.

http://www.beyond3d.com/reviews/ati/r520/index.php?p=07

(The chart shows the XT coming out now, and the XL on Nov 5).

 

[Rodéric]

page 6:
"the costs associated with the64-bit modes" - missing space

 

[thana]

page 7:
in the headings of the comparison table there is a "X13000"

 

[Dave Baumann]

Thanks guys, all these have been updated.

 

[Geo]

Btw, not that you asked, but I'll pass on a writing tip that my wife (who has been published various places) taught me with a ball-peen hammer covered in silk. At least for formal writing --I'm just as bad at it as ever in this kind of writing. I have to go back and edit for it.

Basically, "90% of the 'that' in the world are wasted space". Not all of course --see my first sentence in this post. But check it out for yourself and I think you'll find it true.

 

[Mintmaster]

I noticed a strange sentence when reading:

in fact, RV515 went relatively smoothly, with no unexpected issues, so it is one of the chips that to primarily driving the technology announcements and release on.

I assume 'to' should be 'is' and 'on' should be removed.

BTW, it's great to see that you're striving for perfection!

 

[Reverend]

BTW, it's great to see that you're striving for perfection!

You're talking about Dave and his ambitions regarding... what?

Or are you talking about ATI?

Whichever, sorry, "perfection" = not possible.

 

[Geo]

BTW, it's great to see that you're striving for perfection!

Well, I'd think he's striving to have a place to let us compulsive types nitpick without filling the main thread with it. Which is fine, and works out for all involved. In fact, I hope it sets the standard from now on. He can drop in once in awhile and rescue anything he finds of worth. I rather doubt he's hitting the refresh every few seconds on this thread.

 

[Pete]

Yo, Dave "Perfectey" Baumann, you're missing a "/$549" MSRP for the 512MB XT on p.7.



And, yes, he's shunting the nitpicks to a separate thread so as to leave the article discussion thread free to concentrate on more technical details (as well as my silly Qs). So, while he may be striving (however casually) toward perfection, this is more heading off the nitpickers at the comma splice.

 

[Geo]

But it is a wonderful and sympathetic solution. It recognizes the essential helplessness we have to our compulsion and allows us to engage in it guilt-free, while giving him the chance to stop by when he likes to see if there is anything here he finds worth fixing. :smile:

I only stress this point because I'd like to see it continue for major articles in the future.

 

[Pete]

I agree with all my quads, geo.

Dave, last sentence of p.4, perhaps insert the following colored words:

For the parts in the R5xx series that have three times the number of shader pipelines to ROP's the batch sizes are 48 (4x12) pixels large, so the efficiency drops a little.

 

[Fodder]

Misplaced comma, third paragraph from bottom, page 8.

passing the data between the boards via the chipset does have performance, limitations especially when the chipset uses a single x16 lane implementation split into two x8 configurations

 

[Geo]

Part deux

Note: Adaptive AA has presnetly been qualified by ATI on the Radeon X1000 series, however all boards from 9500 up to X850 have the capabilities for performance Adative AA and ATI state that they are going to go back and qualify the feature for use on all these products.

Fill rates page near the bottom, the texture percentage differences table misidentifies X1800XL as X1800XT.

Errm, isn't it gl_EXT_reme that is Humus benchie?

PowerVR's VillageMark benchmark, which draws a scene with very high overdraw levels, does display a fairly considerable improvement on X1800 XL, but exactly how much of this difference is due to the different vertex rates is difficulat to say.

For the tests without branching we see that the X[1]800 XL is performing very close to it theoretical difference to the X800 XT in the tests, even exceeding it in the VS2.0 test,

Our Doom 3 "Turkey Baster" test uses and extended sequence from the Alpha Labs 1

The Video decode section seems to be combining X1800 graphs with G70 narrative and tables.

so this makes the capability of supporting branching in the Pixel Shader much greater - how much this will spur developer on to utilise the capability will have to be seen yet.

I can think of several ways to fix that, but "dealer's choice" as it were.

 

[Pete]

Pp. 15-16:

X1800 XT % Faster than X800 XT

Should be XL. This happens in all the "% faster than" tables on those two pages.

P. 23: The Normal vs. HDR graph still has series names from the previous SM2.0 vs. 3.0 graph.

P. 28:

In our Far Cry test we see that using both of these IQ features together, naturally, produces a greater performance hit, however the reduction is greater than the sum of enabling the features individually. In this case we are getting a greater performance hit sometimes because the transparencies are occurring on textures which are now being over sampled for FSAA purposes and they are also having 16x filtering applied to them as well, some of which would have had under the Angle Dependant filtering.

IMO:

In our Far Cry test we see that using both of these IQ features together naturally produces a greater performance hit than either individually. However, in some cases the reduction is greater than the sum of enabling the features individually. We see this because the transparencies are occurring on textures which are now both being over sampled for Adaptive FSAA purposes and having extra 16x filtering applied to them (some of which would have been reduced under the Angle Dependent filtering).

P. 31:

Here' we'll....

Nice work, Dave. Glad you survived to tell the tale.

 

[Hyp-X]

The "If you wish to comment on this article please do so here." link seems to point to a non-existing thread.

Edit: It's working now

 

[Hyp-X]

http://www.beyond3d.com/reviews/ati/r520/index2.php

The size comparsion image thumbnail links to the wrong image.
(That is the second small thumbnail above "ATI Radeon X1800 XT & X850 XT PE" at the middle of the page")

 

[thana]

page 11, second paragraph below the board pictures:

"The memory layout of the XL board is against very similar to the XT"

 

[thana]

page 20, below "Far Cry, 4x FSAA & 8x AF":

Comparing the gains the the X1800 XL has in relation to the X800 XT again highlights the efficiency gains R520 has over its previous generations,

instead of the second (red colored) "gains" IMO "improvements" sounds a bit better.


page 25, last sentence:

Curiously, the result at 1600x1200 for the X1800 XT here is actually slower than at 4x FSAA, despite there being more FSAA and texture samples being calculated.

you probably meant "faster" oder "higher" here, and the second "being" looks superfluous to me.


page 26, last paragraph:

When taking all of these performances into account we can see that 4x FSAA certainly has improved with these new memory adjustments, but what sticks out is that 6x FSAA on the XT is actually faster than 4x was in the first place, which logically should be the case as 6x FSAA will always be requiring more more samples to be calculated and more bandwidth used - ...

should be the case => should be the opposite (?)