ARB_texture_non_power_of_two and Mac

Discuss programming topics that involve the OpenGL API.
Post Reply
szo
Posts: 132
Joined: Mon Dec 06, 2010 4:42 pm

ARB_texture_non_power_of_two and Mac

Post by 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
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: ARB_texture_non_power_of_two and Mac

Post by 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
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: ARB_texture_non_power_of_two and Mac

Post by 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.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
szo
Posts: 132
Joined: Mon Dec 06, 2010 4:42 pm

Re: ARB_texture_non_power_of_two and Mac

Post by szo »

mh wrote: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..
mh wrote:(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..
mh wrote: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?
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: ARB_texture_non_power_of_two and Mac

Post by mh »

szo wrote:
mh wrote: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.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
szo
Posts: 132
Joined: Mon Dec 06, 2010 4:42 pm

Re: ARB_texture_non_power_of_two and Mac

Post by szo »

mh wrote:
szo wrote:
mh wrote: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.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: ARB_texture_non_power_of_two and Mac

Post by 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
Posts: 132
Joined: Mon Dec 06, 2010 4:42 pm

Re: ARB_texture_non_power_of_two and Mac

Post by szo »

Spike wrote: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 ???)
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: ARB_texture_non_power_of_two and Mac

Post by Baker »

szo wrote: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?
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
szo
Posts: 132
Joined: Mon Dec 06, 2010 4:42 pm

Re: ARB_texture_non_power_of_two and Mac

Post by szo »

Baker wrote:
szo wrote: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.
Baker wrote: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?)
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: ARB_texture_non_power_of_two and Mac

Post by Baker »

szo wrote: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: Select all

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: Select all

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: Select all

/*
=============
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 ();
}
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
szo
Posts: 132
Joined: Mon Dec 06, 2010 4:42 pm

Re: ARB_texture_non_power_of_two and Mac

Post by szo »

Baker wrote: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.
Baker wrote:But the code looks like this:

Code: Select all

GL_CheckTextureRAM (GL_TEXTURE_2D, 0, gl_alpha_format, 64, 64, 0, 0, GL_RGBA, GL_UNSIGNED_BYTE);
[...snip...]
interesting, thanks.
szo
Posts: 132
Joined: Mon Dec 06, 2010 4:42 pm

Re: ARB_texture_non_power_of_two and Mac

Post by 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
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: ARB_texture_non_power_of_two and Mac

Post by 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.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
szo
Posts: 132
Joined: Mon Dec 06, 2010 4:42 pm

Re: ARB_texture_non_power_of_two and Mac

Post by szo »

mh wrote: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.)
Post Reply