On 24.06.2016 04:07, Brian Paul wrote:
If the user requests an RGB drawing surface but we actually create an RGBA surface, we need it to act as if A=1. For blending, this means adjusting the blending terms to use 1/0 instead of DST_ALPHA/INV_DST_ALPHA. Drivers can use this flag to determine when that's needed.
Having the bit is fine, but shouldn't there be a PIPE_CAP for it? Nicolai
A previous patch I posted last year did this entirely in the state tracker but it involved making blend state dependent on the framebuffer state. This approach avoids that dependency. --- src/gallium/include/pipe/p_state.h | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/include/pipe/p_state.h b/src/gallium/include/pipe/p_state.h index 9c69355..8b0c3a2 100644 --- a/src/gallium/include/pipe/p_state.h +++ b/src/gallium/include/pipe/p_state.h @@ -387,6 +387,7 @@ struct pipe_surface unsigned height; /**< logical height in pixels */ unsigned writable:1; /**< writable shader resource */ + unsigned alpha_one:1; /**< Should an RGBA surface should act like RGB? */ union { struct {
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev