The best video card ever....

[BenSkywalker]

Hope the seller decides to sell it to you for your bid price Rollo.

Larry-

If you are familiar with signal theory then why are we even having this discussion? Full Scene Anti Aliasing. MSAA is not full scene or even close to it. Comparing bilinear filtering to MSAA bilinear is a lot closer to a full scene implementation then MSAA, and not too many people would try to put forth the bilinear passes for FSAA. All of the sites that use FSAA for MSAA are using the term improperly.

Now if you want to say that MSAA is FSAA then it is akin to saying nVidia's 6800 parts have a perfectly working video processor as they do accelerate numerous elements of video processing- on a percentage basis they accelerate more of the video processing then MSAA filters out aliasing.

So, according that, ATI is limited in their capability to implement support for the F-buffer and expose it via DirectX, because MS controls the DirectX HLSL compilier. Whereas ATI controls the GLSL compilier implementation, and will expose it that way.

It certainly doesn't sound like it is defective in hardware, which was your original assertion.

If it was an issue with MS's compiler then you would be able to utilize it through assembly which you can't. The quote you pulled up from ATi is PR spin control.

Well, why don't you directly take that up with Anand then - if he is incorrect in his usage?

I have. Anand is by no means an expert on 3D technology. I also have taken the issue up with the guys over at B3D and I don't recall them ever disagreeing with the fact that calling MSAA FSAA is incorrect(but most people mistakenly call it that so it remains).

I personally think that you have your terminology slightly mistaken, as FSAA based on MSAA and AF, does result in every pixels on the screen being anti-aliased in some way, although perhaps not offering as high a quality output as SSAA would, but of course that has 4x the memory-bandwidth cost compared to no AA.

No, ATi's implementation does not apply AA to every pixel on screen even when using MSAA and AF. Their adaptive AF fails to filter large portions of the screen properly(as does nVidia's current solution) but ignoring that MSAA+AF does nothing to filter alpha textures use to simulate geometry. Go ahead and check it yourself.

In other words, you stated your question wrong in the first place. Btw, why are you mentioning the 8500 and 9700, your question/assertion was that FSAA on the 9800 hardware was non-functional.

The hardware is non functional on R3x0 hardware. I can't say if the R9700 states it has FSAA on the box as I don't have one around I can check.

Ok, so not only is TH and AnandTech wrong in their usage of terminology, but also Beyond3D? Don't you think that the fact that three of the biggest sites out there disgree with your personal usage of the term, means something?

No, I don't think it means anything at all. When I first picked up a R9500Pro I was repeatedly griping about the seriously screwed up AF filtering and the amount of aliasing it introduced. All of the sites you mentioned talked about how much more detail the AF of the R3x0 core added to the scene compared to the rest of the current parts. I got my R9800Pro and was still going off about how poor the AF was on the R3x0 core and again those same three sites you listed off denied it was a problem and there was nothing wrong with it- it was in fact superior to the other offerings. Then 3D Center wrote an article about the low quality blending accuracy that ATi uses on their filtering blending operations and demonstrated how this introduced noticeable aliasing and reduced quality compared to the competition. If everyone simply decided that they were mistaken because Anand, Tom and Dave say something different then numerous issues wouldn't ever be figured out.

 

[VirtualLarry]

Originally posted by: BenSkywalker
Hope the seller decides to sell it to you for your bid price Rollo.
Larry-
If you are familiar with signal theory then why are we even having this discussion?

Good question.

Originally posted by: BenSkywalker
Full Scene Anti Aliasing. MSAA is not full scene or even close to it.

When MSAA is used in combination with AF, is not every single output pixel displayed on the screen, filtered? How is that not "full scene"? MSAA applied to the edges, AF applied to the insides of the textured polys.

Originally posted by: BenSkywalker
All of the sites that use FSAA for MSAA are using the term improperly.

Here's an idea Ben, rather than use my comments in Rollo's threads to attempt to "prove your point", why dont you simply find a good, technically-oriented lawyer, and file suit against all of the major 3D video-accelerator hardware mfg's, for false/fraudulent advertising. Debating it with me is obviously a waste of your time, right? Go make some money off of it, if everyone but you is so incorrect about things.

