Neil Roberts <n...@linux.intel.com> writes: > 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. > 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
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
