On 18.05.2009 12:55, Keith Whitwell wrote: > On Sun, 2009-05-17 at 22:26 -0700, Corbin Simpson wrote: >> Roland Scheidegger wrote: >>> On 17.05.2009 20:27, Corbin Simpson wrote: >>>> Hate to keep bugging the list, but these things just aren't very >>>> well-documented sometimes. This is pretty much all >>>> pipe_rasterizer_state-specific. >>>> >>>> First, point_smooth and line_smooth. I've heard that there's ways to >>>> handle these in vertex shaders, is this true? I'm guessing that these >>>> are in rasterizer state because some cards can do this in dedicated HW; >>>> for those of us that can't, could we maybe set up a get_param for it so >>>> we don't have to have this muddled overlapping state? Or am I wrong >>>> about using vert shaders for smoothing? >>> I am unsure how you want to do smooth lines with vertex shaders? >>> I think what modern hardware usually can do is it calculates a coverage >>> value for each pixel which you can then use in the fragment shader (or >>> rather alpha blend). I'm unsure though if that method actually always >>> would work. For smooth points, no modern hardware seems to support that >>> (though it might be possible some hardware also would do similar >>> coverage calculation). With no hardware support, you can either >>> decompose the circle into (depending on size) lots of tris (a bit >>> expensive though), or just use point sprite and tack on a alpha circle >>> texture and use alpha blend (fglrx for r200 did this - I know cause it >>> didn't work correctly with alpha blend enabled...). I guess though on >>> modern hardware you'd just want to calculate the distance from the >>> fragment center and kill the pixel based on that. Though again I can't >>> see how vertex shaders would help (though possibly geometry shader could >>> do the trick too?). >> I learned something today. :3 > > >> Point sprites or similar were suggested by osiris, too. Not sure, but >> gonna keep thinking about it, maybe revenge it and see what I get. > > It's very easy for a driver to get smooth lines & points, line stipple, > unfilled polygons, etc, working under gallium -- basically just fall > back to software t&l and the draw module will do them for you. > > They are still hardware-rasterized, but we need to do > software-transformation to tweak the geometry to cover the bounding area > of the primitive. Then we set a special 'smoothing' fragment shader and > pass the primitives back into the driver. > > As long as you already support switching between hwtnl and swtnl (or > just swtnl all the time) this is very easy for the driver. Yes, though some hardware doesn't require software t&l for this but can do that somehow, however need some handwaving. For instance radeon r300 hardware (I assumed this was what Corbin was refering to) has GA_LINE_S0 reg with description "S texture coordinate value generated for vertex 0 of an antialiased line; 32-bit IEEE float format. Typical 0.0.". Not sure how it's supposed to work however, the coord generation looks like "line sprite" to me... i965 can do coverage value calculation and so I think wouldn't need sw tnl neither.
Roland ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
