Francisco Jerez <curroje...@riseup.net> writes: > Sigh, it's really awful that our hardware only supports a single sample > index for the whole SIMD thread... I was thinking though that there > might be a better alternative to running the sample-index interpolator > query in a loop: The "Per Slot Offset" interpolator query does allow > independent offsets for each channel, couldn't we pass the hard-coded > table of sample offsets (see brw_multisample_state.h) to the shader > (e.g. as push constants or hard-coded as vector immediates), use VxH > indirect indexing to fetch the right offset for each channel and then > lower it into a non-dynamically-uniform interpolateAtOffset, which the > hardware can handle natively?
Oh, that sounds like a neat trick! I think if we did that we'd have to use push constants rather than vector immediates because otherwise we'd have to recompile the program if it is used with a different sample count, right? That would be a shame. On the other hand I don't think we know any actual use cases of calling interpolateAtSample yet so it might be better to just pick whichever implementation works with the least hassle and then we can optimise it later if it is shown to be important for some application. Having to upload uniforms depending on the sample count could be a bit fiddly to implement. Regards, - Neil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
