The way that dual-source blending is described for GLES2 is very odd,
and we end up with a shader that both has this property set *and* has a
color1 value to be used as the second source. While changing the state
tracker is an option, it seems more reliable to verify that the
broadcast is only done on color0.
Fixes arb_blend_func_extended-fbo-extended-blend-pattern_gles2
Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
---
src/gallium/drivers/swr/swr_shader.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/swr/swr_shader.cpp
b/src/gallium/drivers/swr/swr_shader.cpp
index e4f9796..2f72239 100644
--- a/src/gallium/drivers/swr/swr_shader.cpp
+++ b/src/gallium/drivers/swr/swr_shader.cpp
@@ -645,7 +645,8 @@ BuilderSWR::CompileFS(struct swr_context *ctx,
swr_jit_fs_key &key)
LLVMValueRef out =
LLVMBuildLoad(gallivm->builder, outputs[attrib][channel], "");
- if
(swr_fs->info.base.properties[TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS]) {
+ if
(swr_fs->info.base.properties[TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS] &&
+ swr_fs->info.base.output_semantic_index[attrib] == 0) {
for (uint32_t rt = 0; rt < key.nr_cbufs; rt++) {
STORE(unwrap(out),
pPS,
--
2.7.3
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
