GeForce FX texture related resources

The purpose of this posting is to help you understand the various texture-related resources available to NVIDIA GPUs, particularly for the GeForce FX and Quadro FX family of GPUs (as well as earlier NVIDIA GPUs).

On GeForceFX and QuadroFX GPUs (ie, NV3x) OpenGL drivers, these are the NV_fragment_program & ARB_multitexture implementation dependent limits:

valueof(GL_MAX_TEXTURE_UNITS_ARB) = 4
valueof(GL_MAX_TEXTURE_COORDS_NV) = 8
valueof(GL_MAX_TEXTURE_IMAGE_UNITS) = 16

All future GeForce FX/Quadro FX GPUs will support 8 texture coorindate sets and 16 texture image units, even the most inexpensive GeForce FX/Quadro FX GPU.

Here are the GeForce 256, GeForce2, and GeForce4 MX (ie, NV1x), and TNT and TNT2 (ie, NV4) limits:

valueof(GL_MAX_TEXTURE_UNITS_ARB) = 2
valueof(GL_MAX_TEXTURE_COORDS_NV) = 2 *
valueof(GL_MAX_TEXTURE_IMAGE_UNITS) = 2 *

Here are the GeForce3, Quadro DCC, and GeForce4 Ti (ie, NV2x) limits:

valueof(GL_MAX_TEXTURE_UNITS_ARB) = 4
valueof(GL_MAX_TEXTURE_COORDS_NV) = 4 *
valueof(GL_MAX_TEXTURE_IMAGE_UNITS) = 4 *

  • = effective value since ARB_fragment_program and NV_fragment_program not actually supported.

What this means is that if you use texture units beyond 0-3, you need to write fragment programs. Fragment programs are considerably more powerful and considerably easier to write because you can use the Cg compiler and/or run-time to generate ARB_fragment_program and/or NV_fragment_program code for you.

Here’s a comprehensive list of which limit is used for setting which texture-related state:

depends on num texture units
glEnable/glDisable(GL_TEXTURE_xxx)
glTexEnv/glGetTexEnv(GL_TEXTURE_ENV_MODE, …)
glTexEnv/glGetTexEnviv(GL_TEXTURE_SHADER_NV, …)
glFinalCombinerInput()
glCombinerInput()
glCombinerOutput()

depends on num texture coordinate sets
glEnable/glDisable(GL_TEXTURE_GEN_xxx)
glTexGen(…)
glMatrixMode(GL_TEXTURE)/glLoadIdenity/glLoadMatrix/glRotate/…
glPointParameter(GL_POINT_SPRITE_R_MODE_NV, …)
glTexEnv/glGetTexEnv(GL_POINT_SPRITE_NV, …)
glClientActiveTexture(…)
glMultTexCoord(…)

The NV_vertex_program, NV_vertex_program1_1, and NV_vertex_program2 extensions specify which texture coordinate set an output goes to with the syntax “TEX#” where # is from 0 to 7. ARB_vertex_program specifies which texture coordinate set an output to with the syntax “result.texcoord[#]”.

depends on num texture image units
glTexImageXXX(…)
glGetTexImage(…)
glTexSubImageXXX(…)
glCopyTexImageXXX(…)
glCopySubTexImageXXX(…)
glTexParameter/glGetTexParameter(…)
glColorTable/glGetColorTable(GL_TEXTURE_xxx/GL_PROXY_TEXTURE_xxx, …)
glCopyColorTable/glCopyColorSubTable(GL_TEXTURE_xxx/GL_PROXY_TEXTURE_xxx, …)
glGetColorTableParameter(GL_TEXTURE_xxx/GL_PROXY_TEXTURE_xxx, …)
glTexEnv/glGetTexEnv(GL_TEXTURE_FILTER_CONTROL_EXT, …)
glGetTextureLevelParameter(…)
glBindTexture(…)

The ARB_fragment_program and NV_fragment_program extensions specify which texture image unit a fragment program texture instruction should sample.

NV_fragment_program specifies texture image units with the syntax “TEX#, <target>” where # is between 0 and 15, and <target> is one of 1D, 2D, 3D, CUBE (cube map), or RECT (texture rectangle). ARB_fragment_program specifies texture image units with the syntax “texture[#], <target>”.

glGet depends on how the gotten state corresponds to how the state is set based on the above list.

I hope this helps.

  • Mark

I’ll ask for more: how about texture formats?

I’m especially interested in 10 and 16-bit per channel fixed-point formats.

Several Microsoft’s presentations about DX9 suggest availablity of such formats in new HW generation. Here is a “screenshot” from .ppt:

DXG9 Surface Formats 

 Format  | Filter | Blend
---------+--------+-------
 AGBR8   |   y    |   y
 ABGR10  |   y    |   y
 ABGR16  |   y    |   n
 ABGR16f |   n    |   n
 ABGR32f |   n    |   n

These “filter” and “blend” restrictions must have came from specific HW, I guess. I believe these fixed-point formats could be supported quietly, without any new extension, so that could explain lack of any information about them.

I realize I can use pack/unpack of NV FP to get 16-bit per channel fixed-point format functionality, but I’m interested in availablity of regular texture/pixel formats of that precision.

NV30 emulation doesn’t expose any 16 or 10 bit fixed-point pixel format.

BTW, I’m interested in R300’s capablities as well.

The R300 supports all internal formats up to 16bit/channel (GL_RGBA16) with out extensions, and of course theres the floating point extension too.

The ATI guys can correct me if I’m wrong of course.

Thanks. This, I suppose, was about texture formats. But how about pixel formats? I’m most curious about the 10-10-10-2.

Haven’t seen anything on a 10-10-10-2 format, but here’s a list of formats: http://www.area3d.net/file.php?filename=nitrogl/pixelformats.txt

UNSIGNED_HILO16 is a 2 channel 16-bit/component integer format.

Besides the hardware issues, is there any particular reason why we only get 8 texture coordinates when we have 16 different maps avaliable?

Korval,

I believe generating more “interpolands” is significantly hard (because they need to be perspective correct, perhaps?) but that supporting more logical texture units might be easier (on the order of a wider texture fetch cache or something).

Also, I believe that some textures will usually be sampled with dependent reads, and/or with the same texture coordinates (unique color and normal maps) so it’s probably likely it’s a decent balance. However, interpolating tangent bases sucks up a lot of interpolands, so I’m sure we’ll soon see some nice rendering technique that “would run just fine, if only I had 10 sets of texture coordinates” :slight_smile: