Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I simply draw something into a render target, and use it as an normal texture. It's always working greate to me with my nvidia video card. But today I found my program ran terribly slow (less than 5 fps) on a intel card.

After running an analyse I found glGenerateMipmapEXT is the trouble maker, it costs most of the cpu time. Here's how I bind a RT texture:

  glBindTexture(GL_TEXTURE_2D, m_textureID);<br>

without glGenerateMipmapEXT the texture is nothing but pure white pic. Something wrong with my RTT?

share|improve this question
Are you generating mipmaps every frame? – AttackingHobo Sep 1 '11 at 16:24
@AttackingHobo, yes. Since the content of rt is changing every frame, I need to generate all over the time. Looks like the only way so solve this for intel card is to turn off the mipmap. – Raymond Sep 2 '11 at 14:24
up vote 2 down vote accepted

Please remove the MipMapping flag for your texture... You need glGenerateMipmap because you use MipMapping and OpenGL need a smaller texture. On bad cards(INTEL), GenerateMipmap is a costly operation. This operation must be called one times.

Add this instruction when you load your texture after glBindTexture :

share|improve this answer
That's the cause. All my textures are created with mipmap enabled, and intel failed to generate mipmap for everframe. Thank you. – Raymond Sep 2 '11 at 14:23

First reason - Intel's OpenGL drivers are universally acknowledged to be rubbish. Sudden and mysterious crashes, artefacts, performance differences, etc are the order of the day here. This is normal, nothing to see here, move along.

Second reason - RTT is always going to be slower than just rendering direct to the backbuffer. Not RTT in and of itself, but the overhead of rendering to a texture, then rendering that same texture to your backbuffer - that's some extra fillrate overhead you're incurring. Even on a very very good driver/hardware combo with fillrate being the only major bottleneck and everything else being equal, it will always be slower.

Third reason - mipmapping a rendertarget texture is not a great idea. It may not even be supported in hardware, which means that the driver must pull the texture back to system memory, update the miplevels in software, then put it back to GPU memory.

share|improve this answer
thank you for your answer, it's really helpful, but I prefer Ellis answer because he just point out and solve the problem with one line of c++ code. – Raymond Sep 2 '11 at 14:21

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.