> Desiging a texel fetch unit that can use NPT sizes is possible, and has been possible, but certainly not as efficient as for PT sizes, as you say. If it was impossible, I can clearly see a reason not to include NPT sizes in the spec, but now that isn't the case.

Please keep in mind, *when* the spec for OpenGL was created. People didn't even thought about NPT textures at that time.

> If a hardware manufacturer can't/don't want to make a hardware texel fetch unit with support for NPT sizes (assuming it's in the spec), then the manufacturer is free not to do so, and let the driver do the texturing in software instead, when NPT textures are used.

Texturing is an integral feature of OpenGL. If the specs would allow any texture size, then a hardware manufacturer *needs* to include that in hardware, or no texturing at all (which, again, is against the specs). Otherwise, he would be modifying / implying something that was not mentioned in the specs, and he wouldn't get certified by SGI. You can't just build in a limitation that wasn't mentioned in the specs. Even if the functionality would be there (through software mode), it is next to useless: Developpers would use any texture size, since they are allowed to do so in the specs. The manufacturer with his PT-only card would be killed on the market in no time, since his board wouldn't accelerate 99.9% of the apps/games out there...

> Limiting a spec to what the hardware is capable of at that time is not what I consider optimal.

Of course it's not optimal. But what do you consider optimal ? Including every possible feature, that may (or may not) be developped in the next 10 years ? Doesn't work that way. If you want an ever changing API that tries to do that (and fails), getting incompatible to itself at every major version update, then you should use Direct3D instead...

And I believe, the PT limit is gone in OpenGL 2.0 (though I'm not 100% sure).


Edited by - Yann L on February 28, 2002 11:27:36 AM