glTexSubImage2D(GL_TEXTURE_2D, ... ) & 10.5.3

Is anyone aware of an issue with the X1600 on MBPs and glTexSubImage2D(GL_TEXTURE_2D,…);

Prior to the update I had a system which ran at 60fps.
Since the update my main loop is spending a lot of time doing glTexSubImage2D();

Have I been using something deprecated that has been tightened up in the latest update?

Cheers for any help…

I have profiled this extensively now and it appears that glTexSubImage2D is dropping back to SW under 10.5.3. (For me at least!)

I have read a few other threads and confirmed what I already know. That NPOT textures can cause problems with ATI drivers, but I long ago dealt with those issues, and with the newer ATI cards a lot of those work-arounds, whilst still valid, are unnecessary.

I have also double checked when I copy the texture to the GPU that I am not selecting any funky texture modes, such as GL_WRAP and so on, as again that can cause issues.


Please tell Apple directly.

Done already.

I also got a real quick reply from some of the ATI guys even while they were at WWDC from a mail list posting. Credit to them.

But I guess this all means I’ll have to work around this for a while. :slight_smile:

Just a quick update on this…

It’s not dropping back to software as such. It appears that Apple / ATI have changed quite a lot of stuff. Suspiciously the dropping of 256 colours on OS X.

Whilst it may not be directly related this now looks like a texture format issue, which is forcing data to be copied to and from CPU / GPU ram.

I am waiting patiently for the fix. :slight_smile:

I got tired of waiting and fixed it myself…

Basically I used to use only RGB textures for this (as that’s all I required), but by changing the format I use to RGBA, padding a once efficient piece of code with extra instructions I don’t need, and also by putting some judicially placed APPLE_OPENGL hints for storage around a lot of code I have got back some of my transfer speed.

I would still say that glTexSubImage2D is about 20 - 40% slower than it was before 10.5.3.

So the upshot of this appears to be that the hardware has now effectively been crippled by the latest ‘updates’ that ATI / Apple have done.

I have to wonder how high this is on anyone’s priority list for it to be fixed, which is frustrating…

To be fair Apple do say not to use GL_RGB in their OpenGL docs, but this has worked, and continues to work, on all machines prior to 10.5.3. ATI did not flag the RGB only format as an issue when I contacted them either.

Why take features away? Colour me confused!

NOTE : If anyone out there has some gems to throw my way about how I can best optimize memory, textures and so on on Apple hardware since 10.5.3, or something obvious I may be missing I am all ears as I am sure my solution is not yet perfect.

On nearly all hardware, RGB is not really RGB. It is padded to 32 bit RGBX, which means the upload/download speed is never as fast as RGBA.

arekkusu do you have a ball park figure for how long glTexSubImage2D should take to upload a 17 x 17 RGBA texture? Or know where I can find that?

I know that’s a very general question, but assume I am talking about my X1600.
I want to benchmark it, but don’t know have a figure to reference against.

Ar present I am seeing the following performance:

glTexSubImage2D 4,136 calls for 17 x 17 BGRA textures executed in about 8559815 usec, which is an average of 2000 usec per call.

So that means I could do about 500 of these a second, or 10 a frame!

That’s not good right?

I don’t have a ballpark number. But at 17x17, the setup overhead will probably outweigh any actual transfer time.

The system is optimized to transfer BGRA, at large (i.e. video frame) sizes.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.