<div dir="ltr">On 26 June 2013 14:57, Anuj Phogat <span dir="ltr"><<a href="mailto:anuj.phogat@gmail.com" target="_blank">anuj.phogat@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="h5">On Tue, Jun 25, 2013 at 10:27 AM, Paul Berry <<a href="mailto:stereotype441@gmail.com">stereotype441@gmail.com</a>> wrote:<br>
> This seems like a lot of work to accomplish what is effectively a lookup<br>
> table. If this winds up becoming a performance bottleneck, you might want<br>
> to consider passing the table in via a push constant, and using indirect<br>
> addressing to convert sample index to sample number.<br>
><br>
</div>Yes, that would be helpful. Is it acceptable to do this optimization as a<br>
follow up patch?<br></blockquote><div><br></div><div>Yes, that seems completely reasonable.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div class="im">
> I'm confused why we need loops from 0 to 7 here. It looks like you're<br>
> trying to interpolate each component of the SIMD8 register separately. That<br>
> shouldn't be necessary.<br>
><br>
</div>Output of each SIMD16 sampler instruction (send) is written to 8 grf registers.<br>
So, I'm looping from 0 to 7 to interpolate all these 8 registers. If we lower<br>
the loop counter, we end up with color data 'not-interpolated' in few color<br>
channels. Does this explain your concern?<br></blockquote><div><br></div><div>Aha! The 8 comes from 4 color channels * 2 registers each (since we're doing SIMD16, and a register holds only 8 values). I get it now. A comment to explain this would probably be useful.<br>
<br></div><div>Thanks, Anuj!<br></div></div></div></div>