Oh, and I almost forgot. I also need to know if there’s any advantage to using textures of float4 as opposed to a texture that is 4 times larger but consists of floats. And same question for global arrays.
Of course. Although writes are only guaranteed to be fully flushed out after a kernel call completes. In particular, you cannot write to a memory location and expect to have another thread read it from a bound texture in the same kernel call.
Binding a texture takes less time than the overhead of launching a kernel.
Yes, it can be worth it, depending on your memory access pattern.
With textures, float4 is a clear win over just reading floats. With global memory, the difference is only a few percent.
I’d like to jump in here and ask a tangental question…
been reading about texture memory, but purely from a number cruncher’s perspective, not from the graphics programming angle. But the more I read, the more curious I am about how textures are applied in graphics at this low-level. (I understand the concepts of textures generally, but would like to understand better how they work mathematically.)
Is it just interpolation and, say, mulitplication affecting a value’s sample in a greater waveform (e.g. a surface element) … or much more complex as in FFT / convolution?
I googled the topic - and got somewhat overwhelming results - lots of people are doing graphics these days :blink:
A link to a good primer that deals specifically with the GPU’s texturing techniques - at this nitty gritty thread level - would be wonderful…
From a computational perspective you can think of textures simply as 2D tables with interpolation.
In graphics, texture maps were originally used simply to apply images to surfaces (modulating the surface color), but these days they are used for a wide variety of other effects (bump maps, shadows, image processing etc.), and the hardware includes support for different texture types (such as cube maps) and advanced features like anisotropic filtering.