[Mesa-dev] [PATCH] ff_fragment_shader: Don't generate swizzles for scalar combiner inputs

Ian Romanick idr at freedesktop.org
Mon Jan 2 19:36:25 PST 2012


On 12/23/2011 10:35 PM, Eric Anholt wrote:
> On Thu, 22 Dec 2011 17:43:57 -0800, "Ian Romanick"<idr at freedesktop.org>  wrote:
>> From: Ian Romanick<ian.d.romanick at intel.com>
>>
>> There are a couple scenarios where the source could be zero and the
>> operand could be either SRC_ALPHA or ONE_MINUS_SRC_ALPHA.  For
>> example, if the source was ZERO.  This would result in something like
>> (0).w, and a later call to ir_validate would get angry.
>>
>> Signed-off-by: Ian Romanick<ian.d.romanick at intel.com>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42517
>
> In other cases of handling this in the code, I was using the little
> smear() helper function.  I'd tend towards using that here as well, but
> no strong feeling.

smear replicates the X component to all four components of a vec4.

This code either extracts the W component from a vec4 and returns it as 
a scalar, or it returns the scalar unmodified.

Do you think there should be a new helper function for this case?

> There's also a "bump = get_source(...)" in the bumpmap handling that
> looks like it could use the same treatment.

Technically, yes.  However, I don't think that can actually happen.  The 
(du, dv) value should always be obtained by reading a texture (via 
load_texenv_source a few lines earlier).  If we ever get something other 
than a vec4 as that source, there's a significant bug elsewhere.

Since this would cause another sort of failure, I'm not even sure an 
assertion is in order.  What do you think?

> I think I've reviewed all the other swizzles in the code now.



More information about the mesa-dev mailing list