Originally posted by: BenSkywalker
Now if you want to say that MSAA is FSAA then it is akin to saying nVidia's 6800 parts have a perfectly working video processor as they do accelerate numerous elements of video processing- on a percentage basis they accelerate more of the video processing then MSAA filters out aliasing.

That's funny, everyone so far, has been able to benchmark exactly *zero* acceleration from the PVP on the AGP 6800 cards. Considering that NV's drivers are "unified", and verifiable levels of acceleration do exist on the 6600 cards, that does seem a little... strange, does it not?

Originally posted by: BenSkywalker

So, according that, ATI is limited in their capability to implement support for the F-buffer and expose it via DirectX, because MS controls the DirectX HLSL compilier. Whereas ATI controls the GLSL compilier implementation, and will expose it that way.

It certainly doesn't sound like it is defective in hardware, which was your original assertion.

If it was an issue with MS's compiler then you would be able to utilize it through assembly which you can't. The quote you pulled up from ATi is PR spin control.

I was assuming of course, that they were not outright lying. Are you saying that they were? I haven't been able to find any example demos written using GLSL, since it's fairly new, that would be able to take advantage of ATI's F-buffer implementation. Have you seen any? I was giving ATI the benefit of the doubt here, since I hadn't seen any other references to a non-functional (in hardware) F-buffer, and your assertion was the first that I had heard in the matter, and those comments from the ATI rep make a certain amount of sense; remember, ATI had only recently enabled Geometry Instancing in their parts too, using a DirectX workaround hack to enable it, since they aren't "allowed" to directly expose it, due to the constraints on the API that MS controls. I assumed that the same was happening here with the F-buffer. I could well be wrong - only a test example could prove it one way or another, I guess.

Originally posted by: BenSkywalker

Well, why don't you directly take that up with Anand then - if he is incorrect in his usage?

I have. Anand is by no means an expert on 3D technology. I also have taken the issue up with the guys over at B3D and I don't recall them ever disagreeing with the fact that calling MSAA FSAA is incorrect(but most people mistakenly call it that so it remains).

Alone, it's not FSAA, but when combined with AF, it is. One filters poly edges, one filters inside textured polys. I would assume that if the drivers allow you to enable MSAA, that they would not allow you to disable AF, if they labeled it "FSAA".

Originally posted by: BenSkywalker
No, ATi's implementation does not apply AA to every pixel on screen even when using MSAA and AF. Their adaptive AF fails to filter large portions of the screen properly(as does nVidia's current solution) but ignoring that MSAA+AF does nothing to filter alpha textures use to simulate geometry. Go ahead and check it yourself.

Have you considered that the reason that ATI's MSAA + AF implementation of FSAA is visually less appealing than NV's, might not have to do with the use of MSAA specifically, but rather because of the lower precision bits used when performing the filtering? In other words, due to lack of precision, the output quality suffers, and there is still some apparent visual aliasing. That doesn't mean that it doesn't work at all, only that their quality of implementation needs improving. About the alpha thing. I also found this link , which appears to show that the issue isn't the hardware, but the DirectX driver implementation, since the OpenGL one appears to function properly. At least on a 9700.

Originally posted by: BenSkywalker

In other words, you stated your question wrong in the first place. Btw, why are you mentioning the 8500 and 9700, your question/assertion was that FSAA on the 9800 hardware was non-functional.

The hardware is non functional on R3x0 hardware. I can't say if the R9700 states it has FSAA on the box as I don't have one around I can check.

See, I still don't see how you can make that assertion - if the hardware itself was completely non-functional, don't you think that nearly every major review site that was doing benchmarks with the card, with both "FSAA" (MSAA + AF) enabled, vs. disabled, would have noticed if setting it to enabled did nothing? Because that's how I read your assertion. If your question is more one of proper terminology, and quality-of-implementation, then that's a different assertion than hardware non-functionality.

Originally posted by: BenSkywalker
No, I don't think it means anything at all. When I first picked up a R9500Pro I was repeatedly griping about the seriously screwed up AF filtering and the amount of aliasing it introduced. All of the sites you mentioned 2talked about how much more detail the AF of the R3x0 core added to the scene compared to the rest of the current parts. I got my R9800Pro and was still going off about how poor the AF was on the R3x0 core and again those same three sites you listed off denied it was a problem and there was nothing wrong with it- it was in fact superior to the other offerings. Then 3D Center wrote an article about the low quality blending accuracy that ATi uses on their filtering blending operations and demonstrated how this introduced noticeable aliasing and reduced quality compared to the competition.

Ok, but again, that's not strictly non-functionality, that's a quality-of-implementation issue. It sounds like you are referring to the same thing that I mentioned above, lack of precision bits for the AF operations, with the result that the output still has some apparent visual aliasing.

Originally posted by: BenSkywalker
If everyone simply decided that they were mistaken because Anand, Tom and Dave say something different then numerous issues wouldn't ever be figured out.

But if something was totally non-functional in hardware, don't you think that they would have said something to that effect? What you are doing is effectively accusing them collectively of some sort of conspiracy, really.

Whereas, both AT and TR (and overclockers.com too, based on the other reports, as well as TheReg) have reported on the (allegedly) non-functional 6800 AGP PVP issue.

PS. The amount of "acceleration" that the 6800 (all versions) appear to be doing for MPEG content, is trivial, my S3 Virge and ATI RagePro cards did hardware colorspace-conversion and filtering in hardware years ago. (The analogy is that those features for video would be akin to a fixed-function T&L pipeline, whereas programmable decode (for WMV, etc.) would be akin to programmable shader pipelines.) Just because one is functional, doesn't automatically imply that the other is. The key word with the PVP is "programmable", and if it is, and is working, then it shouldn't be hard to offload things like WMV decoding just as well and as easily as some other formats. The fact that other cards from the same family, using the same "unified" driver set, appear to function, indicates that the problem is not due to total lack of driver support (as I believe the issue with ATI's F-buffer is, until there is more proof available), and therefore the hardware itself is clearly much more suspect.

 

[BenSkywalker]

When MSAA is used in combination with AF, is not every single output pixel displayed on the screen, filtered? How is that not "full scene"? MSAA applied to the edges, AF applied to the insides of the textured polys.

No, alpha textures are not filtered. I read the thread you pointed out on those forums and the poster is mistaken. Fire up CounterStrike using the original engine(I don't have the Source version although it still may be the same Edit- Actually, I do have the Source version- came with HL2 Haven't checked it out yet though/Edit) under OpenGL and load up the Italy map with 6x AA and 16x AF on any current ATi part and look at the railings- severe aliasing. There is also the fact that no AF is applied on the 0 mip at all using AF(for anyone's implementation, even the NV2x parts which had had the purest AF offered yet on a consumer part).

That's funny, everyone so far, has been able to benchmark exactly *zero* acceleration from the PVP on the AGP 6800 cards. Considering that NV's drivers are "unified", and verifiable levels of acceleration do exist on the 6600 cards, that does seem a little... strange, does it not?

Install the default VGA drivers and then the ForceWares and compare how their video playback is. Obviously the PVP is NOT working right now- but the 6800 still accelerates a higher percentage of vid playback then the R3x0 applies AA to pixels on screen.

I was assuming of course, that they were not outright lying. Are you saying that they were?

For DX yes, you can not utilize the FBuffer even using assembly. Under OpenGL I can't say with certainty but I have been waiting to see anything that utitlizes it and like yourself haven't found anything. In fact, Carmack was complaining about the instruction count limit on the R3x0 hardware(well, he made comment that he had already been bumping into the limit) and if JC can't figure out how to get the FBuffer working, I'd say at the very least it is safe to say that ATi made it impossible to use.

Have you considered that the reason that ATI's MSAA + AF implementation of FSAA is visually less appealing than NV's, might not have to do with the use of MSAA specifically, but rather because of the lower precision bits used when performing the filtering?

First off, I'm not saying nV's FSAA looks better, I'm simply saying that they HAVE FSAA. Their xS modes are actual FSAA modes. ATi's edge filtering still has a bit of an edge over nV's(though not as much as in prior generations), nV just has clearly superior texture filtering. The lower precission of ATi's filtering impacts the AF quality for certain though- and this introduces aliasing. Due to the very low level of accuract the effective increase in LOD bias utilized when AF is enabled increases the amount of noticeable aliasing on screen.

Because that's how I read your assertion. If your question is more one of proper terminology, and quality-of-implementation, then that's a different assertion than hardware non-functionality.

My assertion there was that ATi's hardware is fully capable of doing real FSAA but ATi has not enabled it in their drivers.

But if something was totally non-functional in hardware, don't you think that they would have said something to that effect? What you are doing is effectively accusing them collectively of some sort of conspiracy, really.

Not a conspiracy- they have been fed a PR line and swallowed it. Let me be clear on a few things here. Overall I think that using MSAA+AF is a better filtering option then FSAA- you lose too much detail most of the time with a FSAA implementation(in relation to MSAA+AF). That said, there are certain instances where you need FSAA to have any AA at all on certain objects- MSAA+AF does nothing here and particularly for legacy applications having the option would be very nice and simply requires enabling it at the driver level for ATi. They already have the hardware to do it.

 

[DaveBaumann]

Full Scene Anti Aliasing renders the entire image at a higher resolution and then downsamples it(or, in the case of 3dfx, renders out slightly 'jittered' versions of the frame multiple times).

I've yet to see an implementation of Multisampling that doesn't render to a buffer size a multiple of the render target and downsample (hint: this is why it uses more frame-buffer memory and bandwidth).

This method provides anti aliasing to the entire scene including textures(which MSAA does nothing for).

MSAA does do something for textures since textures at the edges will recieve multiple samples.

ATi has no FSAA modes offered on any R3x0 part at all.

That may be the case on the IBM compatible platform, but all Mac versions have SuperSample AA.

 

[Insomniak]

I love Gainward to death. My preference of manufacturers is probably:

1) Gainward
2) Leadtek
3) eVGA
4) BFG
5) Etc.

 

