On Mon, Sep 12, 2011 at 6:17 AM, Dave Airlie <airl...@gmail.com> wrote: > Hi, > > So I was looking at EXT_texture_integer and realised our clear code was > a bit rough wrt allowing drivers access to the native ints. Also the > use of ClearColor vs ClearColorUnclamped meant that gallium never got the > i/ui clear values at all (even as floats). These patches are my first attempt > at cleaning up the clear code to allow a union + type to be passed around.
The union is good, but I'm not sure that we need the _ClearColorType field. According to the GL_EXT_texture_integer spec, it seems that the clear color stored in the union is interpreted according to the datatype of the target color buffer(s). So if the user sets the color with glClearColor() but tries to clear an integer-valued buffer, the results are undefined. There's no need to try to translate the user-specified color data type to the current buffer type. As for gallium, we can probably just replace the 'const float rgba[4]' parameter to pipe_context::clear() with a float/int/uint union type for rgba and let the driver interpret the values according to the color buffer's type. > They don't fix the gallium interface yet, it still floats the clear colors, > but it does try to push the problem down from the mesa core as much as > possible. > > Open questions: > 1) can we drop the unclamped ClearColor and push the clamping into the paths > that need it? (some drivers + the get.c). Yes. > 2) can we drop the dd.h ClearColor hook for integer supporting drivers? The > only drivers using this hook are radeon/r200 dri, the x11 and window gdi > drivers. If we state that its not necessary for the integer paths it makes > the code a lot saner from what I can see. Agreed. I also think we should add a driver hook function for ClearBuffer() to avoid the ugly clear color save/restore code in the glClearBuffer() functions. BTW, I don't see the need for your COPY_CLEAR_COLOR() macro (which could be an inlined function, btw): why not just use an ordinary assignment? -Brian _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
