[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