ARB_texture_non_power_of_two and Mac

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.

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.

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.

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

GL_ARB_texture_rectangle will require rewriting 2D drawing routines for texture coordinate addressing changes. Sigh..

(or is supported in the driver but not hardware accelerated).

That was actually the main point of the question, i.e. how can I reliably detect that GL_ARB_texture_non_power_of_two is fully supported..

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.

Is this only with Mac, or did you experience it on windows or linux two? If the latter, then there is no guarantee at all that GL_ARB_texture_non_power_of_two is hardware accelerated for mipmaps?

EDIT: Also, would it be safe to assume that GL_ARB_texture_non_power_of_two is usable without mipmaps, i.e. 2D only, if it is advertised by the driver?

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.

Is this only with Mac, or did you experience it on windows or linux two? If the latter, then there is no guarantee at all that GL_ARB_texture_non_power_of_two is hardware accelerated for mipmaps?

EDIT: Also, would it be safe to assume that GL_ARB_texture_non_power_of_two is usable without mipmaps, i.e. 2D only, if it is advertised by the driver?

It was on Windows, and was with a GeForce FX. Both bad news.

Personally I had thought that the FX experience was an abberation before now, a case of NV claiming support for it in order to be able to claim GL2 but utterly unusable in practice; since you've observed it on Mac with a reasonably modern Radeon it does seem quite unreliable.

It's a problem I've hit with OpenGL before; there's actually no guarantee that anything at all is hardware accelerated and no facility to query the driver for hardware acceleration exists. But I would have hoped that in 2012 having to deal with this kind of crap, and/or do vendor/driver-specific workarounds, would have been a thing of the past.

Only thing I can think of might be to load some dummy textures at startup, spend a few frames drawing them, time it, and base a decision on that, but it seems a flaky way of doing it. On the other hand the performance drop-off is so severe that maybe it would work out quite well. With your Windows build you could create a D3D device and query that during startup - that will definitely tell you if you get hardware acceleration or not, but it's useless for Mac and Linux, of course.

An intelligent enough driver should be able to work out that you're using non_power_of_two in scenarios where it can be accelerated and do the right thing, but you're reliant on the driver.

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.

Is this only with Mac, or did you experience it on windows or linux two? If the latter, then there is no guarantee at all that GL_ARB_texture_non_power_of_two is hardware accelerated for mipmaps?

EDIT: Also, would it be safe to assume that GL_ARB_texture_non_power_of_two is usable without mipmaps, i.e. 2D only, if it is advertised by the driver?

It was on Windows, and was with a GeForce FX. Both bad news.

Personally I had thought that the FX experience was an abberation before now, a case of NV claiming support for it in order to be able to claim GL2 but utterly unusable in practice; since you've observed it on Mac with a reasonably modern Radeon it does seem quite unreliable.

It's a problem I've hit with OpenGL before; there's actually no guarantee that anything at all is hardware accelerated and no facility to query the driver for hardware acceleration exists. But I would have hoped that in 2012 having to deal with this kind of crap, and/or do vendor/driver-specific workarounds, would have been a thing of the past.

Only thing I can think of might be to load some dummy textures at startup, spend a few frames drawing them, time it, and base a decision on that, but it seems a flaky way of doing it. On the other hand the performance drop-off is so severe that maybe it would work out quite well. With your Windows build you could create a D3D device and query that during startup - that will definitely tell you if you get hardware acceleration or not, but it's useless for Mac and Linux, of course.

An intelligent enough driver should be able to work out that you're using non_power_of_two in scenarios where it can be accelerated and do the right thing, but you're reliant on the driver.

I see, thank for the information.

Don't know about other extensions but for the NPOT case together with the
unacceptable framerate drop the situation is pretty much disgusting to put
it politely.

The only reliable way seems like providing the NPOT support as an option
bound to a cvar with default as disabled, and do a Draw_ReIinit upon user's
request.

Thanks again.

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.

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.

MH said that the Nvidia also lies about it with GeForce FX on windows, so this doesn't seem like a Mac-only limitation. (Or, are you saying that NV really advertises GL_APPLE_texture_2D_limited_npot on windows for GF/FX ???)

However a test on a G4 Mac with an ATI Radeon 7550

I just want to point out that a G4 Mac is at best 2004 era and old PowerPC chip. Not that this observation is material to the problem at hand, but my Macbook Pro with a Radeon of does non-power of two just fine.

And I'm rather confident that this applies to any modern era Mac.

Those old era Macs with Radeons had a lot of quirks it would seem as the Fruitz of Dojo 1.2 version had all kinds of texture memory checking and a few odd workarounds here and there.

Dumb question ... is there a "good" reason to not pad images (not upscale, just pad) up to the power of two and store the tex coords for the texture as a float?

However a test on a G4 Mac with an ATI Radeon 7550

I just want to point out that a G4 Mac is at best 2004 era and old PowerPC chip. Not that this observation is material to the problem at hand, but my Macbook Pro with a Radeon of does non-power of two just fine.

And I'm rather confident that this applies to any modern era Mac.

This is good to verify the low probability of hitting the issue out there, so thanks for the info.

