GL Future?

[glfreak]

Is still OpnGL the industry standard after version 2.1?

What game development companies are adopting GL?

What CAD companies are switching to D3D, or supporting both GL and D3D?

Who is the real enemy of GL and who is trying to kill it?

Is not GL design still targetting 10 year old CARDS?

[Rosario Leonardi]

1- If programmer want to create cross platform program openGL is the only choice.
You can check the list of programs the use openGL here
http://www.opengl.org/products/

2- Blizzard, ID software and all the mobile game developers.

3- Autodesk is the main directX fan. 3DStudio Max run faster on DX, but also support openGL. Maya and other Autodesk product use openGL.

4- Micro$oft?

5- No, 10 year old card don't support openGL 2.x and only geForce 8 / ATI 21xx support openGL 3.x. The power of openGL is the extension mechanism, if a 1946 video card have a support for geometry shaders they can use it, I don't see any other graphic library that allow this.

[bobvodka]

1) The use of 'industry standard' could be considered misleading; in the main stream game development OpenGL is hardly used at all (even Blizzard with WoW ship on windows with a D3D renderer as default).

2) Blizzard but they default to D3D on windows and HAVE to use OpenGL else where. iD, but thats more legacy than anything else. Mobile platforms are OpenGL|ES, this is NOT OpenGL; the two APIs are significantly different.

3) I'll skip

4) Firstly saying "Micro$oft" makes you look a /. troll Rosario; it's a term used by idiots and people who can't deal with the idea that a company might want to make money. The real enemy of OpenGL is, imo, the ARB who have screwed the pooch so many times I've lost count and, to a lesser extent, ATI/AMD whos OpenGL implimentation still isn't up to par (and I say this as an ATI card user). MS on the other hand have no input into OpenGL and since they left the ARB have been happy to ignore it while D3D leaves it in the dust.. so, yeah, I guess if having a better API makes them an 'enemy' then yeah, MS are an enemy of OpenGL by producing a better product.

5) Right now, I've no ideas WHAT OpenGL is targetting. By my estimate in the wild, right now, you have a choice of;
- 2.1 + extensions
- 2.1 + ext + DSA
- 3.0 + ext
- 3.0 in forward compatible mode
- 3.1 + ext
- 3.1 + ext + ext which reenables all the deprecated functions (oh, how this made me laugh)
and I'm sure DSA mixes up in the 3.x line of things as well.

Does OpenGL have a future?
Yes, if only because outside of Windows there really is no alternative... right now however, imo, it's an ungainly mess of functionality and confusion; but hey, that's what the ARB seem to do best.

[glfreak]

Every platform MUST provide their own OpenGL SDK, which works on top of a unified model driver which makes it easier for developer to focus on core driver rather than implementation. Khronos could have done this and have provided at least Linux and Apple their own installable SDKs. The GL context/windowing interface MUST be unified across all platforms, and extensible too.

Deprecated features should not be something to worry about, and it must be maintained by the SDK provider, not the core driver implementer (IHVs).

I agree that MS is not the real enemy, it's the ppl who are responsible for spec. I would not blame AMD at all, it has good support for GL, even it's not up to date with spec. Maybe because they realized already that the spec itself does not worth much attention at the moment...

[Rosario Leonardi]

Ok.. I'll remove my troll hat I'll try to make a more serious answer. :P

2) If he add the magic word "under windows" the only answer is "No under windows nobody that don't want get crazy with all the different driver behavior use DirectX". Blizzard from what I know want to extend is business in Mac world, so it's interested in openGL. Carmack (ID) was a great fan of openGL but recently it seem to loose interest. Also Mac is not widely used and not every company can make the effort to make an engine that run both in directX and openGL.
Oh.. BTW playstation 3 game also use a custom version of openGL(|ES).

4) I say Micro$oft (with the "$" and the "?") because I wasn't very sure (here the "?") of the answer because is a complex argument and we can discuss a lot of who is the worst antagonist of oGL.

