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?).
> > multisample is a very non-specific flag. How much multisampling? Are > there any rules to aim for? This is just used for the opengl enable/disable of multisampling (which can happen at any time - some hardware might not be able to do this possibly). The "how much" is stored in the pipe_texture eventually (the nr_samples field) instead, there's some expectation the number there corresponds to the amount of multisampling, though this can't really cover things like CSAA (though that's not covered by "normal" opengl multisampling neither). > > gl_rasterization_rules probably maps to only one flag in Intel chips, I > bet, but for Radeons there are dozens of flags, instructions, and rules > which have GL and DX variants. Knowing *which* rasterization rules are > covered by this flag would be nice. The most prominent thing it covers is probably the different texture sample positions (though notably DX10 is like OpenGL there). Not sure if this would cover things like differences in LIT instructions, but I guess it does. 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
