[Mesa-dev] [PATCH v2 2/2] i965/fs: Handle non-const sample number in interpolateAtSample

[Francisco Jerez]

Neil Roberts <neil at linux.intel.com> writes:

> Francisco Jerez <currojerez at 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.
>
I guess you could still get around with immediates if you hard-coded the
offsets for *all* MS modes inside a single table (How much data is it in
total?  4 dwords?) and use one set of values or other depending on the
num samples parameter (e.g. by indexing by 'num_samples + sample_idx' so
you know that each sample index gets a unique location in the table for
each multisample mode).  Although yeah passing the right table as push
constants might be easier.

> 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.
>
Sounds OK to me, I'm all for KISS for now until we find some important
use-case for this.

> Regards,
> - Neil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 212 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20151002/90b2a0f5/attachment.sig>