PDA

View Full Version : OpenGL3 and Mac



JoshKlint
01-08-2010, 12:01 PM
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?

Alfonse Reinheart
01-08-2010, 03:20 PM
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).

glfreak
01-08-2010, 04:05 PM
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.

Yann LE PETITCORPS
01-08-2010, 05:13 PM
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 :)
But the reverse is really a nightmare ... :(




@+
Yannoo

JoshKlint
01-09-2010, 02:47 PM
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.

Alfonse Reinheart
01-09-2010, 04:47 PM
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.

scratt
01-10-2010, 09:08 AM
[quote]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.

Alfonse Reinheart
01-10-2010, 01:25 PM
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.

scratt
01-10-2010, 09:35 PM
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.

Alfonse Reinheart
01-11-2010, 02:58 AM
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 ;)

Filip
01-11-2010, 05:02 AM
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

scratt
01-11-2010, 09:31 AM
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 Reinheart
01-11-2010, 02:53 PM
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 (http://developer.apple.com/graphicsimaging/opengl/extensions.html) 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.

scratt
01-12-2010, 12:28 AM
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. :)

Stephen A
01-12-2010, 11:11 AM
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.

pjmlp
01-12-2010, 11:56 AM
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.

Groovounet
01-12-2010, 01:33 PM
We are blessed:
http://www.appleinsider.com/articles/10/...s_x_10_6_3.html (http://www.appleinsider.com/articles/10/01/12/support_for_opengl_3_0_added_in_beta_build_of_mac_ os_x_10_6_3.html)

pjmlp
01-12-2010, 02:25 PM
Quite nice to know.

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

scratt
01-12-2010, 07:50 PM
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.

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. :)

Alfonse Reinheart
01-13-2010, 01:53 AM
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.

Stephen A
01-13-2010, 03:58 AM
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.

So does Apple's GLSL compiler accept:


#version 130
in float Foo;
out vec3 Bar;

?

Because if it doesn't, then you are certainly *not* coding in a 3.x-compliant way.

65% support is not good enough. 95% support is not good enough, either, especially since the last 5% affects every single shader you write (lack of GLSL 1.3, which I really hope is fixed before the final 10.6.3 release).

Apple should be - and is - criticized for this by the community.

scratt
01-13-2010, 08:07 AM
You're arguing that it's not a bad thing. Which isn't that much better.

Wrong again. I am saying it's not a huge issue and there are reasons that I understand and appreciate as to why it has not been implemented fully yet.


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.

Absolutely. Moaning and whinging in public forums is widely recognised as the best way to get huge corporations to change their strategy, especially Apple.


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 hacks you might use to switch between EXT and core won't work. You have to do something more complex. And that's bad.

Taking, err, how many nano-seconds exactly?
Please refer back to the last paragraph in my last post. :)

Stephen A
01-13-2010, 09:49 AM
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 hacks you might use to switch between EXT and core won't work. You have to do something more complex. And that's bad.

Taking, err, how many nano-seconds exactly?
Please refer back to the last paragraph in my last post. :)

Way to miss the point. Hint: this is not about performance.

Janitorial
01-13-2010, 10:52 AM
The problem is that a developer simply can't count on all the functionality being there when they want to use it. Apple often requests developer input as to which functionality they might want to use - but, even when these requests are honored, the time-to-implementation is measurably high.

Having OS X lagging 18 months behind the spec with no visible commitment to shipping something that could be called 3.0, 3.1, 3.2 or even the next revision around the bend - it is in stark contrast with the tack being taken on OpenCL.

The developer story would be greatly simplified and improve confidence in the direction for GL on OS X, if Apple would just implement the specs in their entirety and not create this a-la-carte mess.

Janitorial
01-16-2010, 12:56 PM
This is what timely, comprehensive OpenGL support looks like:

http://developer.nvidia.com/object/opengl_3_driver.html

They actually refer to them as 3.0, 3.1, and 3.2 drivers - because they actually implemented everything in the spec and are thus worthy of the appropriate version label.

Above and beyond simple compliance with the core specification, they have a large number of ARB extensions implemented.

"This driver supports all of OpenGL 3.2 and GLSL 1.50 and the following new extensions..." - Sep 29, 2009.

