diff options
author | Kenneth Graunke <[email protected]> | 2018-07-21 23:40:16 -0700 |
---|---|---|
committer | Kenneth Graunke <[email protected]> | 2019-01-15 20:53:44 -0800 |
commit | 5b51d754d00dfd7d8f4069aca4619f3b056c4eac (patch) | |
tree | e0e95d45b11d37e4b72694fe6c7544d60da4ca84 /Makefile.am | |
parent | 11735d6c9c76256df3be65a8853d78f3437aedd0 (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 'Makefile.am')
0 files changed, 0 insertions, 0 deletions