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). Roland _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
