summaryrefslogtreecommitdiffstats
path: root/src/glx/dri2.c
diff options
context:
space:
mode:
authorKenneth Graunke <[email protected]>2018-07-21 23:40:16 -0700
committerKenneth Graunke <[email protected]>2019-01-15 20:53:44 -0800
commit5b51d754d00dfd7d8f4069aca4619f3b056c4eac (patch)
treee0e95d45b11d37e4b72694fe6c7544d60da4ca84 /src/glx/dri2.c
parent11735d6c9c76256df3be65a8853d78f3437aedd0 (diff)
st/mesa: Optionally override RGB/RGBX dst alpha blend factors
Intel's blending hardware does not properly return 1.0 for destination alpha for RGBX formats; it requires the factors to be overridden to either zero or one. Broadcom vc4 and v3d also could use this override. While overriding these factors is safe in general, Nouveau and Radeon would prefer not to. Their blending hardware already returns correct values for RGB/RGBX formats, and would like to avoid the resulting per-buffer blending and independent blend factors (rgb != a) since it can cause additional overhead. I considered simply handling this in the driver, but it's not as nice. pipe_blend_state doesn't have any format information, so we'd need the hardware blend state to depend on both pipe_blend_state and pipe_framebuffer_state. Furthermore, Intel GPUs don't have a native RGBX_SNORM format, so I avoid exposing one, which makes Gallium fall back to RGBA_SNORM. The pipe_surfaces we get in the driver have an RGBA format, making it impossible to tell that there shouldn't be an alpha channel. One could argue that st not handling it in that case is a bug. To work around this, we'd have to expose RGBX pipe formats, mapped to RGBA hardware formats, and add format swizzling special cases. All doable, but it ends up being more code than I'd like. st_atom_blend already has access to the right information and it's trivial to accomplish there, so we just add a cap bit and do that. Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
Diffstat (limited to 'src/glx/dri2.c')
0 files changed, 0 insertions, 0 deletions