Pipeline Newsletter Volume 4

do we really need long peeks?
Yes.
It’s true that some things that will be introduced in Longs Peak could be introduced to GL2.x.
However, there are enough reasons to release new API: performance, driver development issues - you can read about it in the first newsletter.
Also, new features could turn out to be against OpenGL 1.x/2.x specs.

Besides, we’re now in the age of programmable functionality. We must pay with some blood and tears to keep up. In my case it’s gonna be rather joy and hapiness, but I’m willing to pay :smiley:

Originally posted by Ido Ilan:
[b] Please don’t flame me but do we really need long peeks?
To me it seems that OpenGL 2.1 is a just little messed up form 20 years of evolution, why not remove the redundant calls/types… (like OpenGL ES 2.0).
I love the way OpenGL is organized, the current state machine is very powerful and elegant (it does have limitation on debugging/understanding) .
To me long peeks seems like some DirectX version.
Yes it will be easier for driver writers and have fewer overhead but all this can be achieved with current OpenGL going the way the ES went.

I know Korval,knackered and the rest will flame me but still do we need it?
Ido [/b]
Most of opengl is centred around legacy fixed functionality, so most of opengl is an anachronism.

To me long peeks seems like some DirectX version.
If you’re referring to D3D10, I don’t see anything wrong with that :wink:

Besides, it comes as no surprise to me that new APIs targeting today’s and tomorrow’s hardware should look pretty similar.

Doubt microsoft is putting the same thought into the long term. They’ll happily change the whole api in a couple of years. We can laugh, but at least d3d10 is out and being used.

If it is similar, it is better since the thousands of new games that will come out soon could easily be ported to Mac and Linux. I’m pretty sure no one will switch from DX to GL on Windows itself.

BTW, MS has no choice but to obsolete their own software. They are a business.

If it is similar, it is better since the thousands of new games that will come out soon could easily be ported to Mac and Linux. I’m pretty sure no one will switch from DX to GL on Windows itself.

Even worse, who will use the new API?, current academic are using old fixed pipeline or switching to DirectX (see many recent gpu related graphics papers), games are using DirectX, maybe the workstation market will switch but it is a field changing very slowly.
people are used to the current API if they need to learn a new one what will make them learn OpenGL over DirectX?
I fear that the new API will be the downfall of OpenGL instead of its future.

You would have to go to those academics and do a little market research. If it’s gaming related, then it makes sense to use DX. You have to serve your audience.

If it’s some GPGPU thing, from what I understand these guys want GLdouble support and some specific hw features. They typically use GL and shaders are important to them.

…If it’s gaming related, then it makes sense to use DX. You have to serve your audience.

Why does it make sense? The gaming world is the engine that pushes the graphics industry, if OpenGL is of no usage in that area it will die slowly. Why should someone who is interested in graphics learn OpenGL if most companies uses DirectX. People don’t care if its OpenGL/DirectX as long as its look good and run smoothly.
OpenGL will turn into a niche market (smaller then today) and I don’t believe that alternative OS is almost any factor in choosing to learn OpenGL in the future.

Well, that alternative “Linux” OS might not be that important for gaming in the near future. However, Apple just started to get onto the same track MS did 1995, that they want their OS to become important for gaming. I am not a Mac user, mostly because Macs are no gaming machines today, but i do hope, that their strategy is successful, because OpenGL is THE one and only 3D API for Macs and it would become very important for game developers then. Who would want to use D3D, if one can develop with OpenGL for EVERY platform, except the 360 (and maybe the Wii, i don’t know) ?

In my opinion OpenGL does have the potential to become very strong again, if Apple is successful in bringing mainstream gaming to the Mac. However, for that to happen, we need an API which is designed with hardware in mind that we have today and possibly in the next 5 to 10 years. In this market, that is one of the fastest growing one, it is a pain to work with an API that was designed 15 years ago. And it is getting worse with every new hardware generation.

Longs Peak does not even force you to do the API switch in one go. You can just create a new context, and start using it, while still using your old code, so you can slowly adapt to it.

In the end it will be EASIER, to learn and use Longs Peak efficiently, than it is today to learn OpenGL. Lets face it, OpenGL is a mess. Granted, you can still get started with it in few hours, but MASTERING it is more like black magic, because there are so many ways to do things, so many unknown and unintuitive pitfalls.

With Longs Peak there will hopefully be only few ways to do things and those will be the “right” ways. For starters it will be more difficult, when you only look at Longs Peak, because stuff like immediate mode and display lists will be gone. But the idea is to build an “ecosystem” around OpenGL, that will provide such things in utility libraries. So, instead of glBegin/glEnd you might be writing gluBegin/gluEnd with Longs Peak and the utility library will encapsulate all that stuff for you, so that you can get started as fast as today.

I don’t doubt, that within half a year after Longs Peak is out, we will have libraries like glu, glut, glew and SDL for it, that will make everyone’s lives very easy. And i am pretty sure, that 90% of todays OpenGL programmers will happily adapt to it, because of easier use, less maintenance, less extensions to work with and, very important, better and faster drivers.

And i don’t doubt, that the ARB will not disappoint us with the final specification.

Jan.

mostly because Macs are no gaming machines today
Have you seen recent presentation of Id Tech 5 engine? John Carmack presented his engine on Macintosh. It’s a very good platform for games, so it’s only the question of market actually.
Remember that Playstation 3 means OpenGL.
So now you have 3 alternatives:
#1 - DirectX 9:
Xbox 360 + Windows XP/Vista
shader model 3.0
#2 - OpenGL:
PS3 + Windows XP/Vista + Macintosh (+ Linux)
shader model 3.0/4.0
#3 - DirectX 10:
Windows Vista
shader model 4.0

#2 gives you similar market to #1. PS3 instead of Xbox - I think that’s disadvantage, but you get Macintosh as compensation.
But the thing is that #2 also gives you what #3 does.
So you either develop in both DX9 and DX10, or with OpenGL (with SM4.0 features used if available).
Now if we could only make ATI expose OpenGL API under XBox, but I bet we can’t. Microsoft surely has taken care of it (by the means of technology and law).

in the end it doesn’t really matter which api you use, does it? It’s currently a piece of cake to have a renderer support gl and d3d, and pretty necessary. Just as it doesn’t matter which OS you use, the differences are trivial. Currently the only significant platform consideration is the shader language you use and the number of CPU cores, and how best to utilise them.

in the end it doesn’t really matter which api you use, does it?
From programmer’s point of view it doesn’t matter. It’s the platform that enforces given API upon you. And it’s the market that enforces platform.

My choice today would be DX9, DX10 and OpenGL only for PS3. My choice after release of Longs Peak / Mt. Evans would be: DX9 only for xBox and OpenGL for all others.

OpenGL will turn into a niche market (smaller then today) and I don’t believe that alternative OS is almost any factor in choosing to learn OpenGL in the future.
The problem with your argument is simply this:

Things for OpenGL are not going to get better by not radically redesigning the API. Minor alterations, removal of old functionality, aren’t going to entice anyone who is thinking of using D3D to not use GL.

OpenGL was designed a long time ago. Many of the basic assumptions that they made in good faith back then just aren’t valid today. Simply poking at it isn’t going to improve it at this point. A redesign allows the ARB to create an API that is fast, easy to implement (fewer bugs. Maybe ATi implementations will stop sucking :wink: ), and easy to use.

Quite frankly, OpenGL’s biggest problem isn’t the API per-se: it’s its famous unreliability.

Game developers really want their game to work on ATi, nVidia, and Intel hardware. Unfortunately, only nVidia’s drivers are actually good at OpenGL. The others are somewhere between buggy and horrible in terms of implementation quality. Meanwhile, their D3D implementations are all pretty damned good (though the Vista versions are still lacking). Which would you choose?

LP is promising because it simplifies implementations. It makes it easier for implementers to write their code by lessening the requirements on the implementation.

k_szczech: You didn’t read my post carefully. I was actually referring to exactly that presentation.

Macs are no gaming machines today in that there is no gaming market for them. Hardware is ok, but not high-end. If we are lucky, Macs will be opened up in the near future, so that i can build my own PC but instead of Vista i install OS X (with the gfx card I like).

But unless there are games, that are produced for Macs, MacOS is not an option for gamers.

Jan.

Originally posted by Korval:
[b]Quite frankly, OpenGL’s biggest problem isn’t the API per-se: it’s its famous unreliability.

Game developers really want their game to work on ATi, nVidia, and Intel hardware. Unfortunately, only nVidia’s drivers are actually good at OpenGL. The others are somewhere between buggy and horrible in terms of implementation quality. Meanwhile, their D3D implementations are all pretty damned good (though the Vista versions are still lacking).[/b]
I think something that would help considerably in this regard is a reference implementation and/or conformance tests. A ‘one true implementation’ to compare programs/drivers too so there is some sort of consistency in the OpenGL world.

An OpenGL32.dll reference impl. that I could drop into my program to see if it’s my code or the driver screwing up would be great.

Regards
elFarto

@elfarto: Mesa3D … almost

OpenGL really lacked conformance tests for versions 2.0 and 2.1. Neither GeForce 7 nor Radeon X1800 are OpenGL 2.0 compilant, but both report it.
I want my programs to talk to OpenGL server like this:
-Do you support this feature?
-Yes.
Not like this:
-Do you support this feature?
-Yes.
-Ok, let’s see if it works…

We have to wait and see what requirements will Longs Peak put on implementation, but I’m hoping this issue will be addressed.
I know it’s easy to ask for that and it’s much more difficult to do something about it. Hardware is allready at the market and if it doesn’t support FP16 filtering then what can we do about it? Remove it from specs? Limit Longs Peak to DX10 class hardware only? Of course not.

But unless there are games, that are produced for Macs, MacOS is not an option for gamers.
You mean like World of Warcraft? Or the upcoming StarCraft 2?

I think something that would help considerably in this regard is a reference implementation and/or conformance tests.
How would that help? Do you think that ATi and Intel aren’t aware of the miles of bugs that are in their drivers?

ATi isn’t going to throw off their monthy driver release schedule simply because their GL implementation doesn’t pass conformance. The best way to ensure that drivers are more reliable is to make it easier for developers to make them reliable.

Originally posted by Jan:
Who would want to use D3D, if one can develop with OpenGL for EVERY platform, except the 360 (and maybe the Wii, i don’t know) ?
The Wii can be seen as just a overclocked Gamecube. It has a OpenGl’s fixed pipeline like api. So many calls look the same after a s/gl/ngc/ regexp :wink: The main differences I saw are on the multitexturing, where you set one operation for the whole set of TU (like “TU0*(TU1*0.5)+TU2”), instead of one operation per TU.

On the other hand there’s also the PS3 out there, which is a third area I don’t want to care about . I don’t know about their gpu api, but creating an engine for ps3 will require quite a lot of specific coding on the cpu (ppe + several sce, very slow memory meanings nearly no use of virtual functions…) :slight_smile:

Originally posted by Jan:
Longs Peak does not even force you to do the API switch in one go. You can just create a new context, and start using it, while still using your old code, so you can slowly adapt to it.

If you make a long peak context, then the old GL functions are not available.
If you make a GL 2.1 context, then LP functions are not available.