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. > >> 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. Its true this is a little broadly named. It is intended only to affect pixel-selection in the rasterization algorithms and texture sampling as Roland points out. > Hm, alright. I'll just keep on using GL variants of things until > somebody complains or makes better flags, then. That's pretty reasonable. Keith ------------------------------------------------------------------------------ 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
