Awesome news for Mac dev : openGL 3 !

#1 Agreed
Though we yet have to see apple getting the drivers up there too, because just the OpenGL support won't get anyone anywhere else than a hospital for mind illness due to the insanity generated by it.

At least we can say that by 10.6.3 Apple is only 2 years behind again with their OpenGL support, no longer 3 :)
So we can hope that OGL 3.2 happens in Q1 / Q2 2012 with 10.7 ;)

#2 Mac graphics cards are the same as PC graphics cards, but with a 32/64-bit firmware for EFI rather than just BIOS, backed by completely useless drivers made by clowns in fruity shirts ;)

Apple need to be a little less secretive and actually let the chip manufacturers make drivers for OS X. Currently they're demanding the code, doing gosh knows what to it before foisting it upon us.

Yeah, only two years behind now. That's amazing progress for them!

#3 Well... this sounds all great, but it won't help Torque on OSX.

For instance OSX supports GLSL. Still on an older release of OSX Alex Scarborough found that this..

y = x - 1.0;

... would not subtract, but would *add* 1 to x. There were bugs with having like 13 functions in a GLSL file... more or less was ok... just not 13. Also when we're really lucky compiling a GLSL file would just cause OSX to core dump.

This is the class of bugs that we've found when using OpenGL on OSX. Until Apple decides on supporting games with a reasonably bug free implementation of OpenGL things are hopeless with anything other than very basic functionality.

#4 Minor additions/corrections to Tom's post:
The GMA X3100 drivers from 10.5.0 until 10.5.3 did not implement subtraction of constants in shaders, regardless of shading language (GLSL or the old assembly style). No other cards were affected, as far as I know. For the first batch of IA games I ported I wound up writing a different set of shaders just for the X3100 to work around the issue (x - 1.0 broke, but float s = 1.0 * -1.0; y = s + x; worked. In assembly. GLSL would optimize it down to a subtract and then that wouldn't work. But I digress)

In 10.6.0 through at least 10.6.2 (I have not checked 10.6.3, and since I am no longer employed at TorquePowered I have no inclination to) a GLSL shader which contains 15 unused functions will cause the GLSL compiler to smash the heap during dead code removal. Every shader, every time. Having 15 unused functions actually occurs fairly regularly in Torque3D due to how it assembles shaders.

Oh, and that's a class of bugs we've found. The "Seriously, WTF kind of code makes this happen and who misses it?" class. I can list a dozen far more severe bugs off the top of my head, which I wish I would forget about already.

So, as far as I am concerned, all this means is that Apple added some extensions to the extensions string and tossed in presumably correct function declarations in OpenGL.h. I have virtually no faith that any of the added functionality works properly. In fact, I would consider 'not working' to be the best case scenario; past experience is that it's also quite likely to crash your app or take out the system.

And it's not OpenGL 3 yet. It's just the OpenGL 2.x extensions to provide OpenGL 3 features. OpenGL 3 is, despite most appearances, a genuinely different beast from OpenGL 1/2, and simply adding extensions to OpenGL 2.1 won't get you an OpenGL 3 implementation. Of course, Apple is well aware of this since they're chairing the OpenGL 3.x working group.

Yes, the whole situations is kinda f'ed up.

#5 Tom, Alex, you killed my dream! ;-)

Apple seems to use LLVM to retarget openGL instructions relative to the target GPU.

see jroller.com/murphee/entry/benefits_of_llvm_as_common
and en.wikipedia.org/wiki/Clang

I hoped that this new technique (started in 10.5, I think it started with 10.6) was the reason why openGL performance in 10.6 was inferior to 10.5, and that it become to be more mature now with 10.6.3 around the corner.

But everybody deeply involved with Apple OpenGL code on Torque seems to be very disgusted and discouraged.

My second hope now, is that openGL ES progress on the iPhone front (the only important front for Apple nowadays) will bring back improvement to the Mac OSX openGL front later…

Back to Basic Lighting now… :-)

Nicolas Buquet
www.buquet-net.com/cv/

#6 LLVM? Well, this explains (a little part) of the horror that is high-end (as in "using shaders at all") OpenGL development on OSX.

#7 Apple has been using LLVM in their OpenGL drivers since 10.5.0. LLVM kicks in when 1) The driver must fall back to software rendering, and 2) Generating code to handle vertex buffer formats. Vertex buffer formats are one of the few things I have not had fail on me, and if Torque 3D is falling back to software rendering then clearly something else has gone horribly wrong.

#8 You need to put a disclaimer on this thread! Think of the children!

#9 @Alex: I've read some posts from someone in the VMWare team who was (and probably still is) having crashes when the driver decides to compile some vertex shaders to be used in software. The shaders in question belong to Portal.

#10 So, Mac OSX 10.6.3 is out, and openGL 3.0 is still not of the party. It's not 100% supported : www.macgeneration.com/news/voir/149201/rendez-vous-manque-avec-opengl-3.0.

But there seems to give a better (more efficient) openGL experience.

Does Apple need an openGL developer in Cupertino and is ashamed to ask? ;-)

Nicolas Buquet
www.buquet-net.com/cv/

#11 Valve implied they were advising Apple on GL issues. I think they would be wise to keep listening to them, as they're likely to run into every issue Alex has seen, and then some. With more game companies starting to support OS X we'll see improvements in OpenGL support, I'm sure.

#12 Yeah, Valve will probably make quite some pressure on Apple to get their OpenGL drivers together. If not, expect an announcement of Mac Steam being delayed until 2011 or the Mac Source games running in the OpenGL equivalent of DX7 mode.