If you can read the GL 3.2 spec, you can use all those features on that driver, and then some.

But not to focus unfairly on NVIDIA; let's have a look at AMD on Windows.

http://www.tomshardware.com/news/amd-ati-catalyst-opengl-3.1,8379.html
-> shipping a 3.1 compliant driver five months ago

http://www.opengl.org/news/comments/amd-releases-driver-with-opengl-3.2-support/
-> shipping a batch of GL 3.2 functionality, though not quite a full 3.2 driver yet.

It shouldn't come as a surprise that AMD and NVIDIA are already well past the OpenGL 3.0 and 3.1 spec level; after all the 3.0 spec was published in July 2008 and 3.1 was published in March of 2009 - almost a year ago.

There's really no positive spin on this.

scratt
01-16-2010, 08:48 PM
Gosh! You mean GPU manufacturers are the first to have the new drivers done! Wow! Oh.. wait.. You are literally comparing Apples with Oranges. Pardon the pun.

So Janitorial (and anyone else) I am curious..

Apple didn't bother putting OpenGL3.x into OS X yet, .... because?

Because they are incompetent?
Lazy?
Hate graphics programmers?
Just want to mess with people's Chi?
Couldn't be bothered?

I am just wondering what particular random reason they chose...
Or if perhaps there could be a *good* reason for it...

I am sure all the geniuses in this thread could just pop over to Infinite loop and sort out Apple's graphics department in a second if only they were given a chance... If anyone wants a couple of direct emails so they can drop a line to the engineers and tell them what they think I'd be more than happy to oblige...

Also I am equally curious to see what groundbreaking commercially available products are out there right now exploiting all this OpenGL3.x goodness to the full. Seeing as we're so far down the line with commercial *bug-free* OpenGL 3.x drivers all over the place....

Does Windows 7 use GL3.x features?
By that I mean more than expose drivers that *someone else* wrote for them?

How about Linux?

Do you guys get the difference between these platforms?

pjmlp
01-17-2010, 05:23 AM
I guess for the same reason they delayed more than year the Java 6 support on the platform and tied it to Leopard.

Apple has a tight control on which drivers and technologies get delivered to MacOSX.

On Java's case, it is Apple that *wants* to provide its own implementation, instead of having Sun supporting it.

Maybe it is the same type of situation with graphics drivers. Actually, if you go to the graphics manufacters sites, they don't provide the option to download drivers for the MacOSX.

Ragnemalm
02-16-2010, 01:58 PM
If I get you right in this thread, this problem seems to be near getting solved. If so, good. It is not the first time Apple has lagged behind. Remember when shaders were emulation only on all Macs? That was up to 10.3. Not funny. But after that I think they were pretty well updated for a while, up to 2.1.

What Apple tells us is to file bug reports or similar. I am not sure if that matters. But I don't think a web forum thread matters more. Maybe articles in respected magazines. Apple's own mailing lists are good, I have had direct contact with Apple engineers there several times, and they were quite helpful.

LEgregius
03-12-2010, 10:22 PM
Apple has always been kind of late delivering opengl updates.

pjmlp, Sun originally didn't want to support Mac OS X, plus apple wanted to optimize it to the OS. I talked to apple engineers about this a number of years ago. About them taking so long to get it going, I don't think they have an excuse other than just not hiring enough engineers.

As for Open GL, Nvidia and AMD actually do write the backend drivers for Apple, and they have both been quite late updating drivers for things in the past. However, I spoke to an OpenGL driver engineer from Nvidia like 3 or 4 years ago over lunch at GDC. He told me that Nvidia would gladly do the entire open gl implementation, but Apple wanted to do the high-level part of it because they wanted it to work as close to the same across graphics cards as possible. This paid off for them regarding the intel graphics cards, for which Intel still doesn't have decent open gl drivers on windows.

This doesn't excuse them in any way. I think they are so far behind because they put tons of their OS and graphics engineers on the iPhone, which recently just added OpenGL ES 2.0 support. Not to mention putting them on doing OpenCL. These also delayed the release of Snow Leopard. Apple always seems to put OpenGL and gaming support for the Macs on the back-burner. I think it hurts them extremely. People from Valve said they had talks with Apple several times about supporting the mac, and what they needed from them so they could do it. They reported that apple responded to them that games were important and they would get right on it. They never did. Hopefully apple will get a clue with 10.6.3 as the reports say. I've sure been waiting for them to get one.

