then, back to business, I support for a long time the SGIS_generate_mipmap extension for NVidia products.
I disabled this extension a long time ago for Radeon boards as I can’t have it working properly.
I made a few tests with the latest ATI drivers and the extension still does not work. It seems that only the first mipmap (level 0) is OK, the others are filled with black and occasional noise.
I was wondering if anyone here has successful experience with SGIS_generate_mipmap on Radeon 8500 boards ?
I start to be suspicious about my code, but it works with NVidia boards - it looks like this :
if (SUPPORTS_GL_SGIS_generate_mipmap)
{
//- fast - hardware accelerated - mipmap generation
glTexParameteri(m_textureTarget, GL_GENERATE_MIPMAP_SGIS, TRUE);
glTexImage2D(m_textureTarget, 0, GL_internal_representation, w, h, 0, imageRepresentation, GL_UNSIGNED_BYTE, imgBits);
glTexParameteri(m_textureTarget, GL_GENERATE_MIPMAP_SGIS, FALSE);
}
else
{
//- good old way
gluBuild2DMipmaps(m_textureTarget, GL_internal_representation, w, h, imageRepresentation, GL_UNSIGNED_BYTE, imgBits);
}
thanks for the tip - it behaves the same here! I’ll try to figure out some trick that won’t let the TexParameter enabled forever and I’ll see what ATI can tell about this.
This looks like a validation issue. If you were to draw with the texture before disabling gen mipmaps, then it will probably work reliably. A fix for this is being implemented.
(gf2mx200) ive had to disable this extension cause it causes major slowdowns ingame (not the 25% as claimed but more like 2500%)
ive found this is very dependant on texture size.
eg (with generate mipmap on)
glTexSubImage(…) on a 512x512 sized image fast
glTexSubImage(…) on a 1024x1024 sized image very slow (but with generate mm off then its fast)
does anyone have an idea why this is happening, or some hints about how better to use this extrension
It may be that the GF2MX doesn’t actually hardware accelerate the generation of that large texture, but instead falls back to some software implementation, but that implementation may be fairly efficient. However, even the most efficient software implementation is going to temporarily choke on 1024x1024 textures.
Personally, I’ve settled on using DDS files with pre-generated MIP maps. These let me use a high quality DDS compressor for saving texture space, and also let me control MIP map generation (like, what happens to alpha etc).
Not sure what the root cause is. My first guess is that mipmap generation would be slower if the texture map doesn’t fit into video memory. Hardware mipmap generation also isn’t supported for all texture formats, but that doesn’t seem to be the problem here.
this is for when i bake in the decals from explosions (in game) so pregenerationaint an option but yes generating your own mipmaps is desirable eg normapmaps or when u want more control of the smaller mipmaps
>>Not sure what the root cause is. My first guess is that mipmap generation would be slower if the texture map doesn’t fit into video memory. Hardware<<
this is what i believe is happening, i think ill give the option of disabling/enabling it as other hardware may far better/worse.
>>mipmap generation also isn’t supported for all texture formats, but that doesn’t seem to be the problem here.<<
yes ive read that (IIRC 3 formats are suppotred) but like u say this would affect all sizes