I work on a cross-platform CAD app (Windows, Linux, OSX) and have a Mac Pro triple booted between the three (latest OSX version, Ubuntu 9.10 64b, Win7 64b). Starting with 10.6.3, we began encountering a lot of regressions, until 10.6.5. Since OpenGL performance increased substantially between those releases, I'm guessing a lot of the issues were related to optimization work, and things have calmed down a lot since then. Often a regression would affect either Nvidia hardware or AMD hardware, but rarely both.I'm curious to know what you had to work around.
Most of the issues appeared to be GLSL compiler or FBO related, ranging from crashes that required an application features to be disabled, to minor issues that could be worked around by altering the shaders. Anyway, here are the ones I remember:
- Writing to more than one buffer in an FBO on Nvidia hardware produced a few random garbage pixels where polygons should have been, and nothing else. A crash would shortly follow a frame or two later. In another case, the entire OS desktop would go into a "flicker fit" where it would refresh properly down to a certain random scanline that changed with each frame, then display black. A reboot was required. At first I thought it was a bad card, but it was reproducible on other systems with Nvidia cards. AMD hardware on OSX was fine, as was Windows/Linux.
- gl_FrontFacing stopped working on AMD cards and we had to roll our own using GLSL's frontfacing() function.
- accessing gl_LightSource[] in a constant loop didn't work for awhile on Nvidia, requiring us to unroll it. A OSX version or two later, we had to consolidate the lighting loop into the same fragment shader as main() otherwise some uniforms that were definitely used were not in the active uniform list (the ones near the end of the list alphabetically, but within the max uniform limit).
- in the August graphics update, on AMD hardware I had to do a glGetTexImage on textures drawn to by an FBO render that weren't attached to GL_COLOR_ATTACTMENT0 (depth attachment, color attachments 1+), otherwise they contained garbage when accessed by a shader later in the redraw. glFinish() didn't do the trick either, only reading pixels from the texture fixed the issue.
- Early last year, uniform arrays (uniform int foo[8]) were suddently reported in the active uniform list as foo[0] rather than foo.
- In one fragment shader with an 'if(expr) discard;' statement, I had to also assign a dummy value to gl_FragColor before the discard otherwise the fragment shader displayed black for all pixels.
We reported these issues to Apple as we tracked them down, and most of these issues were resolved within an update or two, but it was a pretty rocky road for a bit. I began to dread OSX updatesNone of these problems affected the same system booted into Linux or Windows using AMD or Nvidia's drivers.
Because of my experience, I couldn't tell if you were being straight up with your comment or not. So I askedDid their drivers alter behavior at all during that entire time? I didn't say they were compliant. I said they were stable.
I don't believe Apple intentionally altered the GL behaviour, but it definitely altered the behaviour of our application. On the bright side, our app is no longer sluggish on OSX, as it was prior to 10.6.4. So, progress
