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. 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)
