ARB_texture_non_power_of_two and Mac

[szo]

Recently I added support for NPOT textures to my uhexen2 engine by checking the existence of GL_ARB_texture_non_power_of_two in the extensions string as advertised by the driver, which seems to work fine on linux and windows in my limited testing. However a test on a G4 Mac with an ATI Radeon 7550 showed that it slowed things down ca.90% because the driver is lying about its NPOT capability especially when mipmap textures are in question. The last post in the following link has explanation about it:
http://www.idevgames.com/forums/printth ... 814&page=2
Do you guys know of a reliable way of detecting the lying drivers? Help with this would be very appreciated.

[Spike]

for things like that, I would just blacklist npot on all radeons, at least on mac. Add a cvar for users to unblacklist it again, if they know of the cvar.
My own engine has mesa blacklisted for glsl, although that's more to stop crashes and general non-compliance.
npot isn't by any means a vital feature.

[mh]

You could fall back on GL_ARB_texture_rectangle for the 2D stuff; the restrictions it imposes are fine in that case and it's more likely to be properly hardware accelerated in cases where full unconditional non-power-of-two support is unavailable (or is supported in the driver but not hardware accelerated).

I've seen the same problem happen on some older GeForces as well so I don't think that just blacklisting Radeons is going to give you a comprehensive fix.

[szo]

[mh]

[szo]

[Spike]

try checking for GL_APPLE_texture_2D_limited_npot? as far as I'm aware, its a gles-only extension, but you might get lucky.

[szo]

[Baker]

[szo]

[Baker]

[szo]

[szo]

I finally went ahead and and implemented a cvar solution for this, default being disabled. Here:
http://uhexen2.svn.sourceforge.net/view ... ision=4611

[mh]

I'd still pad the 2d stuff at least if not able to use npo2; the quality drop-off is just too much otherwise.

[szo]