[Mesa-dev] [PATCH 1/2] glsl: Fix lowering of direct assignment in lower_clip_distance.

Eric Anholt eric at anholt.net
Mon Nov 25 15:02:08 PST 2013


Paul Berry <stereotype441 at gmail.com> writes:

> In commit 065da16 (glsl: Convert lower_clip_distance_visitor to be an
> ir_rvalue_visitor), we failed to notice that since
> lower_clip_distance_visitor overrides visit_leave(ir_assignment *),
> ir_rvalue_visitor::visit_leave(ir_assignment *) wasn't getting called.
> As a result, clip distance dereferences appearing directly on the
> right hand side of an assignment (not in a subexpression) weren't
> getting properly lowered.  This caused an ir_dereference_variable node
> to be left in the IR that referred to the old gl_ClipDistance
> variable.  However, since the lowering pass replaces gl_ClipDistance
> with gl_ClipDistanceMESA, this turned into a dangling pointer when the
> IR got reparented.
>
> Prior to the introduction of geometry shaders, this bug was unlikely
> to arise, because (a) reading from gl_ClipDistance[i] in the fragment
> shader was rare, and (b) when it happened, it was likely that it would
> either appear in a subexpression, or be hoisted into a subexpression
> by tree grafting.
>
> However, in a geometry shader, we're likely to see a statement like
> this, which would trigger the bug:
>
>     gl_ClipDistance[i] = gl_in[j].gl_ClipDistance[i];

These two are:

Reviewed-by: Eric Anholt <eric at anholt.net>

I didn't follow how gl_in[j].gl_ClipDistance[i] is a bare struct deref
of the thing needing to be lowered, since it reads to me like there's an
array and struct dereference first.  But I assume that's just me not
understanding how gl_in[] works.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131125/dbb92efb/attachment.pgp>


More information about the mesa-dev mailing list