[BenSkywalker]

I've yet to see an implementation of Multisampling that doesn't render to a buffer size a multiple of the render target and downsample (hint: this is why it uses more frame-buffer memory and bandwidth).

Do you consider MSAA to render textures at a higher resolution then what it outputs? Of course it is writing to a larger framebuffer, I've just never considered writing the data to a larger buffer to be the same as rendering the scene out in a higher resolution.

MSAA does do something for textures since textures at the edges will recieve multiple samples.

If you want to stretch it that far, couldn't you say that bilinear is also doing something for edge aliasing though?

That may be the case on the IBM compatible platform, but all Mac versions have SuperSample AA.

That's interesting, why don't they enable it on their x86 drivers then? The only reason I can think of is so they can look better when sites like H do their "maximum quality" comparisons.

Ignoring those points though Dave, wouldn't you say using the FSAA term for MSAA isn't really accurate? I know that is the term most sites use; but as I mentioned previously in this thread I don't recall ever seeing you stating that you actually thought MSAA was a FSAA implementation.

 

[DaveBaumann]

Do you consider MSAA to render textures at a higher resolution then what it outputs? Of course it is writing to a larger framebuffer, I've just never considered writing the data to a larger buffer to be the same as rendering the scene out in a higher resolution.

So, its it undersampleing the texture information or oversmpling the pixels??

If you want to stretch it that far, couldn't you say that bilinear is also doing something for edge aliasing though?

Well, Bilinear is an aliasing reduction tool in the first place since its designed to cure some of the horrible aliasing effects of point sampling.

That's interesting, why don't they enable it on their x86 drivers then? The only reason I can think of is so they can look better when sites like H do their "maximum quality" comparisons.

SuperSampling, by rendering to a larger buffer and downsampling, is very easy to accomplish and doesn?t even necessarily need any hardware (3dfx?s implementation was the exception because it does things differently, but in doing so can be completely transparent to every application).

However, some of the 2D overlays phutz things up under D3D ? you?ll see some games, especially flight sims, had issues with early SSAA mechanisms (that weren?t 3dfx?s) because they had a 2D overlay that rendered over the buffer according to the render target size; of course the front buffer and back buffer sizes are different with SSAA and this screws things up. To get around this, drivers that use SuperSampling via a large front buffer have specific driver workarounds for those games ? ATI dumped their D3D driver with R300 to start again and the never re-implemented those workarounds from the R200 driver, and kept it pure with MSAA as the only option as it (should have been) completely transparent to all apps; NVIDIA have had a single driver for all their boards so the SSAA workarounds can much easier be applied to newer boards. This particular issue applies only to D3D though and was never an issue under OpenGL, that?s why the Mac gets SSAA from ATI but not the PC (they could offer it for OpenGL only, but evidently feel that this would confuse the consumer too much).

