d1d3ebb48c
It was a bit trickier to RE, since blob doesn't expose this functionality at all, however we had a clue from the very beginning: lima_blend_factor is 3 bits, i.e. 8 values, but only 5 of them were used, it just waited till someone tried what 3 unused values do. Interestingly enough, it turns out "5" works just as "0" (which is PIPE_BLENDFACTOR_*SRC_*), but only if output register for gl_FragColor is $0, So it looks suspiciously similar with PIPE_BLENDFACTOR_*SRC1_* behavior, and looks like secondary output is taken from $0. Since output regs for all other outputs are configured via RSW, there must be a field in RSW for output register for secondary color, it's likely 4 bits and it's currently set to 0 for reg $0. Then it was just a matter of brute-forcing various consecutive 4 bits in RSW - and indeed, setting top 4 bits of rsw->aux0 to the index of gl_FragColor output register fixes blending tests when we use "5" blend factor instead of "0". So it must be a register number for gl_SecondaryFragColor. Unlike gl_FragColor, the field is only repeated once in RSW. Wire it up in compiler, and piglit arb_blend_func_extended now passes. Reviewed-by: Andreas Baierl <ichgeh@imkreisrum.de> Reviewed-by: Erico Nunes <nunes.erico@gmail.com> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13873>
50 KiB
50 KiB