Those old era Macs with Radeons had a lot of quirks it would seem as the Fruitz of Dojo 1.2 version had all kinds of texture memory checking and a few odd workarounds here and there.

Can you show some sample checks (or a link to the mentioned sources?)

Can you show some sample checks (or a link to the mentioned sources?)

Well the Fruitz of Dojo 1.2 page is here (http://www.fruitz-of-dojo.de/php/download.php4?dlnr=2). But the source is in a .dmg which is a disk image and I'm not sure how you can open that without using a Mac.

But the code looks like this:

  Code:

GL_CheckTextureRAM (GL_TEXTURE_2D, 0, gl_alpha_format, 64, 64, 0, 0, GL_RGBA, GL_UNSIGNED_BYTE);

And that function looked like this:

  Code:

void   GL_CheckTextureRAM (GLenum theTarget, GLint theLevel, GLint theInternalFormat, GLsizei theWidth,
                            GLsizei theHeight, GLsizei theDepth , GLint theBorder, GLenum theFormat,
                            GLenum theType)
{
    GLint   myWidth = -1;
    GLenum   myError,
         myTarget;
   
    // flush existing errors:
    glGetError ();

    // check our target texture type:
    switch (theTarget)
    {
        case GL_TEXTURE_1D:
        case GL_PROXY_TEXTURE_1D:
            myTarget = GL_PROXY_TEXTURE_1D;
            glTexImage1D (myTarget, theLevel, theInternalFormat, theWidth, theBorder, theFormat, theType, NULL);
            break;
        case GL_TEXTURE_2D:
        case GL_PROXY_TEXTURE_2D:
            myTarget = GL_PROXY_TEXTURE_2D;
            glTexImage2D (myTarget, theLevel, theInternalFormat, theWidth, theHeight, theBorder, theFormat,
                          theType, NULL);
            break;
        case GL_TEXTURE_3D:
        case GL_PROXY_TEXTURE_3D:
            myTarget = GL_PROXY_TEXTURE_3D;
            glTexImage3D (myTarget, theLevel, theInternalFormat, theWidth, theHeight, theDepth, theBorder,
                          theFormat, theType, NULL);
            break;
        default:
            return;
    }
   
    myError = glGetError ();

    // get the width of the texture [should be zero on failure]:
    glGetTexLevelParameteriv (myTarget, theLevel, GL_TEXTURE_WIDTH, &myWidth);
   
    // now let's see if the width is equal to our requested value:
    if (myError != GL_NO_ERROR || theWidth != myWidth)
    {
        Sys_Error ("Out of texture RAM. Please try a lower resolution and/or depth!");
    }
}

By the way, if I am correct those old Mac G4 had like 32 MB or 64 MB of texture memory.

http://www.everymac.com/systems/apple/p ... p_mdd.html

  Code:

/*
=============
Draw_TransPicTranslate

Only used for the player color selection menu
=============
*/
void Draw_TransPicTranslate (int x, int y, qpic_t *pic, byte *translation)
{
   int            v, u, c, p;
   unsigned      trans[64*64], *dest;
   byte         *src;

   GL_Bind (translate_texture);

   c = pic->width * pic->height;

   dest = trans;
   for (v=0 ; v<64 ; v++, dest += 64)
   {
      src = &menuplyr_pixels[ ((v*pic->height)>>6) *pic->width];
      for (u=0 ; u<64 ; u++)
      {
         p = src[(u*pic->width)>>6];
         dest[u] = (p == 255) ? p : d_8to24table[translation[p]];
      }
   }

#ifdef MACOSX_TEXRAM_CHECK
        GL_CheckTextureRAM (GL_TEXTURE_2D, 0, gl_alpha_format, 64, 64, 0, 0, GL_RGBA, GL_UNSIGNED_BYTE);
#endif /* MACOSX */

   glTexImage2D (GL_TEXTURE_2D, 0, gl_alpha_format, 64, 64, 0, GL_RGBA, GL_UNSIGNED_BYTE, trans);

   glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
   glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);

   glColor3f (1,1,1);
   glBegin (GL_QUADS);
   glTexCoord2f (0, 0);
   glVertex2f (x, y);
   glTexCoord2f (1, 0);
   glVertex2f (x+pic->width, y);
   glTexCoord2f (1, 1);
   glVertex2f (x+pic->width, y+pic->height);
   glTexCoord2f (0, 1);
   glVertex2f (x, y+pic->height);
   glEnd ();
}

But the source is in a .dmg which is a disk image and I'm not sure how you can open that without using a Mac.

7z (from the p7zip project) extracts it on my linux: "7z x *.dmg" reveals an *.hfs file, and then "7z x *.hfs" extracts the real thing.

But the code looks like this:

  Code:

GL_CheckTextureRAM (GL_TEXTURE_2D, 0, gl_alpha_format, 64, 64, 0, 0, GL_RGBA, GL_UNSIGNED_BYTE);

[...snip...]

interesting, thanks.

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

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

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

Yeah. For that though, I'll need to overhaul the texture management in uhexen2 (may start by porting over Fitzquake/Quakespasm code.)