Discussion in 'Rendering Technology and APIs' started by GLX, Jul 12, 2008.
"A move" is not nearly what we were promised neither expecting.
OpenGL 2.0 "Pure" is long overdue.
What we were expecting was a new API without (without!) any new hardware support in core, no DX10 level support. This choice would have kept GL quite behind indeed. Until the next major update.
What we got was an update with DX10 support, and with a depreciation route towards placing GL in a better position to roll in a new object model (new API).
So they swapped priorities. Personally I think they made the right choice given the situation.
In 2002 3DLabs proposed a new OpenGL, 2.0 "Pure", which was to get rid of the slow path and move the API in the era of programmable hardware.
We are 6 years later, and we still don't have it.
Firms could see that coming in 6 years and prepare for the change.
Even OpenGL 3.0 Long Peaks (covering R3xx/NV4x up, with ARB extensions for D3D10 features, AFAIR) and Mount Evans (covering G8x/R6xx and so D3D10 level hardware) have been announced since years, long enough for firms to get ready.
Clearly, if the schedule was followed, we would have OpenGL 3.0 (Long Peaks) and OpenGL 3.1 (Mount Evans) by now...
Quite simply, because in the long run, they will fail. Sooner or later, someone is going to put out a DirectX clone, and at some point, the industry will get behind it. Once that happens, they will lose control. It may take along time, but it will happen. Thus, they're better off trying to entrench the API further by offering help to port it. It won't impact their sales of Windows or XBox360 in the slightest, but it will do is increase developer mindshare.
You see it happening today with Internet Explorer. For a long time, they eschewed supporting open standards and insisted on adding proprietary semantics in their browser to enforce lock in, and it worked for awhile, when they had 90% of the browser market. They could do anything they wanted, and offering to hand over and commoditize features to competitors seemed like a lose-lose position. Then Firefox and WebKit provided viable, better, alternatives to IE, and their marketshare started slipping. Now with IE8, they have returned to the fold, but too late. Their position in weakened. The traditional powerstructure (W3C) has been made irrelevent, and the future of Web standards is now controlled mostly by Google, and anti-Microsoft contributors. It is likely that IE is on the path to obsolescence.
I know it seems utterly ridiculous and unthinkable, but ponder a scenario where compute shaders become a common programming model for lots of non-gaming tasks. There's no way data centers today are going to switch from Linux to Windows, and AMD/NVidia/Intel will surely want to sell solutions to these people, therefore, they have a vested interest in making sure minimally, a viable GPGPU/compute-shader driver architecture shows up on Linux, whether its OpenCL/LLVM or something else. Either way, it's not unthinkable that a separate industry push to run compute shader tasks on multicore or GPU via a standardized API would evolve into a render API as well. Microsoft would suddenly find themselves with no voice in a whole new market segment.
Anyway, if you look at Microsoft's history, only very few of their initiatives are profitable, many are cost centers aimed at heading off competitors in emerging markets. They have launched tons of APIs and products for which there's no real business model, except that they didn't want someone else to control it.
For whatever reasons, the old API has been kept. IF, it's because of CAD folks, even then I don't expect the IHV's to drop full OGL support because it would kill their high-margin workstation products. As for the API itself, I had chosen to wait for this before I started learning about programmable graphics pipeline, but now it seems that we are not going to get it any time soon.
As for OGL's future, I have seen the community break out in hives on OGL's forums and I am extremely disappointed that this is the second time they chose to let the past screw the future. Hey, even MS is looking to ditch classical windows in favor of Midori.
My point is, sometimes, you just have to make a clean break from the past if you want to do great in the future. It's a simple law of evolution. Either you adapt yourselves to changing environment, or you go extinct.
I can't figure out why didn't mandate all gl3 stuff(types,functions etc) to be prefixed with gl3 and let old stuff stay and mark it deprecated. After a few years and iterations, drop old stuff entirely and mandate a change of prefix from gl3 to gl to fix the version madness and complete the transition. Sure the function names will have to be changed but come on, how hard is a search and replace in your editor.
As for MS, EEE is in their blood. It is a genetic problem with them. They simply can't resist the temptation to fuck "truly" open standards.
It's a good extension, but how useful is it without support from ATI? Given their history with GL drivers, I don't expect them to actually implement it until it becomes core (which at this rate, will be at least another 2 years ).
Just saw this on Blues:
Khronos ramping up OGL3.1 to respond to criticisms. Now expected within 6 months, instead of the 12 previously mentioned.
Read the whole thing here.
yes and in other news: everybody is confident in stuff the ARB is telling.
At least they are acknowledging the feedback and promising to do something about it. Which is good in my book. Hopefully they will deliver on their word this time, Until then this sucks though. Personally I think there are too many cooks for this soup and that it should be shrunk so they can focus on developing and delivering solid code without constant interference.
Just guessing on the interference thing, but having more then 100 members ought to make for some nice quarrelling on the smallest of changes and features. At least past and personal experience hints to that fact.
you know the saying: fool me once, shame on you, fool me twice, shame on me...
they promised the same stuff after GL2, then after some really great looking presentations and newsletters they give us 'this' GL3.
yes, we can _hope_ that they begin to deliver something they say. and thats about it, we can hope, but not rely on anything they say.
on that note, i hope that the deprecated stuff gets removed really fast and something like EXT_direct_state_access gets a fast introduction into the GL3 core.