I have an NVidia GeForce 6800 running on a PC with PCI Express
and using the Forceware 81.95 drivers.  The card has 8 texture
units.  However, when I query the OpenGL driver with
    GLint iMaxTextures;
    glGetIntegerv(GL_MAX_TEXTURE_UNITS,&iMaxTextures);
the value reported is 4.  In the DirectX version of my renderer,
the device caps report a value of 8.

Anyone else seeing this problem?  Am I missing something here,
maybe one of those overriding desktop properties settings?

The driver information is
    vendor = "NVIDIA Corporation"
    renderer = "GeForce 6800/PCI/SSE2"
    version = "2.0.1"
    glu version = <null pointer>

--
Dave Eberly
http://www.geometrictools.com 

Hi Dave,

I've noted the same behavior. It seems that nvidia's standard multitexture 
implementation wasn't extended with more than 4 texture units (I'm not 
entirely sure since i havent fed it with invalid values to test it). If you 
use fragment programs there is always GL_MAX_TEXTURE_IMAGE_UNITS_ARB to 
exploit the extra texture units. Note that you can use the glActiveTexture 
and glBindTexture with a seemingly invalid texture unit 
(GL_MAX_TEXTURE_UNITS < x < GL_MAX_TEXTURE_IMAGE_UNITS_ARB), as long as the 
texture lookup is done in a fragment program.

Jon

"Dave Eberly" <dNOSPAMeberly@usemydomain.com> wrote in message 
news:PlMAf.11268$ZA2.1009@newsread1.news.atl.earthlink.net...
>I have an NVidia GeForce 6800 running on a PC with PCI Express
> and using the Forceware 81.95 drivers.  The card has 8 texture
> units.  However, when I query the OpenGL driver with
>    GLint iMaxTextures;
>    glGetIntegerv(GL_MAX_TEXTURE_UNITS,&iMaxTextures);
> the value reported is 4.  In the DirectX version of my renderer,
> the device caps report a value of 8.
>
> Anyone else seeing this problem?  Am I missing something here,
> maybe one of those overriding desktop properties settings?
>
> The driver information is
>    vendor = "NVIDIA Corporation"
>    renderer = "GeForce 6800/PCI/SSE2"
>    version = "2.0.1"
>    glu version = <null pointer>
>
> --
> Dave Eberly
> http://www.geometrictools.com
> 

"Jon Hasselgren" <spam@sucks.com> wrote in message 
news:%xOAf.43007$d5.199200@newsb.telia.net...

> I've noted the same behavior. It seems that nvidia's standard multitexture 
> implementation wasn't extended with more than 4 texture units (I'm not 
> entirely sure since i havent fed it with invalid values to test it). If 
> you use fragment programs there is always GL_MAX_TEXTURE_IMAGE_UNITS_ARB 
> to exploit the extra texture units. Note that you can use the 
> glActiveTexture and glBindTexture with a seemingly invalid texture unit 
> (GL_MAX_TEXTURE_UNITS < x < GL_MAX_TEXTURE_IMAGE_UNITS_ARB), as long as 
> the texture lookup is done in a fragment program.

Thanks for the verification.  I queried for GL_MAX_TEXTURE_IMAGE_UNITS_ARB
and got 16, which agrees (of course) with the technical information at 
NVidia's
web site.  Now I have to wonder why DirectX only reports 8 simultaneous
textures.  I'll have to experiment to see what happens when I go past the
incorrectly reported limit.   I am rewriting my renderers to be based only 
on
shader programs (no fixed function support), so the query of
GL_MAX_TEXTURE_IMAGE_UNITS_ARB works for me.

--
Dave Eberly
http://www.geometrictools.com

Dave Eberly wrote:
> I have an NVidia GeForce 6800 running on a PC with PCI Express
> and using the Forceware 81.95 drivers.  The card has 8 texture
> units.  However, when I query the OpenGL driver with
>     GLint iMaxTextures;
>     glGetIntegerv(GL_MAX_TEXTURE_UNITS,&iMaxTextures);
> the value reported is 4.  In the DirectX version of my renderer,
> the device caps report a value of 8.
> 
> Anyone else seeing this problem?  Am I missing something here,
> maybe one of those overriding desktop properties settings?
> 
> The driver information is
>     vendor = "NVIDIA Corporation"
>     renderer = "GeForce 6800/PCI/SSE2"
>     version = "2.0.1"
>     glu version = <null pointer>
> 
> --
> Dave Eberly
> http://www.geometrictools.com 

What exactly is a texture "unit" here?

The hardware supports 16 texture images and enough general purpose 
vertex and fragment attributes to implement 8 or more texture coord 
sets.  If you write your own shaders you can use as many of these as you 
wish, up to the hardware limits.  To take advantage of all 16 available 
texture images, you may use one texture coord for multiple images, or 
you may derive one texture coord from another in the shader.

Fixed function is dead  - the implementation already generates shaders 
on your behalf when you use TexEnv or register combiners.  The driver 
team made the decision not to aggrandize this abstraction by pretending 
there are more texture units.  Writing your own shader is not only more 
efficient, it also provides tremendous flexibility above and beyond that 
which can be achieved through fixed function.

See also: Cg, GLSL, ARB_fragment_program

"Michael I Gold" <goldHI@THEREberkelium.com> wrote in message 
news:43d3cc2e$1@news.meer.net...

> What exactly is a texture "unit" here?
>
> The hardware supports 16 texture images and enough general purpose vertex 
> and fragment attributes to implement 8 or more texture coord sets.  If you 
> write your own shaders you can use as many of these as you wish, up to the 
> hardware limits.  To take advantage of all 16 available texture images, 
> you may use one texture coord for multiple images, or you may derive one 
> texture coord from another in the shader.
>
> Fixed function is dead  - the implementation already generates shaders on 
> your behalf when you use TexEnv or register combiners.  The driver team 
> made the decision not to aggrandize this abstraction by pretending there 
> are more texture units.  Writing your own shader is not only more 
> efficient, it also provides tremendous flexibility above and beyond that 
> which can be achieved through fixed function.
>
> See also: Cg, GLSL, ARB_fragment_program

Thank you for the detailed description.  Yes, fixed function is dead,
and I am in the process of killing the support for it in my own engine.
The problem is that when you have built an engine on top of the fixed
function pipeline, a rewrite requires identifying those portions that need
to be deleted or replaced.  This is not always easy to identify when
a graphics API is designed not to "break" when you add new features
and designed not to "deprecate" things.  The query of GL_MAX_TEXTURE_UNITS
is part of code that is 5 years old.  The only reason I noticed the
problem with the number of "texture units" is that I was debugging a
system designed to make certain that a (Cg) shader program does not
require more "resources" than what the graphics card supports.

The simple goal for the query was to verify that the hardware can
support the number of samplers required by a Cg program.  It is
easy enough to figure out how many samplers the program
requires :)   The problem is knowing what query to make to figure
out what the hardware supports.  The suggestion about querying
GL_MAX_TEXTURE_IMAGE_UNITS_ARB appears to be the answer.

--
Dave Eberly
http://www.geometrictools.com