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

Reply via email to