[Mesa-dev] [RFC PATCH V3 00/10] ARB_gpu_shader5 interpolateAt* support for i965
Chris Forbes
chrisf at ijw.co.nz
Sat Nov 23 14:02:27 PST 2013
Third respin of the basic idea, with a complete-ish i965 backend now.
Works, except for a few things:
- Varying packing interaction is pretty bogus. Currently we look inside
the ir_swizzle that got generated, and don't correct for it, so this
only works for varyings which get packed into the start of a vec4.
- Nonconstant sample id is not supported. This should be done by a lowering
pass which converts it to ir_binop_interpolate_at_offset + reference to
a builtin uniform with the sample positions. V2 had a crude implementation
of this at the GLSL builtins level, but I haven't ported it yet.
- SIMD16 support is disabled in the backend due to the way the PI unit
interleaves the barycentric coordinates.
My plan from this point:
- Add four new ir expression opcodes:
- ir_collect_bary_centroid: () -> vec2
- ir_collect_bary_sample: int -> vec2
- ir_collect_bary_offset: vec2 -> vec2
- ir_interpolate_bary: vec* -> vec2 -> vec*
- Add a lowering pass which splits ir_interpolate_at_* into the appropriate pair
of the above. This will be used by at least i965, but might be useful to other
drivers.
- Add the missing lowering for nonconstant sample id. Again, this is something
i965 will want; other drivers may or may not need it.
- Rejig backend code to implement the new opcodes rather than ir_interpolate_*
directly. ir_collect_* will need to avoid splitting like I'm currently doing
for ir_interpolate_*; ir_interpolate_bary can be split normally [wrt its first
operand; the second must remain as a vec2].
The swizzle/varying-packing interaction should just fall out when this is done.
- Add CSE support for ir_collect_bary_* to avoid redundant messages.
- Fix up and enable SIMD16, if we care.
-- Chris
More information about the mesa-dev
mailing list