On Tuesday 08 March 2005 08:48, Martijn Sipkema wrote: > From: "Daniel Phillips" <[EMAIL PROTECTED]> > > > > > The simple 2x2 supersampling approach does not have this problem, > > > > > but how does this work for multisampling? > > > > > > > > The color value for each subsample is stored separately and only > > > > mixed with other subsamples in final scanout. > > > > > > Multisampling is the standard OpenGL way---apart from using a > > > multipass algorithm using the accumulation buffer---of handling > > > antialiasing for the general 3d case. > > > > Multisampling is an extension, not a standard feature of OpenGL. > > No, it is a standard, though optional, feature of OpenGL since 1.3 IIRC.
Yes, thanks for clearing that up. And page 321 of the OpenGL 2.0 spec, states explicitly that both multisample and supersample implementations are supported, so that clears that up. On a light reading, I still don't see exactly how implementations without coverage masks are made entirely legal, because the spec seems to make some very specific statements about the availability of coverage bitmasks. I trust there is some way to read the spec so that coverage bitmasks aren't required. > > By the way, it is a practical certainty that we will not be able to > > implement GL_SMOOTH or GL_LINE_SMOOTH in hardware in the initial > > design. These will have to be implemented using alpha polygons, just > > like any other early generation 3D card. > > That's too bad, since these are nice features. But I kno next to nothing > about hardware and how hard it would be to implement. Antialiased lines > certainly are not that complicated though. Think of an elephant in a bathtub. That is how our simple fixed function rendering pipeline looks, sitting in the middle of this gate array. There just isn't room to add hardware for any functions that aren't strictly needed for the OGL 1.3 pipeline, without drastically scaling back the fill rate of the card. If we drastically scale back the fillrate, everybody including 2D users will hate this card and the project will die on the vine. Simple, no? To put it another way: all the dedicated multipliers are already used up, just to render two pixels per clock with 2 texture multitexturing. We need to implement somewhere between 50 and 100 additional 8x8 multipliers in random logic to handle the fragment processing (because all the dedicated multipliers are taken by the rasterizer). There are tons of big nasty floating point adders and lots of logic to glue it all together. There are four memory controllers, a video controller, a DMA controller and (probably) a pci controller to implement. And a bunch of things I have overlooked because I am not a hardware guy. Just based on lack of multipliers, hardware line antialiasing is out of reach. Implementing aa lines as polygons may not produce the most perfect results in the universe or be as fast as a dedicated Gupta-Sproul implementation, but it is the only choice available. And if we did somehow find ourselves with more hardware to burn, a better use for it than Gupta-Sproul lines would be to increase the rate of span setup from 4 clocks per span to 1 clock. That way, skinny trapezoids would render just as fast as Gupta-Sproul lines. As for prettiness, please look here and tell me this is not pretty: http://homepage.mac.com/arekkusu/bugs/invariance/TexAA.html And again, we don't have any choice, so the discussion is academic. > > FSAA provides an important capability that is well within our reach to > > implement and can't be emulated in any practical way. It is not meant > > for drawing a 2D desktop. In this, we are no different from any other > > 3D card. > > You could implement it in software by rendering to a larger buffer and > downsampling, right? There is quite some hardware around that doesn't > support FSAA (and may even support smooth lines). Supersampling does render to a larger buffer and downsamples. Minimal hardware is required, just the averaging on scanout. That is why it is practical to do, whereas Gupta-Sproul lines are not. 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)
