On Mon, Mar 21, 2011 at 4:50 PM, Brian Paul <bri...@vmware.com> wrote:
> On 03/21/2011 09:10 AM, Keith Whitwell wrote: > >> On Mon, 2011-03-21 at 02:12 +0100, Marek Olšák wrote: >> >>> diff --git a/src/gallium/include/pipe/p_state.h >>> b/src/gallium/include/pipe/p_state.h >>> index cf6c5b5..f6ad456 100644 >>> --- a/src/gallium/include/pipe/p_state.h >>> +++ b/src/gallium/include/pipe/p_state.h >>> @@ -81,6 +81,8 @@ struct pipe_rasterizer_state >>> { >>> unsigned flatshade:1; >>> unsigned light_twoside:1; >>> + unsigned clamp_vertex_color:1; >>> + unsigned clamp_fragment_color:1; >>> unsigned front_ccw:1; >>> unsigned cull_face:2; /**< PIPE_FACE_x */ >>> unsigned fill_front:2; /**< PIPE_POLYGON_MODE_x */ >>> >> >> Don't know if this affects the overall packing of the struct. Have you >> been able to check? >> >> Otherwise the interface changes look good to me. >> > > > How do most GPUs handle this clamping? Is it done with extra shader code > or is it a discrete operation? If most hardware does it with shader code, > maybe we should just do it that way too in Gallium and avoid the new cap > bits, etc. > There is a bit in the CB_COLOR[0-7]_INFO register on R600 which controls color clamping before blending. I am not sure whether it can be used for ARB_color_buffer_float or whether it's strictly dependent on the colorbuffer format. Christopher, do you happen to know whether NV50/NVC0 has a hardware state for it too? > OpenGL 3.0 deprecates the per-vertex and per-fragment clamp controls so > people will have to do it in their shaders eventually. > > > Re: your comment in rasterizer.rst: > > > XXX: this happens _before_ the geometry shader and thus might not belong > here. > > So is there some question about where the per-vertex clamp is to be done? > It seems to me that it should be done after the geometry shader. > You're right. I will remove that comment. Marek
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev