BTW, colors should indeed be clamped for SM 2.0 in the VS. The reason is that old ps2.0 hardware used the R8G8B8A8_UNORM format for color varyings, meaning that all colors were always clamped when they left the vertex shader and this behavior couldn't be disabled. r300-r400 behave this way, so they don't need any clamping. There are 2 CAPs for this:
PIPE_CAP_VERTEX_COLOR_UNCLAMPED PIPE_CAP_VERTEX_COLOR_CLAMPED If just PIPE_CAP_VERTEX_COLOR_CLAMPED is advertised, the colors are clamped after the vertex shader and this cannot be changed. (r300-r400) If both CAPs are advertised, you can choose if you want clamping or not by setting pipe_rasterizer_state::clamp_vertex_color. (r500) If just PIPE_CAP_VERTEX_COLOR_UNCLAMPED is advertised, the colors are not clamped and this cannot be changed. (r600 and later chips) Marek On Sun, Jan 11, 2015 at 10:30 AM, Axel Davy <axel.d...@ens.fr> wrote: > On 07/01/2015 17:36, Axel Davy wrote : >> >> Nine code was clamping color outputs for vs < 3, >> but msdn docs says it is done in the ps. >> Wine seems to clamp them at the vs level. >> >> It makes more sense to clamp at vs level for performance, >> but according to doc, ps 2.x shouldn't see clamping. >> >> > We have found a game using ps 2.x that didn't work well anymore > with this patch, so likely the documentation is wrong about ps 2.x > behaviour. > > Since it is disallowed to use vs <= 2 with ps 3 and vs 3 with ps <= 2 > (except for software renderer), > then it is better for performance to clamp color outputs at vs <= 2 level, > which is what was doing > previous code. > > So this patch is dropped. > > Axel Davy > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
