ATI


ATI’s stand was one of the more ostentatious of the show, certainly the largest of the 3D vendors, but then this is no surprise as they have the most to shout about given the recent unveiling of Radeon 8500 and 7500. They certainly were touting it as well!

There were four PC’s all housing Radeon 8500’s and running the new ATI demos showing off the effects and capabilities of their next generation chip, further 8500 equipped PC’s running games (UT, Serious Sam and Max Payne), a Radeon 8500DV All-In-Wonder, a FireGL 8800 and a few Radeon 7500 equipped PC’s as well.

I managed to grab some time with ATI’s Technical Manager Mark Holmes to talk about various aspects of the new technology and ATI in general. Mark later brought in Jason Mitchell from ATI’s 3D Application Research Group to go over some of the more technical aspects of our discussion. Here what they had to say…

First up is Mark:

We’ve seen the previews of Radeon 8500 on various sites now, but there were some caveats on those because they were pre-release silicon running very early drivers, hence some of the features weren’t yet in operation. Is everything still going to schedule as far as the new version goes?

Well, A13 was always going to be our production silicon and that’s back from the fab.

So there are some boards out there [on the show floor] now?

There are some boards running production silicon out there, yeah.

When did the A13 chips come back then?

Not long ago at all, basically.

And everything’s working as expected?

Yeah, it’s the production silicon and it’s ready to go.

We’ve seen the various chip revision numbering schemes from different manufacturers – A13, going by other schemes, makes it seem as though it’s been through 13 revisions! That’s not the case is it?

No, just three; the production chip was ready on the third version. For the Radeon 7500 we got it done in two, which is pretty incredible.


One of the things we’ve seen on the Radeon 8500DV All-In-Wonder is the ‘AGP4X’ bridge chip for the first time; that kind of paves the way for the return of ‘MAXX’ technology does it not?

Yes it does. There’s nothing currently planned for it though.

MAXX technology is fantastic, but you need to hit the right timeframe from the market perspective, and consumer value for money perspective. We’re not interested in ripping people off, and the initial MAXX came at a time where we felt we could offer performance which was equivalent or better than our competitors at the same sort of price, therefore it had a market – that was a very short lived space though because we can get the same performance from one Radeon chip. If there is a time where we feel we can benefit the consumer by bringing it again then we will do, but it’s not something that we necessarily roadmap. What we want to think is that out future generation of single chip will be at the right time and at the right price with the right level of performance and there will be no need for MAXX.


I’ll have to ask about the age-old sticking point where ATI is concerned and that’s about the quality of ATI’s drivers. What’s the situation there?

I think it’s fair to say that ATI have come under a fair amount of stick for their drivers; but it’s also important to realize that the installed base of ATI users is colossal therefore the voice gets amplified.

What I will say though is that since Radeon we’ve made a lot of changes in the way we write the software and the entire focus on that department and already we’ve seen the benefit from that. We’ve listened in about the unified driver model and we are going down that route, and the quality and performance of the drivers over the past few months have got much better.


Are you increasing the size of the driver team then?

Well, not really the size. The thing with ATI is we’ve got a 15-year history with ten or eleven generations of chips, maybe, and by continually supporting these older chipsets we’ve been diluting our efforts. So, we’ve refocused and we’ve hired some smart guys and we’ve done a lot of work in that area. And now, I’m beginning to see comments along the lines of “Ahh, actually, they aren’t that bad” and the performance is getting better. I tested the latest drop of the 8500 drivers against the initial set, and the difference in performance is startling.

I would have been first to criticize our software department some time ago, I’m now not – I’m firmly behind them.


What’s the strength of the engineering like now, because, obviously, you’ve got what ATI previously had and now ARTX has been there for the past year or so?

Yeah, we’ve got the ARTX team, they represent a design team with a fantastic history; they know how to work together as they’ve worked together for ages.

How many of them were there?

I don’t think there were that many people, sub thirty possibly – just a small nucleus of people. Remember, ARTX were previously just an IP company, so you don’t really need a lot of people to do that. Of course, we did get a CEO in the bargain as well, in the form of Dave Orton.

 

And here’s what Jason had to say:

You’ll have to forgive my definitions because they probably won’t match yours, but so far we’ve seen two forms of AA: Supersampling and multisampling. What are you using?

When you have a Multisample Buffer…

…the Multisample-Buffer? Is this similar to the T-Buffer?

Any Multisample-Buffer should be similar to a T-Buffer.

So, this is the DirectX8 Multisample-Buffer?

Yes. The Multisample-Buffer or T-Buffer are all children of the Accumulation Buffer though.