Ignoring those points though Dave, wouldn't you say using the FSAA term for MSAA isn't really accurate? I know that is the term most sites use; but as I mentioned previously in this thread I don't recall ever seeing you stating that you actually thought MSAA was a FSAA implementation.

The terminology is not limited to a ?few sites? this stems from OpenGL/SGI/3DLabs as well ? these old stalwarts of the industry are the ones that termed it. If you want to drill into the detail the term ?Full Scene? does not necessarily encompass ?Full Sample?. MSAA is ?Full Scane? antialiasing since it is applied to the entire scene without any intervention from the application (other than the app telling the number of samples to use if it is turned on by the app); remember old ?Edge AntiAliasing? had to be enabled per vertex, so wasn?t necessarily ?Full Scene? (and that is the difference to MSAA Edge AntiAliasing as opposed to just old Edge AntiAliasing).

 

[BenSkywalker]

So, its it undersampleing the texture information or oversmpling the pixels??

I guess that would depend on how you are looking at it.

Well, Bilinear is an aliasing reduction tool in the first place since its designed to cure some of the horrible aliasing effects of point sampling.

And it is closer to FSAA then MSAA.

This particular issue applies only to D3D though and was never an issue under OpenGL, that?s why the Mac gets SSAA from ATI but not the PC (they could offer it for OpenGL only, but evidently feel that this would confuse the consumer too much).

It would confuse the consumer too much versus the horrific CCC?

The terminology is not limited to a ?few sites? this stems from OpenGL/SGI/3DLabs as well ? these old stalwarts of the industry are the ones that termed it.

I'm quite familiar with their implementations of FSAA, and the new wave MSAA doesn't match up to any of their types of techniques that they used back when they were first utilizing the term for their hardware. MSAA can't compare to SSAA or any of the various accumulation buffer techniques that were popular with SGI/Integraph/3DLabs years ago.

MSAA is ?Full Scane? antialiasing since it is applied to the entire scene without any intervention from the application

Your implication in that statement is that it can work application independent which isn't always the case. SplinterCell and Halo as examples. You can of course bring up their odd rendering implementations(compared to other titles) but MSAA is not capable of working on every app and certainly isn't close to working on all aliasing.

remember old ?Edge AntiAliasing? had to be enabled per vertex, so wasn?t necessarily ?Full Scene? (and that is the difference to MSAA Edge AntiAliasing as opposed to just old Edge AntiAliasing).

But MSAA is only an edge anti aliasing technique. It may be full scene *for geometric edges*, but in terms of aliasing removal bilinear is a lot closer to FSAA then MSAA.

 

[flexy]

$39 s/h + 7.5% tax for me in IL...

let me see..total w/ tax = $ 1005.42

I think i take a whole bunch

 

[DrMrLordX]

Best video card ever? I think not. This is the best video card ever! ATI and nVidia fanboys, bow down!

 

[halfadder]

Best graphics ever? Hehehe! I loved the original GeForce256 back in 1998/1999. It was soooo much better than anything else. The 3DLabs WildCat 7210 was nice in 2003, it was a full-length AGP monster! Or the all-time ultimate, Silicon Graphics Infinite Reality inside the Onyx2 and Onyx3 computers... an OpenGL beast from 1995 and updated several times until 2001. In the minimum configuration, it came on 3 cards, each about 2 feet by 2 feet square. The maximum configuration came on 6 cards!! You could have as many as 16 sets of 6 cards each in a single machine (actually several racks full of metal boxes connected by firehose-thick cables). The InfiniteReality4 had 1 GB of dedicated texture RAM and 10 GB of general purpose graphics RAM.

These days SGI just uses a bunch of ATI FireGL cards working in parallel (each one does a section of a screen) controlled by their monster Altix (Opteron/Linux) supercomputers.