From d769e67c522cc4faebd98e57e53466713c785b85 Mon Sep 17 00:00:00 2001 From: Mike Blumenkrantz Date: Mon, 16 Mar 2026 09:07:10 -0400 Subject: [PATCH] llvmpipe: fix color fbfetch with the unlowering pass, there is no longer a separate gl_LastFragData variable, so this workaround just breaks color outputs fixes dEQP-GLES31.functional.shaders.framebuffer_fetch.basic.last_frag_data cc: mesa-stable (cherry picked from commit 4b2022a8f58aab6d06c04457b6d334714cecf744) Part-of: --- .pick_status.json | 2 +- .../drivers/llvmpipe/ci/llvmpipe-fails.txt | 1 - src/gallium/drivers/llvmpipe/lp_state_fs.c | 18 ------------------ 3 files changed, 1 insertion(+), 20 deletions(-) diff --git a/.pick_status.json b/.pick_status.json index cd983e9beae..b0426fda3c7 100644 --- a/.pick_status.json +++ b/.pick_status.json @@ -4884,7 +4884,7 @@ "description": "llvmpipe: fix color fbfetch", "nominated": true, "nomination_type": 1, - "resolution": 0, + "resolution": 1, "main_sha": null, "because_sha": null, "notes": null diff --git a/src/gallium/drivers/llvmpipe/ci/llvmpipe-fails.txt b/src/gallium/drivers/llvmpipe/ci/llvmpipe-fails.txt index d3b9d642c7a..b7aeb5bd35c 100644 --- a/src/gallium/drivers/llvmpipe/ci/llvmpipe-fails.txt +++ b/src/gallium/drivers/llvmpipe/ci/llvmpipe-fails.txt @@ -93,7 +93,6 @@ spec@!opengl 1.1@polygon-mode-offset@config 4: Expected white pixel on right edg spec@!opengl 1.1@polygon-mode-offset@config 4: Expected white pixel on top edge,Fail # Seen in https://gitlab.freedesktop.org/mesa/mesa/-/pipelines/1364513 -dEQP-GLES31.functional.shaders.framebuffer_fetch.basic.last_frag_data,Fail spec@arb_framebuffer_object@execution@msaa-alpha-to-coverage_alpha-to-one_write-z,Fail spec@ovr_multiview@compiler@multiple-num-views-in-single-declaration-mismatch.vert,Fail diff --git a/src/gallium/drivers/llvmpipe/lp_state_fs.c b/src/gallium/drivers/llvmpipe/lp_state_fs.c index df9db51babc..99ef54ac808 100644 --- a/src/gallium/drivers/llvmpipe/lp_state_fs.c +++ b/src/gallium/drivers/llvmpipe/lp_state_fs.c @@ -1241,7 +1241,6 @@ generate_fs_loop(struct gallivm_state *gallivm, LLVMBuildStore(builder, out, ptr); } - bool has_cbuf0_write = false; /* Color write - per fragment sample */ nir_foreach_shader_out_variable(var, nir) { if (var->data.location < FRAG_RESULT_DATA0) @@ -1252,23 +1251,6 @@ generate_fs_loop(struct gallivm_state *gallivm, unsigned cbuf = get_cbuf_location(var, s); unsigned attrib = var->data.driver_location + s; if ((cbuf < key->nr_cbufs) || (cbuf == 1 && dual_source_blend)) { - if (cbuf == 0) { - /* XXX: there is an edge case with FB fetch where gl_FragColor and - * gl_LastFragData[0] are used together. This creates both - * FRAG_RESULT_COLOR and FRAG_RESULT_DATA* output variables. This - * loop then writes to cbuf 0 twice, owerwriting the correct value - * from gl_FragColor with some garbage. This case is excercised in - * one of deqp tests. A similar bug can happen if - * gl_SecondaryFragColorEXT and gl_LastFragData[1] are mixed in - * the same fashion... This workaround will break if - * gl_LastFragData[0] goes in outputs list before - * gl_FragColor. This doesn't seem to happen though. - */ - if (has_cbuf0_write) - continue; - has_cbuf0_write = true; - } - for (unsigned chan = 0; chan < TGSI_NUM_CHANNELS; ++chan) { if (outputs[attrib][chan]) { /* XXX: just initialize outputs to point at colors[] and