ARB_texture_non_power_of_two and Mac
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.
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.
Re: ARB_texture_non_power_of_two and Mac
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.
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.
Re: ARB_texture_non_power_of_two and Mac
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.
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
We knew the words, we knew the score, we knew what we were fighting for
Re: ARB_texture_non_power_of_two and Mac
GL_ARB_texture_rectangle will require rewriting 2D drawing routines for texture coordinate addressing changes. Sigh..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
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:(or is supported in the driver but not hardware accelerated).
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?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.
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?
Re: ARB_texture_non_power_of_two and Mac
It was on Windows, and was with a GeForce FX. Both bad news.szo wrote: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?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.
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?
![Sad :(](./images/smilies/icon_sad.gif)
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
We knew the words, we knew the score, we knew what we were fighting for
Re: ARB_texture_non_power_of_two and Mac
I see, thank for the information.mh wrote:It was on Windows, and was with a GeForce FX. Both bad news.szo wrote: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?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.
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?
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.
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.
Re: ARB_texture_non_power_of_two and Mac
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.
Re: ARB_texture_non_power_of_two and Mac
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 ???)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.
Re: ARB_texture_non_power_of_two and Mac
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.szo wrote:However a test on a G4 Mac with an ATI Radeon 7550
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?
Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
![Cool 8)](./images/smilies/icon_cool.gif)
Re: ARB_texture_non_power_of_two and Mac
This is good to verify the low probability of hitting the issue out there, so thanks for the info.Baker wrote: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.szo wrote:However a test on a G4 Mac with an ATI Radeon 7550
And I'm rather confident that this applies to any modern era Mac.
Can you show some sample checks (or a link to the mentioned sources?)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.
Re: ARB_texture_non_power_of_two and Mac
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.szo wrote:Can you show some sample checks (or a link to the mentioned sources?)
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);
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!");
}
}
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?
Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
![Cool 8)](./images/smilies/icon_cool.gif)
Re: ARB_texture_non_power_of_two and 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 source is in a .dmg which is a disk image and I'm not sure how you can open that without using a Mac.
interesting, thanks.Baker wrote:But the code looks like this:[...snip...]Code: Select all
GL_CheckTextureRAM (GL_TEXTURE_2D, 0, gl_alpha_format, 64, 64, 0, 0, GL_RGBA, GL_UNSIGNED_BYTE);
Re: ARB_texture_non_power_of_two and Mac
I finally went ahead and and implemented a cvar solution for this, default being disabled. Here:
http://uhexen2.svn.sourceforge.net/view ... ision=4611
http://uhexen2.svn.sourceforge.net/view ... ision=4611
Re: ARB_texture_non_power_of_two and Mac
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
We knew the words, we knew the score, we knew what we were fighting for
Re: ARB_texture_non_power_of_two and Mac
Yeah. For that though, I'll need to overhaul the texture management in uhexen2 (may start by porting over Fitzquake/Quakespasm code.)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.