[Mesa-dev] [PATCH 2/3] glsl: Fix incorrect hard-coded location of the gl_SecondaryFragColorEXT built-in.

Ilia Mirkin imirkin at alum.mit.edu
Tue Aug 23 03:10:12 UTC 2016


On Mon, Aug 22, 2016 at 10:55 PM, Francisco Jerez <currojerez at riseup.net> wrote:
> Ilia Mirkin <imirkin at alum.mit.edu> writes:
>
>> On Mon, Aug 22, 2016 at 9:59 PM, Francisco Jerez <currojerez at riseup.net> wrote:
>>> gl_SecondaryFragColorEXT should have the same location as gl_FragColor
>>> for the secondary fragment color to be replicated to all fragment
>>> outputs.  The incorrect location of gl_SecondaryFragColorEXT would
>>> cause the linker to mark both FRAG_RESULT_COLOR and FRAG_RESULT_DATA0
>>> as being written to, which isn't allowed by the spec and would
>>> ultimately lead to an assertion failure in
>>> fs_visitor::emit_fb_writes() on my i965-fb-fetch branch.
>>
>> My recollection was that it didn't work with COLOR for "stupid"
>> reasons. Can you confirm that
>> bin/arb_blend_func_extended-fbo-extended-blend-pattern_gles2 -auto
>> passes with this patch?
>>
> Yes, it does, in fact
> arb_blend_func_extended-fbo-extended-blend-pattern_gles2 hits the i965
> assertion failure I mentioned above unless this patch is applied.

This causes the test in question to fail on nouveau... the TGSI shader
generated starts with

FRAG
PROPERTY FS_COLOR0_WRITES_ALL_CBUFS 1
DCL IN[0], POSITION, LINEAR
DCL OUT[0], SAMPLEMASK
DCL OUT[1], COLOR
DCL CONST[2..3]
DCL CONST[0..1]
DCL TEMP[0]
DCL TEMP[1..2], LOCAL

So clearly something gets confused. I think this needs a bit more
investigation... without this patch, the header looks more like

FRAG
PROPERTY FS_COLOR0_WRITES_ALL_CBUFS 1
DCL IN[0], POSITION, LINEAR
DCL OUT[0], COLOR
DCL OUT[1], COLOR[1]


More information about the mesa-dev mailing list