Am 23.01.2012 20:02, schrieb Roland Scheidegger: > Am 23.01.2012 19:55, schrieb Marek Olšák: >> On Mon, Jan 23, 2012 at 7:29 PM, Roland Scheidegger <[email protected]> >> wrote: >>> Am 23.01.2012 19:07, schrieb Marek Olšák: >>>> On Mon, Jan 23, 2012 at 6:34 PM, Roland Scheidegger <[email protected]> >>>> wrote: >>>>> Am 23.01.2012 15:44, schrieb Marek Olšák: >>>>>> Hi, >>>>>> >>>>>> I will have to (at least partially) revert this commit, as well as the >>>>>> forked code in glsl_to_tgsi: >>>>>> >>>>>>> commit 2c326e72664e65166c68b027b26aaf373f3be36d >>>>>>> Author: Roland Scheidegger <[email protected]> >>>>>>> Date: Thu Feb 4 19:23:09 2010 +0100 >>>>>>> >>>>>>> gallium: add point size clamp to implementation limits in vertex >>>>>>> shader >>>>>>> >>>>>>> The point size min/max registers (unused by mesa state tracker) >>>>>>> were removed >>>>>>> since most hardware couldn't do much with them. However, we don't >>>>>>> want to have >>>>>>> to rely on hw to do point size clamping correctly to implementation >>>>>>> dependent limits, hence have to do that in the vertex shader. This >>>>>>> should also >>>>>>> solve a potential problem with (non-AA) points smaller than 1.0 >>>>>>> which according >>>>>>> to OGL still have size 1.0. >>>>>>> Note that OGL point rendering is odd, in particular point sprites >>>>>>> are rasterized >>>>>>> differently to points. Some hardware might support those different >>>>>>> modes, but in >>>>>>> any case the different clamping values used for >>>>>>> smooth/multisampled/sprite >>>>>>> enabled points might help a bit for hw which rasterizes points the >>>>>>> same as point >>>>>>> sprites. >>>>>>> Also tweak mesa's ff to vertex shader translation so don't have to >>>>>>> clamp twice in >>>>>>> case of point attenuation. >>>>>> >>>>>> I mean the part which rewrites vertex shaders to clamp the point size >>>>>> in st/mesa. We can't do that if transform feedback is enabled. The >>>>>> point size must be unmodified when writing it into a transform >>>>>> feedback buffer. Also it's unclear to me why we clamp the point size >>>>>> at all. >>>>>> >>>>>> If we want to do any clamping, we should do it after transform >>>>>> feedback, that is after the vertex and geometry shaders. Hardware >>>>>> drivers would have to do it in hardware somehow or fallback to Draw. >>>>>> BTW all Radeons can do point size clamping, so adding >>>>>> pipe_context::set_point_size_range(float min, float max) would be okay >>>>>> for them. >>>>>> >>>>>> BTW I think the only operation which can be done before transform >>>>>> feedback is vertex color clamping (as per the EXT_transform_feedback >>>>>> spec). >>>>>> >>>>>> Marek >>>>> >>>>> I probably didn't think of transform feedback when doing this, so this >>>>> looked like a good idea. IIRC most drivers didn't deal correctly (or at >>>>> all) with point size limits - e.g. point size of 0 would disappear >>>>> (instead of showing point size 1 with non-aa points), max/min point size >>>>> ignored etc. and it looked like not all drivers actually could deal with >>>>> it correctly (without adjusting the vertex shader themselves). >>>>> But you're right this can't work correctly with transform feedback (as >>>>> clamping should happen at rasterization time), so feel free to implement >>>>> a solution which works. >>>>> You can't fallback to Draw however (or rather you shouldn't) since you'd >>>>> always need to fallback if points are drawn, because you don't know if >>>>> the actual point size is larger than either the API or implementation >>>>> dependent limit. So you'd need to fix the drivers to handle it themselves. >>>> >>>> The only requirement so far seems to be: >>>> If non-aa points, then minimum point size = 1. >>>> >>>> I can fix Radeons and Draw. I guess Christoph wants to go with >>>> out-of-spec behavior as usual or do what NVIDIA do. That leaves us >>>> with nvfx and svga. It would be good to know if nvfx can force the >>>> minimum point size to 1 for non-aa points (cc'ing Lucas Stach). Do you >>>> have any idea what we should do for svga? >>> >>> Probably need to fix up the shader. d3d (and svga protocol) point size >>> of 0.1 means the point will vanish (as the point quad rasterization >>> state isn't handled), whereas ogl requires this to be rounded up to 1.0. >>> While the legacy OGL point rasterization rules are significantly >>> different to d3d points (which are the same as ogl point sprites mostly) >>> this is really the difference you will notice. >> >> OK, but this will get pretty ugly when you start supporting geometry >> or tessellation shaders or streamout, assuming you ever want to >> support those. > > Yes but for supporting these new protocol is needed anyway, so can fix > that at this point (that's at least what I think).
Actually I believe this is not necessary. We support a POINTSIZEMIN setting which should work ok (always set to 0.0 currently just setting this to 1.0 for non-pointsprite, non-aa points might do the trick). Roland _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
