Hi, i’m wondering what’s happening with opengl and ARB, why they work so slow? I’ve read that VBO took 2 years (!!!) to be accepted by ARB. What’s happening here?
I made a decision a few months ago to work with opengl, and as time passes i’m regreting of that. I see a lot of features being added by DX, and only a few extensions on ARB.
That’s why ARB exists for? for doing almost nothing?
Almost every developer i talk to (opengl programmers) is agree with this. ARB is slow creating new standard extensions.
Look, i love opengl way of doing things, i love its multiplatform, and i know opengl won’t die, mainly because it works great on university and scientific environments. But that’s only because there’s no *nix DX version!
I don’t want to start a flame war here, but it’s frustating, even when i’ve seen great extensions lately, looking the death of my beloved API just because ARB components are too lazy to work on a fastest pace.
Do we need a “dictator”, as MS with DX, to bring opengl to a right (fastest) pace? If yes, then i vote for one.
But opengl can’t continue this way, otherwise Carmack will be the only programmer using it in gamedev envs, and if i have to be honest, i think he is alone atm.
I need to see i’m not wrong with opengl, i choosed opengl with closed eyes a few months ago, now i’m loosing my faith in it.
Just my 2 cents,
Design by committee is alwasy slower than design by one. The Direct3D API is designed why Microsoft. OpenGL is designed by a relatively large group of people who have to get together and agree on the new API extensions. Fundamentally, it is slower.
Yeah, i know that, but that’s not an excuse. That way of working is killing opengl in terms of people using it, the number of newbies that start with opengl and switch to DX because is “cooler” is growing everyday, and the worse, they don’t switch back to opengl.
And why is that? because ARB is slow. Perhaps ARB might “quit” some committee members and stay with the better contributors (that is biggest graphic HW manufacturers and probably SGI). That way the pace would be faster and we (developers) would be happier, don’t we?
Im not really sure waht your after…
ok arb_VBO took a long time to finish, but the polygonthroughput wasnt really that a big deal 2 years ago, the fillrate of the cards was to low anyway…
Arb_Vertex_program is just a short snap away from VS2.0 ( loop and branch is on its way), same for Arb_fragment_program, its better than PS1.4 but not relly ps2.0 ( or i might be wrong on that onw, havent checked it out that much)
all the textureblenmodes has been there for a while ( for cards without pixelshaders) and are almost the same as D3Ds texturestagestates.
HLSL… well yes, its not finished yet, but you could use cg for the time being.
slow progress has a advantage, its not so much ‘wrong discisions’ as a dictator api… look at the development from dx3 to dx9… they missed much features and did many things in the wrong way… leading to changes that forced dxcoders to rewrite large portions of their programs if they wanted just one little new feature from an newer dx version. but for opengl you can take an old 1.1 compatible program and just start testing fragmentprograms… not needed to change any other call. (take a dx3.0 and try vertex/fragment shaders… you have lot of work there )
Im not saying that dx or gl is the best, i just pointed out the differences between 2 ways of dealing with changes in an api, dx has been a short fast road with many quick turns, and is now a pretty nice interface, and so are opengl.
maybe you can tell that ARB is slow, and probably slower than DX, but you can not deny that vendor-specific extensions are fast, faster than DX in essence.
Yeah, they can be faster, but is a real pain code for all the vendor specific extensions (and their fallbacks of course).
Ok, as i said in previous messages i don’t want to start a flame war, as i think this is not a correct place. I just wanted to point that ARB must work faster if they don’t want nobody uses their work.
I think we, ogl developers, must start some kind of movement to make ARB to work faster. Is better for us, and is better for opengl too.
Ok now for the constructive points : what do you propose for faster ARB work ?
More members ? Refunding ? other ?
[This message has been edited by vincoof (edited 05-12-2003).]
More members? no, that can only be worse. Less members.
IMHO 3 or 4 members (graphic HW manufacturers) and SGI as supervisor would do a nice job. The question here is to adapt technologies in a standard way. NV, 3dlabs and Ati do almost the same, so why don’t put all that in an ARB fashion? they do it for DX… (at least they implement what MS says) I don’t say to do the same, but to put extensions with the same functionality in an standard way.
Less than 30 ARB extensions in 10 years… doesn’t seem too much work don’t you think?
Of course opengl worked great without extensions for the first… 5 years?
Originally posted by toni:
[b]Less than 30 ARB extensions in 10 years… doesn’t seem too much work don’t you think?
Of course opengl worked great without extensions for the first… 5 years?
I think OpenGL 1.0 came into existance in 1992, so that would make it 10 or 11 years it exists.
Between then and now there has been over 200 extensions created. Of course, not all of them are ARB, but there are plenty of EXT extensions as well.
Some members, like MS should be removed (they actually quit).
I think that the speed at which extensions are created has nothing to do with people using D3D.
You dont even know what you are worried about.
How long have you been learning 3D graphics? 1 month? 2 months?
I think ARB is not a bad thing as it permits Opengl 1.x to support new features. If not, how would be opengl graphic cards ? you may buy an opengl 1.3 one, and someone else the 1.3.1… surely not a good solution (to my point of view).
Now that telling dx is even better is the worst thing so could tell: Any societies were behind M$ for that (and all). So this is not surpising that M$Dx is faster than OpenGL. However, do you feel free that only (now) commercial computer things are good ???
This is just because money make things now…
Anyway I’m for OpenGL and won’t let DX come into my Linux !!! I’ll fight against it (in the right sense) if it wants to come to our free opened community.
So dangers come from similar thoughts: what for do you want M$ to come to invade free ? isn’t it better to think at the reverse ? ( that free comes into M$ ??). So DX may could work with gl ?
Correct me if I’m wrong, but extensions aren’t to extend OpenGL and not “be” OpenGL?
Anyway, it would be good if someone created a library that can load user-defined extensions, especially now with the release of Cg and the incomming of OpenGL 2.0 Shader Language. ThanQ,
I think that is a good thing not to ba fast. But also not to be slow is a better thing!!!
I like OpenGL 'cause there’s a *nix version too. I like Windows NT/XP as a O.S.
I don’t like Direct3D.
But when will the OpenGL 2.0 will come out?!?!?!!?!?!?
Do I have to wait 30 years???
I don’t want to flame but the speed the ARB is moving is like a turtle, an OLD dying turtle.
Hope OpenGL won’t die. Hope OpenGL will strike back with a real 2.0 vesion.
I won’t write a line of OpenGL code till the 2.0 will be released.
I find this a curious discussion, because I see a lot of desire for the next version of OpenGL to come out, and thoughts that the ARB should work faster… but no suggestions for direction or desired changes (other than ‘kick out some people’ - which would really have very little effect in reality).
If you have specific features you would like to see, then please suggest them here and to your favorite IHVs.
If there isn’t anything you particularly desire, then the API is obviously evolving faster than your needs… so there is little reason to change the process.
A standard HLSL has certainly taken a while. It took a long time to get critical mass behind it, and then longer to sway the remaining major players. I would have preferred it arrived more quickly. I’m confident that when it does arrive, however, it will be well suited to my current and future needs.
I’d love to see some /specific/ requests.