I think Ms is in the top of my list, in the past they have tried in every way to stop people from developing in openGL under his platform. The main MS idea was to support openGL only in the NT platform and leave directX (or WinG) for entertainment.
It have worked well (that's why I used the "$").

Also a lot of ARB member as you say don't make openGL life easy. But maybe a problem of openGL is that want to run on every platform ("from games to virtual reality, mobile phones to supercomputers" the logo say) and it's difficult to make everybody happy.

Maybe we can add Creative. Creative bought 3DLabs, and remove every found on the developing of openGL.

But you can also add game industry in the list of the enemy. They always preferred Dx even when it was not so matured as today. Or Macintosh, because they don't sell enough computer.. or the people cause they don't buy enough Mac.. or the whole world because it's unfair. Oh damn.. you are right, I'm an idiot. :P

[bobvodka]

No, the PS3 uses PSGL which is their own library, there is a GL|ES lib on the PS3 but, aside from iD using it for some things, no body really uses it beyond maybe prototyping simply because it is too slow. Everyone uses an engine and engines go to the metal. (On the 360 is is of course DX and the Wii has it's own library for doing things; I've had the... pleasure? of developing on the PS3 and the 360 and I'm now moving to the Wii)

Also, what you are talking about with OpenGL is history... practically pre-history in technology terms. OpenGL made it onto Win95 (iirc, maybe 98 so far back my memory is fuzzy) and this was before hardware acceleration. The reason for this probably made a degree of sense; OpenGL was targeted initally at workstations and NT was their workstation OS, the demand however caused it to happen otherwise.

[glfreak]

Fair enough. Then would there be any chance to have lightweight DirectX version for handhelds and mobile phones?

[bobvodka]

There is a DX mobile in existance, however MS haven't really pushed it all that hard/at all and there is little support for it.

You won't get any arguement out of me that, in the mobile space, GL|ES is king of the 3D. Maybe MS aren't bothered about that market right now, or maybe they just don't have a good responce, who knows and I wouldn't like to try to predict the future; they could pull a 360 on us or they could pull a Zune.. or indeed neither.

If anything happens then I would suspect WinMobile 7 will be the turning point but that won't be until next year iirc and might still be targeted mostly at 'office' types who don't need 3D acceleration on their phones (honestly, it's not something I've missed; my features tend to be touch screen + hardware QWERTY keyboard)

[glfreak]

Maybe it needs something like this:

glBeginEffect(effect_ref)
glBeginTechnique(0)
for(i = 0; i < technique[0].numPass; i++)
glBeginPass(i)

...drawing commands

glEndPass();
glEndTechnique();
glEndEffect();

Get rid of explicit state management

Get rid of binding mechanism

Everything has to be doe through the effect mechanism

[Brolingstanz]

I'll never understand the concept of playing a game on a phone.

Anyways, even with an effect system state has to be set explicitly at some point - if not by you then by someone else. Most seem to prefer to have control over this stuff themselves anyway.

[glfreak]

And are drivers now any better with the new spec?

How many IHVs tried to make 3.1 drivers so far?

What's next? GL 4.0?

Cannot we just bring OpenGL to the point it has same features as D3D 10 without need of extensions?

[Brolingstanz]

Glfreak is "Strawman" - man of a 1000 sombreros.

You set 'em up and I'll tear 'em down.

:)

[ScottManDeath]

Troll me once, shame on you. Troll me twice, shame on the mods :)

[Jan]

Once? Twice? Let me count the ways...

[glfreak]

The problem with some forums is that when someone has a strong argument or a controversial question, his post is taken as a "troll," or lets say it's a way to kill the topic, and hence ppl will lose their interest in giving their opinion...anyways

[Jan]

No, if people give their opinion once or twice on this forum, even it it is unpopular, there is not much of a problem. People just don't like it, if the same question/discussion is posted every fu ck ing week, with bad grammar and really really bad arguments in general (or no arguments, at all, just trolly "OpenGL IS DOOMED!! DOOOOOOMEEEED!!!!111oneeleven" 'arguments').

There is a reason you are rated two stars. I regularly wonder, whether you mean anything seriously, or this is all just fun and games for you.
Even IF you are indeed interested in OpenGL, it won't improve by your really dumb threads, so please, spare me and others the pointless discussions in the future and stick to questions/discussions that are really of some value.

Jan.

[Dark Photon]

Thanks, Jan. I've been deferring my urge to reply with something similar.

[glfreak]

since u offended me this way and insulted my posts and grammar :) then go fu...ck ur ass...and yeah GL is almost dead!

[V-man]

Take it easy dude.
From 3.0 and onwards, it is going to be about getting rid of the old cruft. Change obviously comes very slowly in GL land.

Cannot we just bring OpenGL to the point it has same features as D3D 10 without need of extensions?
By extensions, I guess you mean getting function pointers with wglGetProcAddress. A new dll will never get created for Windows by the ARB. That is the responsibility of the platform maker - Microsoft.
Those are the facts, whether you like it or not.

[Dark Photon]

since u offended me this way and insulted my posts and grammar :) then go fu...ck ur ass...and yeah GL is almost dead!
If you think so, what does that say about you hanging around here?

Personally I know you're all wet, but please: get rid of the doom crap, or take your sign and go preach on some D3D corner.

[Brolingstanz]

Don't worry, Glfreak, I've nothing but love and respect for you.

Anyway, on the brighter side of life...
- GL3 headers have been updated in the registry
- OpenGL 3.1 drivers have been released
- OpenCL drivers have been released

