OTOY Forums

Hi , I just read this on Kepler´s whitepaper and wanted to know which is the number of textures that can handle kepler at the same time.


"Texture Improvements
The GPU’s dedicated hardware Texture units are a valuable resource for compute programs with a need
to sample or filter image data. The texture throughput in Kepler is significantly increased compared to
Fermi – each SMX unit contains 16 texture filtering units, a 4x increase vs the Fermi GF110 SM.
In addition, Kepler changes the way texture state is managed. In the Fermi generation, for the GPU to
reference a texture, it had to be assigned a “slot” in a fixed‐size binding table prior to grid launch. The
number of slots in that table ultimately limits how many unique textures a program can read from at run
time. Ultimately, a program was limited to accessing only 128 simultaneous textures in Fermi.
With bindless textures in Kepler, the additional step of using slots isn’t necessary: texture state is now
saved as an object in memory and the hardware fetches these state objects on demand, making binding
tables obsolete. This effectively eliminates any limits on the number of unique textures that can be
referenced by a compute program. Instead, programs can map textures at any time and pass texture
handles around as they would any other pointer".

badmilk69 wrote:Hi , I just read this on Kepler´s whitepaper and wanted to know which is the number of textures that can handle kepler at the same time.


"Texture Improvements
The GPU’s dedicated hardware Texture units are a valuable resource for compute programs with a need
to sample or filter image data. The texture throughput in Kepler is significantly increased compared to
Fermi – each SMX unit contains 16 texture filtering units, a 4x increase vs the Fermi GF110 SM.
In addition, Kepler changes the way texture state is managed. In the Fermi generation, for the GPU to
reference a texture, it had to be assigned a “slot” in a fixed‐size binding table prior to grid launch. The
number of slots in that table ultimately limits how many unique textures a program can read from at run
time. Ultimately, a program was limited to accessing only 128 simultaneous textures in Fermi.
With bindless textures in Kepler, the additional step of using slots isn’t necessary: texture state is now
saved as an object in memory and the hardware fetches these state objects on demand, making binding
tables obsolete. This effectively eliminates any limits on the number of unique textures that can be
referenced by a compute program. Instead, programs can map textures at any time and pass texture
handles around as they would any other pointer".

CUDA 5.0 introduced texture objects, which allow an unlimited number of textures, but for several reasons we don't use CUDA 5.0 yet and the texture object mechanism is only available for Kepler GPUs which are only used by a small minority. So we have decided to not implement them for now, since they work very differently to texture references and would require some major changes in our CUDA code.

Fortunately the maximum number of texture references increased to 256, which required only small changes in the code to leverage. -> Currently, with the release candidates, we allow 144 LDR RGBA textures, 68 LDR greyscale textures, 10 HDR RGBA textures and 10 HDR greyscale textures on Kepler GPUs. Of course all render GPUs must be Kepler GPUs.

Cheers,
Marcus