Announcement

Collapse
No announcement yet.

What are your first impressions of the Parhelia ?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #91
    it's not because it says it AAs the edges that it's EDGE AA
    :::muted:::

    Comment


    • #92
      Originally posted by Ryu Connor
      I'm immensely disappointed at this very moment Walt C. You didn't read the links I provided, did you?

      Ryu,

      (This is PART ONE--I had no idea this would take as many words. Ah, what the heck, you only live once, right?...)

      I'm sorry you're disappointed, but I did read your links--I guess you didn't read my post...?.... I notice you dismissed the issues I raised--and it took a bit of time to type in general descriptions for all five (5) of them--without comment and simply referred me to what Tech Report had written up, as though the mere link itself was some sort of Holy Writ. Of course, that's why I'm disappointed--it's tough to raise issues when the other party isn't listening.

      I have never in my life heard the definition of "multisampling" as "edge AA", or "only AA'ing pixels on the edges," so I have to confess that's a brand new one on me... I spelled out some very basic and good reasons why it can't be in the case of the GF4 (and also was not in the case of the GF3, either).

      Multisampling, as I've always heard it defined (for years now), is that the first frame in a given sequence of frames is the only one in which all of the pixels are sampled. After that, in each succeeding frame, only the pixels which change are sampled again. And this continues indefinitely.

      The pixels, usually groups of pixels, that do not change from frame to frame are merely copied to all succeeding frames, whereupon those pixels are not resampled again until they change. Depending on what goes on in a game, or more specifically within a series of frames within a game, you will get more or less pixels resampled for FSAA. This of course definitely impacts performance because the number of pixels AA'ed each frame is far less than in a situation where all of the pixels are AA'ed anew in each succeeding frame.

      In example: say you have a single 3D figure moving in front of a static background. In multisampling FSAA, all of the pixels in the frame are sampled once (to whatever degree you set--2x, 4x, etc.) After that, only the pixels which change in the succeeding frames are resampled in the frame wherein they change--the rest of them are merely copied to all succeeding frames, until such time that any or all of them change. In this example, only the pixels which change in and around the moving figure, comprising the figure itself, and the bits of the background the moving figure displaces from frame to frame, are resampled according to whatever degree you set up in the drivers (2x, 4x, etc.) All of the rest of the pixels are mere copies of the original full scene AA that took place in the first frame.

      So, when nVidia says, "FSAA" they mean FSAA (all the pixels in each frame), but they could be talking about Supersampling or about Multisampling--both of which simply describe the sampling methodology used, and neither of which remotely means "edge AA." Edge AA is a completely different AA method, and is never, under any circumstances, to be confused with FSAA. Again, FSAA simply explains that all the pixels in the image are AA'ed, and supersampling and multisampling are merely two, separate methods by which that may be accomplished.

      As I noted in the original post, this is exactly why nVidia doesn't use any higher sampling definition than 4x (because all of the pixels in the frame are AA'ed), and why Matrox uses the term 16x FAA (not FSAA) to explain its edge AA algorithm. The reason Matrox uses "16x" even though we all know by now that the P is not the same kind of high-performance (in terms of frame rate) chip the GF4 4600 is, is because Matrox's 16x FAA impacts only pixels around the edges of objects with a frame, according to an algorithm Matrox has defined, and this in turn means that the number of total pixels receiving this treatment with each frame is far less than the total number of pixels comprising each frame. When Multisampling in an FSAA setting, a number of pixels less than the total number of pixels in each frame is resampled, but in almost every case that number will exceed the number of pixels resampled in each frame by Martox's FAA (edge AA algorithm.) How many less pixels in each frame the FAA method will resample as opposed to the FSAA method, or "MSAA" as you I think somewhat inaccurately put it, is determined by the number of pixels which change from frame to frame.

      In order to be roughly equal in the terms of overhead required for each method, the Matrox FAA edge method would have to resample exactly 4x less the number of pixels in a frame as the nVidia 4x FSAA multisampling method would have to resample in a given frame (because sampling 1 pixel at 16x is roughly equal to sampling 4 pixels at 4x each in terms of overhead.) Given the fact that the number of pixels to be resampled in a given frame by either method fluctuates from one frame to the next, and that the determination of just which pixels will be resampled from one frame to the next depends in this case upon two wildly dissimilar AA algorithms, the chance that any given frame would result in a situation where the performance overhead of nVidia 's 4x FSAA multisampling and Matrox's 16x FAA would be roughly equal is about NIL, I should say. What, maybe 1000-1 best case? It's almost impossible to say--except that, for certain and absolutely, overall the nVidia method will be treating more pixels per frame, although taking 1/4 of the samples for each pixel treated per frame. If in a given frame the nVidia method had to resample 8x the number of pixels than the Matrox method, then even though the matrox method was taking 4x the number of samples per pixel, the nVidia method would be doing 2x the work.
      Understand?

      That's why I say that comparing 16xFAA to to 4x FSAA (multisampling) is comparing oranges to apples, no question about it. Therefore, the only completely fair way to compare these two products, since nVidia doesn't do FAA and Matrox doesn't do 4x FSAA multisampling is to compare nVidia's 4x FSAA multitsmpling to Matrox's 4x FSAA (multisampling or supersampling, I don't know which.) If, however, it turns out that Matrox is doing Supersampling and nVidia is doing Multisampling FSAA, then even that comparison will not be strictly an apple to apple comparison, since 4x FSAA Supersampling takes quite a bit more work than 4x FSAA multisampling. However, this would still be much closer in terms of comparative performance because in each frame ALL of the pixels are AA'ed, just the method is different.

      This seems to me to be transparent.

      Reiterating, nVidia never uses a number higher than 4x, because what nVidia does in the case of the GF4 (and possibly in the current case of the GF3 as determined by more recent drivers), is to use the Multisampling method of FSAA, which means that a lot more pixels are being treated (all in each frame) by 4 samples, but that those that do not change in succeeding frames are copied from the first frame where they were sampled (regardless of where that particular frame occurs in the total number of frames.) nVidia used to use, in earlier drivers for the GF3 and earlier products, the very resource-intensive Supersampling method of FSAA, which meant that all pixels in each frame were resampled 4x, whether they had changed or not. As has been noted by many, Supersampling is considered more accurate, yet is considered not so much more accurate that its color fidelity advantages outweigh its performance penalties in relation to Multisampling. Thus, although both methods are "full scene" in that they treat every pixel in each frame, the multitsampling method of FSAA is far more efficient because its performance overhead is nowhere as high as Supersampling, and its color fidelity for each pixel is just about as high as Supersampling--though not technically as high.

      The other (what I would call) "glaring" error in the links you provided me is a complete (seemingly) misunderstanding of what 3dfx did with it implementation of rotated grid super sampling. The biggest difference between 3dfx's RGSS and all other subsequent attempts to emulate it to date, including nVidia's, is that 3dfx's was done completely in hardware. None other than John Carmack himself made the observation after having first tested the V5, that its "hardware RGSS could not be duplicated in software." This is a fact routinely forgotten these days.

      The proof is in the pudding. No other FSAA scheme to date, including ALL of those done by nVidia thus far, has been able to handle the AA'ing of near horizontal and vertical lines in a 3D frame as well as 3dfx's hardware (operative word) RGSS scheme. Although I don't use the V5 anymore, and have subsequently replaced it in my primary system with first a GF3 and now a GF4 4600, I have easily noted that neither GF3 or 4 handles near horizontal and verticals anywhere as well as the V5. And that's precisely because that whatever degree of RG nVidia uses is a software implementation and not handled in hardware as it was done with the V5.

      The significance of "near horizontals and verticals" is definitely profound, because if you look at any given 3D frame, the vast number of lines within it will be near horizontals and verticals--not pure horizontals and verticals, and not 45-degree + angles. Again, like Carmack, I've seen the difference, and I know what my eyes tell me... Seeing is definitely believing in this case.

      [end Part ONE]
      I'm uh....C, Walt C.

      Comment


      • #93
        [Part TWO-conclusion]

        Rather, what I find odd, and somewhat disturbing, is that almost all of the time these days, the ones who "gloss over" what 3dfx did with its hardware RGSS, are almost always the very ones who *skipped* the V5 when it was released, and preferred instead a nVidia product, and furthermore were the very ones who routinely said in review after review that they preferred no AA to any AA at all, because they were after frame rates. I used to chuckle at that little bit of self-deceit, because what they were really saying, which was obvious to anyone who'd ever compared nVidia's FSAA with 3dfx's, was that nVidia's FSAA sucked so badly that they'd gladly prefer no FSAA at all when running their nVidia products. Of course, this wasn't what they said ....

        But having often compared nVidia's FSAA with what 3dfx was doing at the time myself, I can't blame them for being stuck with a nVidia product which they refused to run in FSAA mode...

        With my current GF4 4600, which I do prefer above my V5 simply because of the raw performance aspects, I still note that although nVidia has done a great job refining what are essentially its software FSAA modes so that they are much better than what nVidia started with after the V5, they still do not come close to the kind of image quality the V5 delivered.

        Having said that, even though I find the FSAA image quality of the current GF4 to be below my standards--as I have said often here and elsewhere the amount of blurring I get in 4x is very distracting and still noticeable but much less in 2x--I still agree with those early nVidia pundits who declared that they'd rather run their nVidia products without FSAA at all.

        So what I do with my 4600 is run anisotropic filtering at 8x (64-tap), and get what I think is great image quality, and don't spoil it by using nVidia's various FSAA schemes (which are still inferior to what I had with the V5.) I still get acceptable performance with 64-tap AF, and a nice, crisp non-blurred image at the same time. Under these conditions I'll gladly put up with some jaggies where I have to with my GF4 4600.

        It's going to be interesting to see the nV30 as I note that the nv30 is the first chip jointly developed by the 3dfx & nVidia engineers. Will hardware RGSS or RGMS make it into the nv30? At this point I have no idea, but it will be interesting to see. If it does, this will probably settle the purchase of my next videocard on the nv30.
        I'm uh....C, Walt C.

        Comment


        • #94
          The Tech-Report article is worded in such a way that it suggests that Edge-AA is a form of multisampling. When I read through that article, I too was led to believe that this was the case. I believe the problem to be in the wording only - many articles use the term edge-AA to refer to the process of eliminating jaggies (since these are the only places they are visible), they are not referring to the technical process known as edge-AA.

          The AA technical briefs on the NVidia site are pretty clear on this point - no current Geforce cards support Edge-AA. Edge-AA is supported under the directX 8 API - however Microsoft do not recommend using it if Full-Scene AA is supported. For info on the DirectX 8 definition of this process, check this link:

          Learn with interactive lessons and technical documentation, earn professional development hours and certifications, and connect with the community.


          edit: To clarify further, according to the DX8 definition, edge antialiasing must be called by the software, and the specific edges to be redrawn must be defined within the program. The card is not able to apply antialiasing to all edges automatically.
          Last edited by Cheesekeeper; 2 July 2002, 04:12.

          Comment


          • #95
            It's referred to as an edge AA because it doesn't sample the whole scene. Hence the move away from calling it Full Scene AA.

            Then benefits are a performance increase (because you aren't doing the full scene). The downside is the loss of better visuals (because you aren't doing the whole scene).

            For example:

            <a href="http://www.unspacy.com/ryu/systems.htm">Ryu's PCs</a>

            Comment

            Working...
            X