And on the Linux front things have never looked better
- Driver installation is a snap (with F10 anyway)
- Creating a GL3 context with X is easy!

Heck it's high time to throw a few shrimp on the barbie and pop open a cold brewski..

[glfreak]

Which IHVs have released full implementation of GL 3.1 so far other than the NVIDIA?

If ripping 75% of the 2.1 features and tagged them under deprecated extension makes GL streamlined API and driver implementation is alot easier and reliable, where is the other IHVs from that?

It's not troll, Khronos :), it's just you fucked up the GL spec, and you still dont have core GS for god sake.

:D

[Alfonse Reinheart]

If ripping 75% of the 2.1 features and tagged them under deprecated extension makes GL streamlined API and driver implementation is alot easier and reliable

Once the ARB abandoned Longs Peak, they also abandoned making GL implementations more reliable via the specification. You are expecting results that the ARB no longer intended to provide.

[glfreak]

Interesting to know this.

Again I'm not trolling as some may say, but I'm trying to understand what is going on that they abandoned all the Longs Peak or whatever they called, and came up with an awkward spec. that focuses on deprecation, giving the excuse that implementation will be easier and more reliable, while we don't have GL 3.1 except from NVIDIA, and which has some bugs as some reported.

And now someone please tell me why on earth version 3.1 does not include geometry shader as core functionality?

[Brolingstanz]

And now someone please tell me why on earth version 3.1 does not include geometry shader as core functionality?

I'll wager GS (or its equivalent) makes its core debut in 3.2.

Then maybe that's just wishful thinking...

[glfreak]

As I understand, GS is an uncertain feature yet to be a core functionality?

If not, why?

thanks.

[Alfonse Reinheart]

Do any of the IHVs like Geometry Shaders? Maybe they intend to remove Geometry Shaders in the future. OpenGL does not need yet another core feature that is not future-compatible.

[glfreak]

I'm more curious to know why IHVs don't lie geometry shaders? Then why did they created it in the first place?

[Ilian Dinev]

Some find GS is rarely useful for them. Others like to stick to DX9-class hardware. Others didn't like the synthesis performance of the first cards with GS.
With time, this can change.

[Brolingstanz]

Btw, what's up with depth clamp?

I was just dotting my i's and crossing my t's in a little 3.1 state preparation extravaganza and I noticed it's not core yet. Could have sworn it was.

What gives?

:)

[Alfonse Reinheart]

Then why did they created it in the first place?

ATI once created an extension specifically to do vertex weighting. NVIDIA once created a different extension to do a much more limited form of vertex weighting. Both of these were made obsolete by vertex shaders.

Why did they create these extensions, and the hardware behind them? Because it sounded like a good idea at the time.

Geometry shaders are a perfect extension. They expose hardware-based features. But when the day comes that there is a better way to get at similar features (tessellation shaders. Pre T&L > post T&L), the extension can be dropped. If it was core, it could not easily be dropped without going through the deprecation process.

Core features should be things that the ARB is certain about being future-proof.

[Dark Photon]

I'm more curious to know why IHVs don't lie geometry shaders? Then why did they created it in the first place?
New generation of GPUs needed a new feature to provide incentive for folks to upgrade? Problem: 1st gen performance. If developers don't code for it, user's aren't compelled to upgrade to get it.

Wonder if it'll go the way of the dodo once the tessellator-capable GPUs take hold (starting ~4Q09-1Q10). That's gonna be cool. Good precedent with consoles.

[Nicolai de Haan Brøgger]

I think GS has a niche with point sprites, or? There's probably a few other techniques where it's the preferred approach... A lot of developers were just expecting something else than it really turned out to be.

[Ilian Dinev]

Another technique that is boosted by GS maybe is edge-related stuff, generally in NPR rendering.

[zeoverlord]

Geometry shaders are a perfect extension. They expose hardware-based features. But when the day comes that there is a better way to get at similar features (tessellation shaders. Pre T&L > post T&L), the extension can be dropped. If it was core, it could not easily be dropped without going through the deprecation process. I think it will make it into core someday, if it's replaced it will probably be replaced by a more generalized way of using shaders, like perhaps a programmable pipeline or something.

It is useful though for point sprites, impostors, fins, leaves, vegetation, volumetric->vertex conversion, shadows and a bunch of other stuff we haven't even thought of.

I think the reason it's delayed is that they have to see what a possible future tessellation shader will look like as they might interact a bit.

[Brolingstanz]

Let's not forget about render-to-cubemap, stencil shadow volume generation and of course the wonderful lines you can draw with a GS :)

If future GL tessellation works the way it will in d3d11 it'll be an addition to not a replacement for the geo stage. Tessellation itself is actually still canned in d3d11, sandwiched between 2 new programmable stages responsible for transforming control points and evaluating patch surfaces. Don't see this as a geometric amplification/decimation/manipulation/synthesis panacea per se but it is mighty cool.

Of course there's always compute interop and the many-core storm that's brewing over the horizon...

[glfreak]

Hmmm so the ARB do not see it any worthy feature right now?

Or they think it will be dropped by HW in the future...then it's not a problem to add it now to the core API because they got the deprecation mechanism ;-)

Besides I asked about geometry instancing long time ago, and why it's not part of GL core, since Direct3D already had it, and the answer was very strong that GL does not need this feature but D3D because the later has drawing call overhead. And now we see it part of the latest core GL spec. You may say that ARB later on realized its potential and decided to add it to the core. I agree, but not anymore since they have the deprecation model :)

Don't get me wrong dudes, I'm just trying to reason things...
GL has been my fav API and still, until I had to switch to D3D because of some HW lack of proper support. However, when one of the biggest companies in the CAD industries start thinking of an alternative...I feel frustrated.

[Brolingstanz]

> Hmmm so the ARB do not see it any worthy feature right now?

Right now it's anybody's guess what the ARB thinks. However, as it seems ATI has seen fit to include GS among the new features of its 9.6b drivers, there's a fair to midland chance that it'll make it to the core in 3.2.

Lately I'm again wondering what's on the plate for GLSL in the coming days. Cg has interfaces and DX11 has added classes, obvious portents of shading languages becoming a bit more object oriented. Seems to me there are some welcome perf implications here in addition to a significant convenience, stuff beyond the mere syntactic sugar one might be tempted to thumb one's nose at.

[Alfonse Reinheart]

What are the "welcome" performance implications of object-oriented languages? Do they not perform at the same speed or slower than other languages?

[Brolingstanz]

The goodness with the object oriented approach is (at least) twofold.

1. Combat the combinatorial explosion created by lots of e.g. light/material combos automagically. This is the "convenience" bit, which is considerable.

2. An efficient linker can inline and optimize interface code (at the source level) on the fly. This is the perf bit.

Now couple these with true multithreaded operation (read: compilation) and you've got yourself a real barn burner IMHO.

Convenience aside, the underlying assumption here is that it's still better perf wise to special case code where possible, despite recent improvements in the handing of ubershaders.

[Eosie]

Just a thought ... What would be better for GLSL than being replaced by Cg? Nothing, I guess. ;)

Anyway, I wouldn't use a shading language without parametric polymorphism (think C++ templates). Even Cg interfaces seems to be more like the parametric polymorphism than inclusion one. I use C++ templates in CUDA C and it's VERY useful for writing uber kernels.

[Brolingstanz]

Yep... I see in the CL registry they've added a nice C++ binding (cl.hpp) along these lines.

[glfreak]

I dont see any need for OO support shader languages, since the concept of an object has no evidence in the shader paradigm. Besides shaders are not consider large-scale modules, not yet.

In the near future shaders will completely replace the API, and become part of the unified CPU language...

[Brolingstanz]

You're probably right. Probably makes more sense in the long run to have 2 or more languages to battle for a given programming task, each with its own problem reformulation requirements.

The "worst" part of GPGPU right now is having to manage parallel reformulations to scale with core counts and the glue necessary to connect it all together with the runtime. Not so bad perhaps here with the initial baby steps, but as things more forward a bit in complexity, CUDA, CL, Larrabee/Ct, etc. start to look a lot better on a standalone basis, if you get my drift. Not so much the OO end of it but the multi-language aspect that really chaps my arse.

[glfreak]

I'm more afraid of OpenCL it gonna end totally open to the IHVs where it fails stability and lags behind its current spec version.

For me, "Open" implies "optional" which means it's up to whatever platform to provide whatever version, whatever quality :)

I see GPGPU is a contemporary tech that will die slowly sooner as soon as we get n-core CPUs capable of even handling ray-tracing, then good bye to APIs :)

[Gedolo]

The binding mechanism must die!

OpenGL needs to have an API-oriented versioning scheme.
With clear cuts, not just profiles of one version.
More something like:
3.y line
3.y line: compatibility profile
(until here, everything is legacy from the current situation)
4.y line: incompatible with 3.y, only where necessary
(tada progress and an api cut)

The 3 and 4 line can be supported on drivers.
Each app can use 3 OR 4 but not both.
Graphic cards should be multi-tasking.

Old apps can run in a 3.y context while new apps written in 4.y context run in the newer 4.y context.

Anyway, here is the link to my reply on the OpenGL 3.2 official feedback thread:
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&amp;Number=261969#Post2619 69