OpenGL3 and Mac

From what I gather, OpenGL3 is not support on Macintosh computers, and there is no indication of when or if it ever will be. If this is so, isn’t it a major setback to OpenGL3? One of the main advantages of OpenGL is its cross-platform capabilities. If OpenGL3 is for Windows and Linux only, isn’t that a major impediment to its adoption by developers? What is the plan to overcome this?

You ask that question as though there is or can be a plan to overcome it.

OpenGL is a specification: a PDF document. That is ultimately all the ARB can do. It is left to the different vendors to implement that document.

On MacOSX machines, Apple has taken the liberty to essentially do what Microsoft does with Direct3D: define a part of the implementation and allow IHVs to implement a lower-level API that Apple defines. This is fine, to a point. But it also means that Apple controls all of OpenGL on MacOSX.

If Apple wants to freeze OpenGL at 2.1 on MacOSX, there is nothing anyone can do about it. If Apple simply doesn’t have the time/resources to keep OpenGL on MacOSX up to date while also doing all of the other things they’re doing, then there is nothing anyone can do about it.

Many 3.x GL features are exposed as ARB core extensions. I don’t know enough about Mac OpenGL implementations, but I would hope that they can expose extensions. If they can, then they can get around Apple’s slow improvement easily enough. If not, then there is nothing that can be done unless Apple chooses to do it.

Blizzard is probably our best friend here. They’ve got a pair of games coming out in the near future (near in Blizzard-time, of course). And if they want GL 3.x on Macs, then they can start throwing their weight around with Apple (though, thanks to iPhone and the App store, that isn’t very much weight these days).

Portability is not meant to target specialized APIs such as graphics, and hence should not be an issue. Your portable code should work on top of a wrapper of these system-specific API calls, resulting in your code being portability scalable. Unportable/system-specific stuff is kept isolated and they are usually fixed in size relatively very smaller than the actual scalable code.

But it’s true that it’s anormal that we have to use specifics MacOS makefiles for to work with SDL, OpenGL, GLUT and others THAT ARE MAKE FOR TO BE CROSS PLATEFORM .

I find too that this isn’t the good way that to add useless complexity for nothing for crosscompilations with gcc/g++ for example …

On other side, this permit to use a very cool and fiable plateform for devellopments/testing, and when we can compile it on MacOS it’s really a pleasure that to adapt the project for to compile it on the Linux plateform :slight_smile:
But the reverse is really a nightmare … :frowning:

@+
Yannoo

Thanks for the information. Until MacOS supports OpenGL3, we are going to stick with OpenGL 2.1.

Portability is not meant to target specialized APIs such as graphics, and hence should not be an issue. Your portable code should work on top of a wrapper of these system-specific API calls, resulting in your code being portability scalable. Unportable/system-specific stuff is kept isolated and they are usually fixed in size relatively very smaller than the actual scalable code.

I was under the impression that cross-platform compatibility meant your code would work the same across different platforms.

I was under the impression that cross-platform compatibility meant your code would work the same across different platforms.

Yes, but Apple controls OpenGL on MacOSX. So unless they care about cross-platform compatibility, you’ll have to do the best you can.

[quote=Alfonse Reinheart]

Yes, but Apple controls OpenGL on MacOSX. So unless they care about cross-platform compatibility, you’ll have to do the best you can.

I don’t get your point here.

The same charge could be levelled at Microsoft, or any other proprietary API developer. Sony, Nintendo etc.

At least Apple’s implementation of OpenGL 2.1 will work on any other platform supporting the 2.1 API.

The same cannot be said of DirectX across Vista and XP even.

The same cannot be said of DirectX across Vista and XP even.

Not true at all. Vista/Win7 can run DX9 (and earlier) applications just fine. DX10 and above are not available on XP. So it’s exactly the same.

How is it “exactly the same” ? And I am still not getting your earlier point.

I am not trying to get into an API flame war here, but DirectX is a completely closed system with it’s own internal restrictions which are not actually based on limits of the underlying hardware. It’s limited at Microsoft’s whim and it’s limits are based on marketing operating system revisions for a closed eco system. A lot of those so called “limits” are part of a campaign of FUD.

OpenGL2.1 will work across the board on any platform (Apple, Linux etc. etc.) which supports it. How are Apple not caring about cross-platform compatibility?