OpenGL 3.2 and Open CL are support on linux, btw. They actually were stable on linux before windows for both AMD and Nvidia, if memory serves. Go figure.

ZbuffeR
03-13-2010, 02:32 AM
At least Valve ports Source Engine to Macs, maybe that hints for some updates in april ?

LEgregius
03-13-2010, 08:18 AM
Actually, yes. Valve is bringing Steam to Mac in April, and Portal 2 is announced for mac. They are also going to port all future games to mac, at least for the foreseeable future.

AND, if you own any games on steam, you can download the mac version for free, which is a big deal.

HenriH
03-14-2010, 05:56 AM
I would say they should skip OpenGL 3 outright and go directly to OpenGL 4 now.

Alfonse Reinheart
03-14-2010, 05:03 PM
I would say they should skip OpenGL 3 outright and go directly to OpenGL 4 now.

No. They should expose both GL 3 and GL 4. If you have hardware that is 3.x only, you shouldn't be restricted to 2.1 + extensions.

Filip
03-29-2010, 03:13 PM
10.6.3 is out and in good classic Apple manner they sure doesn't fail to disappoint. Getting really fed up with this sh*t.

Rob Barris
03-29-2010, 04:07 PM
Which feature were you looking for ?

Stephen A
03-29-2010, 04:36 PM
How about GLSL 1.3 for starters? :)

arekkusu
03-29-2010, 07:13 PM
What specifically are you looking for in 1.30? Anything that you can't already do in 1.20 + EXT_gpu_shader4?

Groovounet
03-29-2010, 08:25 PM
No way! Are they going to make us way until MacOS X 10.7 to reach OpenGL 3.0 and use it as a selling feature?
...
Hello! OpenGL specs: every 6 months. MacOS big versions, every 12 / 18 months.

...

Filip
03-30-2010, 03:29 AM
Of course you can do almost anything with the gl2.1 + extensions but that is not the point here. All other platforms have more up to date drivers. (even bsd and open solaris it seems!!!) It's is especially annoying that Windows is a better OpenGL dev platform than Mac when Microsoft actively works against OpenGL while Apple sits on the darn board!
I work in visualization and want to have access to the latest and greatest and although I love the Mac platform I'm slowly feeling forced to move to Linux for serious dev work. Why not 3.3 now? I don't get it? Why do apple sit on the board and work on the spec if they won't use it?
Let's turn this around: Why are you content with having to use 2.1 + extensions and missing access to hardware features that all the rest of the computing world has access to?

Groovounet
03-30-2010, 03:46 AM
I follow that especially on a platform whose targets are likely to be into graphics. Maybe not games yet, but real graphics software.

"Norrköping, Sweden" nice... EuroGraphics?

Filip
03-30-2010, 06:08 AM
Groovounet : Yupp, Eurographics in a month. Sadly I haven't got time to actively attend since we are on a tight schedule for the inauguration of our visualization center (visualiseringscenter.se) on may 27 this year.

Currently we are deploying almost everything we do on Windows XP and in some cases Linux. I try to make everything (somewhat) platform independent and for this reason it would be nice to be able to target e.g. nvidia G80 + 3.3 drivers. Obviously it is not a problem to work around this by using a high level API or lowest common denominator but it would be easier if we didn't have to. Easiest would be to drop Mac altogether since we don't actually need it. It's just a "grassroots movement" from my side to use it. I want to use Mac as my main platform.

Alfonse Reinheart
03-30-2010, 07:04 PM
What specifically are you looking for in 1.30? Anything that you can't already do in 1.20 + EXT_gpu_shader4?

If I may hazard a guess, one thing might be to use the exact same shaders across platforms. Like one might do in a cross-platform API: use the same code across platforms.

Having to use different shaders, or even just #defines and such, across platforms is against the notion of having a cross-platform API.

Filip
03-31-2010, 08:55 AM
Spot on Alfonse ! Couldn't have said it better.