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. >> 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). Alright. So r300 can (with a bit of experimenting) do this. Just gotta figure out exactly what looks best. Looks like I've just got to examine the nr_samples count for the bound colorbuf, and then adjust accordingly. >> 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. Hm, alright. I'll just keep on using GL variants of things until somebody complains or makes better flags, then. Thanks. ~ C. ------------------------------------------------------------------------------ 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