What Apple are actually trying to do is produce stable systems which have a solid and reliable feature set and cross platform compatibility. 3.x will come when it’s ready for prime time in OS X, and Open CL has settled down. In the meantime there are a plethora of extensions added regularly to Open GL on OS X.

How is it “exactly the same” ? And I am still not getting your earlier point.

It’s set notation. You said that code written to GL 2.1 on MacOSX would work just the same on any GL 2.1 implementation. And that this is not true of Microsoft and Direct3D.

All of the current Windows platform support DX9. Only Vista and above support DX10. So there is only one point of division between versions of D3D supported on different OS’s offering D3D support.

All desktop platforms support OpenGL 2.1. Only non-Apple desktop platforms support OpenGL 3.x and above. Again, there is one point of division between versions of OpenGL supported on different OS’s offering OpenGL support.

In both cases, it is one specific entity that is preventing support for these in the larger set. Your GL 3.x capable card cannot expose extensions that allow for accessing GL 3.x features on Mac OSX. Apple prevents this, just like Microsoft prevents D3D10 capable cards from exposing D3D10 operations on XP.

There is one crucial difference. XP is a dying OS; there will be fewer users of it in the future until it eventually become negligable. At that point, the lack of backwards compatibility in XP becomes irrelevant.

MacOSX just had a new revision… without 3.x support. Microsoft has exposed new hardware features on a new OS; Apple did not. Yes, Microsoft limited the backwards compatibility of DX10. Whether you believe that they had good reasons for this or that it was “based on marketing operating system revisions for a closed eco system” is irrelevant. What matters is that on new versions of Windows, you can get access to new hardware features. On no version of MacOSX can you do that.

This is not good. Not good for Apple, not good for MacOS X, not good for hardware makers, and not good for OpenGL.

OpenGL2.1 will work across the board on any platform (Apple, Linux etc. etc.) which supports it. How are Apple not caring about cross-platform compatibility?

Because OpenGL has had 3 version changes sense then, one of them being a major version change. Apple sits on the OpenGL ARB; they knew this was coming. And yet, Snow Leopard offers no 3.x features. They don’t even expose 3.x extensions in preparation for supporting 3.x.

2.1 is old. Several years old. Support for 3.x should not be considered optional.

3.x will come when it’s ready for prime time in OS X, and Open CL has settled down.

OpenCL has nothing to do with OpenGL; you do not have to let OpenCL “settle down” before implementing GL 3.x. And what about 3.x is not “ready for prime time” in OS X, yet is perfectly function in every other desktop OS?

I honestly don’t understand why you’re defending Apple for their clear negligence on this issue. They’ve done a bad thing with their OpenGL support; you should not be defending them for it.

In the meantime there are a plethora of extensions added regularly to Open GL on OS X.

Where is ARB_geometry_shader? Where is ARB_uniform_buffer_object? Even something as simple as ARB_vertex_array_object (which they already have under a virtually identical API) isn’t available.

Yes, Apple has some Apple-specific extensions, but that’s hardly supporting cross-platform portability, is it :wink:

I also would like GL3.2 on Mac and am quite disappointed that the current Mac OS X doesn’t support it (10.6.2).
Regarding extensions: Geo shaders are in as far as I can tell and have been for a long time. And as you say yourself: ARB_vertex_array_object and the Apple version of it are virtually identical. It’s not all that bad but it definitely could be a lot better.

Lets hope all gets fixed with 10.6.3

Alfonse I really think you need to go read some Apple docs as you are way off base with some of your assertions. Geometry shaders have been exposed on hardware that is capable for a long long time. As are things like instancing etc. From the standpoint of someone who produces software for a wide audience it’s nice to be able to build bleeding edge features into your App, but to be honest you need to market to the wider audience… At the moment GL2.1 is perfect for that (if we are still talking about cross platform compatibility). If you want bleeding edge features you generally have to code special cases and with the extensions Apple does provide and you don’t seem to know about - or want to acknowledge - you can also do that on OS X.

Your accusing Apple of not supporting cross platform development, and defending Microsoft who have a closed proprietary API and actively campaign against OpenGL, and all things Open. Doesn’t make sense to me at all.

