On Sunday 13 March 2005 23:34, I wrote: > On Sunday 13 March 2005 06:28, Nicolai Haehnle wrote: > > On Sunday 13 March 2005 01:25, Daniel Phillips wrote: > > > A question nobody raised yet: what about running FSAA in a > > > window? Although it is possible to map all non-FSAA graphics > > > transparently to FSAA and run FSAA for the full screen, the > > > overhead would be awful. The best way to do this is render to > > > texture and copy the texture to the window. This requires being > > > able to send the scanout to memory instead of the DAC, which > > > seems like a feature worth having since it gives us render to > > > texture, which has many other uses. > > > > You don't need to screw around with the DAC to get render to > > texture. As long as the texture format and framebuffer format are > > the same (which they will be, according to Timothy), all you need > > to do is reprogram the colorbuffer base address independently of > > the frontbuffer base address (but you need that ability anyway in > > order to implement double buffering). > > Unless the FSAA averaging is combined with the scanout, which is > highly recommended. It is a tiny amount of hardware that saves a > huge amount memory bandwidth. > > Anyway, this is not "screwing around with the DAC", it is "screwing > around with the video controller". Timothy was planning to make that > pretty fancy anyway, as I recall, i.e, programmable. This feature > will probably fit right in. > > > A 2x2 box filter for FSAA could then be obtained simply by using > > the bilinear filtering of the texture unit. > > But that would require an additional rendering pass with an > additional memory bandwidth hit just when we don't want it, and would > be very non-transparent to the application.
Hmm, on second thought, it's not that bad. The overhead is limited to just the window with the FSAA. But on third thought, that window might be a big part of the screen, and so take a big bite out of fill rate by unnecessarily hogging the 3D pipeline. On fourth thought, this is unlikely to be the very worst thing about the card. On fifth thought, this is precisely what we plan to do with 2D graphics in general. And finally, being able to direct the FSAA scanout to a texture is an easy optimization we could leave for later. OK, thanks Nicolai, I feel better about that now. Note that the averaging hardware is still needed for video scanout or else full-screen FSAA (the most important kind) will be a lot slower. Probably uselessly, with this arrangement we could have FSAA running in multiple windows while the screen as a whole is also in FSAA mode, and we'd get some weird kind of double antialiasing. Regards, Daniel _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
