fix: pass the real number of channels to rs_texture and rs_texture3d on gpu

[lgritz]

These were discovered when moving SPI's renderer to the the current release and switching to use the rs_ functions.

[lgritz]

The Windows tests are failing because of unrelated issue #2003.

I think I've made a mistake in the OptiX parts, actually. Don't review yet, I think this still needs a little work.

[lgritz]

Eew, there is some confusion about how the rs_texture family of functions should work. The parameters are passed as (int nchans, float* result) (I'm simplifying), and in some parts of the code, we act as if result was an array of nchans, but in other places we seem to assume that it's always a pointer to float[4], and it's up to the caller to later copy out individual floats if needed.

It might be worth noting that for the old RendererServices, the texture methods also pass int nchans, float* result and expect that it's result[nchans]. But WITHIN the implementation, there is a lower level that assumes float[4] in order to use some SIMD acceleration.

So do we imagine rs_texture to be a direct substitute (in a sense) for RenderServices::texture(), or is it more analogous to the hidden thing in side RS::texture that knows it has a float[4] to deal with? Which would you like it to be?

Now that I've written the above, I think that it makes most sense for rs_texture to mimic RendererServices::texture, in that the fact that we pass nchans at all makes me think that it's supposed to only touch result[0..nchans-1] and not just jam a float4 in there.

But if you disagree strongly, speak up before I finish fixing it all.

[lgritz]

Never mind that last comment. I think I have it all fixed already, was just one spot making a bad assumption. Obviously, rs_texture ought to have the same meaning of its parameters as RendererServices:texture did.

[lgritz]

@chellmuth @aconty This is a necessary step to get Spear fully caught up.

[aconty]

Good catch!

[sfriedmapixar]

Looks good to me.