Announcement

Collapse
No announcement yet.

r200 register to enable SSAA

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

  • r200 register to enable SSAA

    Hi!
    As ATI delays publishing register reference documents continuously, I have lost hope to figure out how to enable FSAA (or call it SSAA, whichever you like)

    To prevent confusion I'd like to emphasize that I don't mean xorg.conf setting to enable FSAA. I look for the method to enable FSAA in driver level. Any Ideas?

    Regards,

  • #2
    You are talking about Super-Sampling Anti-Aliasing/Full-Screen Anti-Aliasing, right?

    Comment


    • #3
      Exactly that's what I am looking for desperately...

      Comment


      • #4
        It's not covered by the doc we were planning to re-release either. AFAIK there's a lot more to SSAA than just setting a register bit, but we can check.

        EDIT - Alex took a look through the internal hardware design info and didn't see anything that looked SSAA-related there either. That implies the SSAA was being done using the 3D engine, originally in the driver but presumably it makes more sense to do it in the compositor these days.

        EDIT 2 - from skimming the old programming guide, it looks like the R200 used MSAA rather than SSAA for full-screen AA. That might be why we didn't find anything.
        Last edited by bridgman; 03-26-2009, 02:26 PM.

        Comment


        • #5
          So super-sampling is basically a matter of rasterize->downsample, then?

          Is this similar on newer hardware, as well?
          Last edited by TechMage89; 03-26-2009, 11:09 AM.

          Comment


          • #6
            Bridgman, the capability is definitely implemented in the Catalyst driver. As it is not open source, perhaps you may want to delve into its source codes regarding the details.

            Comment


            • #7
              Originally posted by wildcard View Post
              Hi!
              As ATI delays publishing register reference documents continuously,
              Something I should mention; we have *not* delayed publishing register reference documents at all. We identified the *sequence* of tasks we would be working on, and we're getting fairly close to the point where we will be looking at older GPUs. In the meantime I said that *if* we were able to find an editable copy of the existing docs we would try to re-release them sooner. That's it.

              We may not have published specs as quickly as you *hoped*, but that's different.

              Originally posted by kurukafa View Post
              Bridgman, the capability is definitely implemented in the Catalyst driver. As it is not open source, perhaps you may want to delve into its source codes regarding the details.
              We will do that when we start working on the older GPUs. Right now our focus is still primarily on 5xx and newer parts, at least until we see basic 3D for 6xx/7xx and some basic power management in the open source drivers.
              Last edited by bridgman; 03-26-2009, 02:27 PM.

              Comment


              • #8
                Something I should mention; we have *not* delayed publishing register reference documents at all.
                I don't mean any offense, apologies. I respect your work.

                So super-sampling is basically a matter of rasterize->downsample, then?
                Well it appears there is something more than that. I've already tried downsampling rasterized image, but it does not perform as does catalyst.

                from skimming the old programming guide, it looks like the R200 used MSAA rather than SSAA for full-screen AA. That might be why we didn't find anything.
                Then, what is your suggestion for me to proceed? Shall I expect recieving any further details any soon?
                Any sort of clue is very appreciated. I'm in such a trouble you cannot imagine

                Comment


                • #9
                  As far as I remember you really need a memory manager.

                  you just need to render to a backbuffer 2xwidth + 2xheight, and downscaling on the blit to the frontbuffer or using the 3D engine to scaledown with smoe filtering. or maybes thats super-sampling, I forget the details

                  I don't think there is much in a register.

                  Comment


                  • #10
                    IIRC, the R200 only did SSAA, but with a programmable or pseudorandom sample pattern with from 2 and 5 samples per pixel (as opposed to a simple 2x2 grid, which as airlied points out doesn't really require any special hardware functionality at all--that's what the R100 had, BTW)

                    I remember that it took several (Windows) driver revisions for ATI to get the R200's FSAA to actually work, so perhaps it was mostly driver magic all along, somehow using the 3D engine to implement the variable sample patterns? Either that or the hardware that set up the sample patterns was buggy somehow.

                    Comment


                    • #11
                      If by any chance r300 docs are any good to you:
                      http://www.x.org/docs/AMD/R3xx_3D_Registers.pdf

                      there on page 25 one may find AA config register. I'd be very delighted if r200 or r300 would get a working SSAA and line smooth. It seems ridiculous that almost ten years old stuff is still so secret that it is next to impossible or needs great deal of work to make any complete docs available without NDA and big money.

                      http://ixbtlabs.com/articles/atir200
                      http://ixbtlabs.com/articles2/radeon/ati-r300.html

                      Features explained in above links would be so nice in open source media players that it almost makes me angry to remember days when it was just posible to play svcd on P2 300MHz and mach64 or so. That's only because proprietary player makers (Windvd et al) get access to the docs.

                      Is AMD waiting for The Open Graphics Project to publish their first asic and then just kill the competition like a bug?

                      Comment


                      • #12
                        Originally posted by vesa View Post
                        Features explained in above links would be so nice in open source media players that it almost makes me angry to remember days when it was just posible to play svcd on P2 300MHz and mach64 or so. That's only because proprietary player makers (Windvd et al) get access to the docs.
                        With regards to hardware accelerated video playback in the open source drivers, the issue is that if they document the way to send the compressed video frames to the GPU, it then becomes possible for someone to write a windows driver that can intercept these compressed (but stripped of any DRM that may have been applied to them) video frames. And that means that AMD would then be in violation of the license it has with Microsoft (the one that allows AMD to see all the secret bits you need in a display driver before Windows and the media players running on top of it will give you the compressed-but-no-DRM video frames).
                        AMD would then be opening themselves up to a lawsuit from MS (and content companies relying on MS and the GPU vendors to protect the decrypted video stream)

                        Comment


                        • #13
                          Just a word of note:
                          If you render in a 2x2 grid, you will essentially get something only slightly better than 2xAA, since you only have 2 "levels" of testing per pixel per dimension.
                          By rotating the grid about 30%, (RGSS) you can get 4 "levels" of testing per pixel per dimension. Same amount of work, but vastly better image quality.

                          I also remember my Radeon 8500 could sample sub-pixels, but how it did it... I don't know

                          Comment


                          • #14
                            Originally posted by vesa View Post
                            If by any chance r300 docs are any good to you:
                            http://www.x.org/docs/AMD/R3xx_3D_Registers.pdf

                            there on page 25 one may find AA config register. I'd be very delighted if r200 or r300 would get a working SSAA and line smooth. It seems ridiculous that almost ten years old stuff is still so secret that it is next to impossible or needs great deal of work to make any complete docs available without NDA and big money.
                            It's not so secret, it's just a lot of work, and there are only a few of us on the open source team. Not only does the information have to be compiled and written, it then has to go through IP and legal review. If we spent time now creating docs for r2xx chips, it would take a way from getting info out on newer chips and other features that aren't documented at all yet. That's our priority right now. We do hope to eventually get documentation out on older chips, but in the meantime, the r1xx/r2xx programming information is already available in the mesa 3D drivers and radeon ddx source code.

                            I've checked the r200 register databases and I did not see any AA regs, so presumably we used the 3D engine. The mesa r200 3D driver has pretty much everything documented at this point.

                            As to r300, IIRC, smooth lines require shaders. There's no dedicated hw for them like on older asics.

                            Comment


                            • #15
                              I found a description of how FSAA was implemented on the original Radeon (R100):

                              http://www.sharkyextreme.com/hardwar...depth/10.shtml

                              Rather than render to a double-sized backbuffer and downscale it, the R100 renders to four separate backbuffers (each offset by half a pixel in a different direction) and then blends them. This is more efficient because you only need 4 times the memory rather than 5--in the blending step, you blend three of the backbuffers onto the fourth. It also makes optimal use of the hardware resources because the R100 has three texture units.

                              There's no magic hardware register to do this, it's entirely done at the driver level.

                              I imagine that FSAA on R200 on the proprietary drivers on either Linux or Windows works the same way, only you have more choices of AA levels that are hardware-efficient, because of the more versatile pixel pipeline.

                              Comment

                              Working...
                              X