OpenCL uses the GPU among other bits of silicon, and OS X has gone through a major low level revision in 10.6. Bringing GL3.x into this early on could have resulted in much less reliable OS IMO. Something akin to say… Vista.

As for hiding hardware features… Well you said it yourself. Microsoft actively blocks features to force people to upgrade. Apple to my knowledge and experience will expose hardware features on old equipment as and when it becomes available in the API they produce.

Alfonse I really think you need to go read some Apple docs as you are way off base with some of your assertions.

Are these sufficient?

From the standpoint of someone who produces software for a wide audience it’s nice to be able to build bleeding edge features into your App, but to be honest you need to market to the wider audience… At the moment GL2.1 is perfect for that (if we are still talking about cross platform compatibility).

You know, you don’t have to use the 3.x features if they’re not there. That’s the whole point of backwards compatibility; you can see if something is there in order to use it.

If hardware has access to transform feedback, and I’m doing something that uses transform feedback, I want to be able to use it. If not, I can do a fallback that uses PBOs. But I’d rather do it directly if possible.

The whole point of core ARB extensions is so that you do not have to rewrite your code if something is in the core or exposed as an extension. By not supporting them, you now have to go out of your way to make things work.

Most important of all, who are you or Apple to tell me what platforms I should and should not target? If I want to target 3.x only, why should you or Apple get in my way? I’m an adult; I can make my own decisions about the market for a particular graphics product and GL version to support. Apple’s job is to provide the API; I will decide how to use it.

Apple isn’t doing their job. To the detriment of OpenGL 3.x.

If you want bleeding edge features you generally have to code special cases and with the extensions Apple does provide and you don’t seem to know about - or want to acknowledge - you can also do that on OS X.

EXT_geometry_shader4 is not the same thing as ARB_geometry_shader. And EXT_bindable_uniform is definitely not the same as ARB_uniform_buffer_object.

In order to support doing either of these the right way (ARB) and doing it the MacOSX way (random EXT stuff), I would have to have multiple codepaths just to use the feature across multiple platforms.

How does this constitute serving the needs of cross-platform development? How does forcing people to write for 2.1 + old (and in some cases, poor) EXT extensions cross-platform, when every other platform supports 2.1 + core ARB extensions and 3.x core features, support cross-platform development?

Your accusing Apple of not supporting cross platform development, and defending Microsoft who have a closed proprietary API and actively campaign against OpenGL, and all things Open. Doesn’t make sense to me at all.

What Microsoft does is irrelevant; this is about Apple not offering a proper OpenGL implementation, thus inhibiting OpenGL 3.x use.

Further, I’m not defending Microsoft doing anything; I was refuting your anti-analogy that the Direct3D break between XP and Vista was somehow worse than the GL version break between Apple and non-Apple platforms.

OpenCL uses the GPU among other bits of silicon, and OS X has gone through a major low level revision in 10.6. Bringing GL3.x into this early on could have resulted in much less reliable OS IMO.

Both NVIDIA and ATi have exposed OpenCL on Windows without bringing instability to the OS. Microsoft did the same with D3D Compute shaders, again without bringing instability to the OS. Indeed, they were able to pump out a major OS revision while simultaneously back-porting DX11 into Vista.

Why was Apple unable to do this? Especially when they’re the ones who pioneered OpenCL.

Something akin to say… Vista.

It’s good to see that the Vista FUD is still alive and well after all these years.

As for hiding hardware features… Well you said it yourself. Microsoft actively blocks features to force people to upgrade.

No, that’s what you said. The known facts are that Microsoft did not allow DX10 to function on WinXP. It is your belief that this is done solely to force people to upgrade. I believe you called it “based on marketing operating system revisions for a closed eco system.”

You’re free to believe that this was Microsoft’s only or just primary motivation, if you wish. I’m not going to argue the point here. But I never said that it was, nor did I ever agreed with you.

Alfonse, I am not going to debate you any more. You contradict yourself in your last three posts. And even contradict yourself within the last post all by itself.

One thing I will point out is that the scope of the OpenCL implementation on OS X is far more than simply exposing it. It’s not just about GPUs and it’s tied into a cohesive and well thought out process management system. Like I said before, go do some reading. Skimming web pages of GL extensions is simply not sufficient - as you have shown with your replies. :slight_smile:

It is beyond me how one can argue that Apple not implementing GL3.x is somehow a good thing. They’ve had access to the specs for at least 18 months - this should have been more than enough time for Apple (and Intel) to implement the necessary drivers.

No matter how you spin this, they are doing a disservice to the OpenGL ecosystem.

Couldn’t agree more.

This was one of the reasons why I ended up buying a PC with Windows 7, instead of a Mac.

I didn’t want to give Apple my money, without knowing if they will ever bother to support OpenGL 3.x.

We are blessed:
http://www.appleinsider.com/articles/10/…s_x_10_6_3.html

Quite nice to know.

Although I have now a PC, this is the kind of actions that will keep OpenGL a viable option.

I didn’t argue it was a good thing.

What’s more, without Apple in the OpenGL camp supporting more than one distinct platform, and various flavours of silicon & API, the “ecosystem” as you refer to it, would be in a far worse situation.

What I did say is that there were good reasons behind it not being plugged into Snow Leopard from day one. A lot of those were decisions made inside Apple, by Apple, for the good of their product and their customers in their engineers opinion. Some external factors were also in play, which were all too apparent when GL3.0 was first “released”.

FYI as of today (this is prior to the next update linked to above) GL3.0 is effectively supported up to 65% on OS X as are certain features of 3.1 and 3.2. With the next update that hits 95% AFAIK. I am not sure what stuff Alfonse is reading but his idea of what is and is not possible on the current OS X OpenGL implementation on capable Apple hardware is a little off, to say the least.

It’s certainly possible to program in a GL3.x compliant way even with the current GL2.1 implementation and the extensions that are exposed. I have been doing so for most of the last 18 months or so. When you look at the amount of bleating in the early days of GL3.0 and the arguments and panic over how deprecated features were going to be supported / not-supported / supported selectively by certain manufacturers etc. it really does not seem that much of a big deal to me where the OpenGL API is exactly on an OS as specialised as OS X. Nor does it impact cross platform development in any really appreciable way for a competent engineer in my experience doing it day in and day out.

Frankly looking through the list of supported and unsupported extensions and features, I get the urge to play the sound effect of a baby crying when I read posts from Alfonse and yourself. :slight_smile:

I didn’t argue it was a good thing.

You’re arguing that it’s not a bad thing. Which isn’t that much better.

The only way to get improvement is to hold IHVs accountable for doing the wrong thing. This means not being understanding when they’re 18 months out of date.

I am not sure what stuff Alfonse is reading but his idea of what is and is not possible on the current OpenGL implementation on capable Apple hardware is a little off.

Then please enlighten me. Show me where AppleGL currently supports any of the following extensions. And before you ask, no, EXT versions don’t count*:

ARB_framebuffer_object (note: not hardware based)
ARB_geometry_shader4
ARB_texture_rg
ARB_texture_compression_rgtc
ARB_framebuffer_sRGB
ARB_draw_instanced
ARB_copy_buffer (note: not hardware based)
ARB_sync (note: not hardware based)
ARB_map_buffer_range (note: not hardware based)
ARB_texture_buffer_object
ARB_texture_array

The ones marked “not hardware based” are extensions that can be, and in many cases are, implemented on pre-DX10/GL3.0 hardware. ARB_framebuffer_object in fact has been backported to most DX9 hardware (and when this is not the case, it is because IHVs no longer support that hardware with new drivers). In these cases, there really is no excuse.

  • If you’re wondering why the EXT versions don’t count, it’s because of this. Either the ARB version is a regular ARB extension, or it is a core extension. If it’s a core extension, then that means that you don’t need different codepaths for the ARB version and the core version. That simplifies code, and that’s good. Supporting the EXT version would therefore mean adding a codepath. That’s bad, so any reason not to is good. The better supported a core extension is, the sooner the EXT one will become irrelevant.

If it’s not a core extension, then you need different codepaths. However, if there is an EXT, ARB, and a core version, then there’s a really good chance that functionality changed between the EXT and the ARB. That means that simple function pointer tricks you might use to switch between EXT and core won’t work. You have to do something more complex. And that’s bad.

When an extension, particularly an EXT extension, is superseded by an ARB one, the ARB one needs to become the primary version of that functionality.