OK. When we get down to frame buffer organization at the moment you have something like GeForce3 which has 2x2 scaled frame buffer, whereas with the T-Buffer of old you’ve got several different frame buffers for each of the sample points, which are then averaged before display – is that similar to yours?

It’s all a weird definition anyway, because our textures and frame buffer aren’t linear – we swizzle the heck out of our stuff to get better memory access patterns. Once you realize how much we are reordering things the distinction between separate buffers or one big buffer is kind of irrelevant.

It’s basically a hybrid Multisampling and Super-Sampling technique. The real key here is that with a naïve Super-Sampling technique that you would get by simply making a bigger buffer and filtering it down, the distinction is that we actually jitter the sub-samples.

When you think logically about a pixel it’s made up of some number of samples; those samples lie within the area of that pixel and how they are laid out is part of the black art of Anti-Aliasing / signal-processing theory. How to choose a good pattern is what we’ve spent many man-years on, so the jittering algorithms and patterns are something that we protect, but the idea that we are jittering those things is very important. For something that doesn’t have jittering for a certain number of samples we will have better quality; conversely we will get an equivalent quality from fewer samples.


So, obviously your sampling points for 2X can be entirely different for 4X…

They can even vary between pixels, which is very important; so one pixel can have one sample pattern and another pixel can have a different pattern.

It’s all programmable, so if the developer wants a 3 sample Multisample-Buffer we will have a different sampling pattern that will be appropriate to 3 samples than we would for 4 or two. But the important thing is that the patterns can be different for each pixel – dependant on the location on screen we can choose a the best sample pattern from a ‘map’ that is predefined.


Backing up to the type of FSAA implementation featured in Radeon 8500, you say it’s a hybrid between Multi-sampling and Super Sampling – will it cater for texture aliasing?

Yes.

Does it have a ‘Virtual’ Frame buffer – i.e. are the samples combined in the RAMDAC?

That’s not done in the RAMDAC.

Radeon 8500 can go up to 16 samples though, what’s the performance like with that?

There’s definitely going to be a significant performance hit with that! We don’t really expect that to be a common performance scenario for real-time games.

Although we are talking to some people who have applications for near real-time frame generation; some guys are actually doing some things with Horse Races. People are putting these chips on horses so they can track their positions around the tracks, and while they may not have cameras at the race they’ll be able to track their positions and then they will be able to ‘virtually’ film that race. They want to generate these frames fast, and they want to use real-time 3D, but they don’t have to be interactive, so what do they run at? 60Hz. So, it’s not necessarily a gaming solution, but I wouldn’t see it as useless.


What does Radeon 8500 support in terms of Anisotropic filtering?

Basically it’s very similar to what we did in [the original] Radeon. The performance hit of it is really, really small in comparison to Anti-Aliasing.

One thing is that it’s orthogonal; that is to say it can be used on all six textures at once.


And it Radeon 8500 can take the same number of samples as Radeon?

That is correct. Which is a maximum degree of 16:1 anisotropic; now that’s 16 Bilinear samples, so when people talk about 64X they are usually multiplying by four. The level that’s required is determined per-pixel, which is one of the reasons why it’s such a low performance hit, is that for a pixel that doesn’t need that it just gets 2:1 or 1:1 or something.

Can it do Trilinear filtering at the same time?

No. It samples from one map.

This was basically an algorithmic choice. The anisotropic filter kernel by definition is not a square; it’s got a height and a width and we select the mip level based on the small dimension and then sample according to the large dimension of the filter kernel shape. It’s
a way to do anisotropic filtering, there’s no true way to do it – true is generally not a word to use in graphics!

(Laughs) … So we can’t use TRUFORM then?

Fair point! Although there’s no E in TRUFORM!

Talking to some of the other guys on the ATI booth they seemed pretty excited about Radeon 8500’s prospects, especially where SMARTSHADER is concerned and they are in the process of getting it out to developers at the moment; there was even talk of adding support of Pixel Shaders v1.4 into the latest revision of the Lithtech engine. I asked if they felt they would actually get developers to go as far as PS1.4 when there is such a large quantity of GeForce3’s out there and it may be easier for developers just to go to PS1.1 or 1.3; I was told that it fairly easy to utilise PS1.4 as an extra layer of special effects over the other levels, and they do expect that some developers will do so.

One thing that ATI were sore to be missing on their stand was any form of Game Cube representation – Nintendo wouldn’t let them have any at all. It transpires that Nintendo has complete control over the Game Cube, which obviously includes marketing it, however more importantly it means that ATI have no developer support work for it, that’s all routed to Nintendo. They seemed to be quite pleased that they were getting an ATI logo on the Game Cube unit itself, and presumably they’ll be even happier once the royalties start rolling in!