Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 9 of 63 FirstFirst ... 78910111959 ... LastLast
Results 81 to 90 of 623

Thread: The ARB announced OpenGL 3.0 and GLSL 1.30 today

  1. #81
    Junior Member Newbie
    Join Date
    Aug 2008
    Posts
    2

    Re: The ARB announced OpenGL 3.0 and GLSL 1.30 tod

    I read it all. Frustration is understandable, due to promises made for the past 2 years. However this is not a HUGE tragedy. In conclusion it just means more work for programmers.

    This was clearly handled badly in terms of communication, specially the lock down. Being an open organization all meetings should have transcripts, and that way we would know what happens behind closed doors, at least that would allow us to understand the rational behind certain decisions and who is opposed certain features.

    I take from rbarris comments that basically OGL 3.0 is the maintenance of the "Status Quo", OGL3.0 is a competitor to D3D, however the lag of features for real-time developers using either API is pretty much the same. If you want the advanced feature you are dependent of drivers and extensions and have to jump thru a couple extra hoops to get the features you get for free in a D3D context.

    Basically what people wanted was:

    a) A simpler API that could have a fresh start with new drivers done from scratch.

    I think the vendors looked at this and thought - hum writing new drivers does not come cheap, and we still have to support all the legacy code anyway, plus we already have to do D3D10+ that covers 85% of the real-time market anyway. Let's just do what we do every time we need to add new features to OGL, create a new context that relies on extensions - this way, those that want to move forward can use this and those that don't, don't have to implement the extension. This basically translates into a new path to be worked around by app programmers = more work for us, and less work for driver makers. So this makes some twisted sense.

    You can bet that 3D application companies like autodesk, luxology and others that have advanced OpenGL application like Maya, Mudbox, Modo are not very happy with the way this turned out. At the same time certain groups within autodesk (the CAD/VIZ devision) are content with it, since they don't have to radically change their base code.

    Since the main driver makers are part of the group, they share part of the blame.

    b) A cleaner, leaner API that does not have 5 ways of doing the same thing.

    Well that already exist up to a point and it's called OpenGL ES 2.x you can use it on the desktop already but since it is only a wrapper of OGL 2.x code anyway it may not make much sense. However if you want a leaner, cleaner way of writing you OGL application that only uses shaders you can use this API syntax instead. Does not make sense performance wise, but it's a possibility. In the end OGL3.0 initially promised less hurdles to be jumped and this spec ends up adding a couple more.

    Basically what this means is instead of shrinking your code, you now have an extra context to support and basically add a couple of thousand lines to your code if you want to support a OGL3 context in addition to any other context you may have in your engine.

    In conclusion, people are disappointed not so much due to the technical details. In one way or the other there is an extension or workaround that enables feature X to be done on OGL3.0 by adding complexity to the mix, and reducing you target market to people that have cards and drivers that actually can run this kind of context. We wanted a OGL on a diet (i think even the khronos ppl) and it turns out that all it was done these past two years is talk about loosing weight while at the same time eating cake

    Not enough fat was cut, i blame the drive makers for that, not enough was added in a proper way, DSA extension should be central to a new object programming model. There was not enough courage from the board members to break away from the legacy code like it was done from OGLES1.x to OGLES2.x Instead a new getto was created for OGL3.x applications. This specification increases fragmentation of code, and in all aspects is a mess to handle. It will get you from point A to point B just like D3D you just need to code a few hundred extra plumbing lines of code, and pray that the hardware and driver can handle your code correctly.

    In the end it would be nice to know why things turned out like they did. Since the initial vision was much more ambitions. I think it is one of those cases where...

    "You want answers?!!"
    "I want the truth!!"
    "You can't HANDLE the truth..!!"

    Edit: After reading Barthold's version of the truth i really almost can't handle it. Why didn't you come up with this in Jan08? Even earlier, at the time the object model problems began, there is allot of smart people on these forums *i exclude myself* that could work on the problem, and possibly present alternatives.

    I think the conclusion here, is khronos needs to communicate more, and be a lot more open with the communities with witch it should write open standards, and not simply present open standards that do not please the majority of the community.

    I hate to admit it it but Korval is right, nobody like to use OGL as it is. It's a fat API with a programming model from the early 90s. But if you want cross-platform then you have to use it. And there are other reasons why one has to support it, but it's not exactly a joy to use or maintain. OGL needs to turn into the original OGL3.x vision, and it needs to do it FAST, or face extinction in less than a decade.

  2. #82
    Junior Member Newbie
    Join Date
    Aug 2008
    Posts
    1

    Re: The ARB announced OpenGL 3.0 and GLSL 1.30 tod

    This is just kind of insane. Talking about MS vs. the ARB is a joke, since the ARB just commited suicide. The most insulting thing possible is an ARB member asking for future input, after outright killing OpenGL. Then again, if you're going to run an organization with a small amount of cutting edge members, and a huge amount of members who are based on nothing ever improving, what can you expect.

    "Hay, want to keep supporting a 7 year old piece of trash?? ?? What? No? I don't understaaaaaaand!"

    Seriously, it's impossible to see this as anything other than a joke. OGL v2 was the first complete failure that caused most people to flee. But this is something different...whole platforms are being abandoned.

    I don't know why there's even any discussion about NVidia, or ATI, or Intel, or any other company related to graphics. The ARB's core audience are now entirely GL 1.x-related CAD companies.

    Several platforms use 'GL-like' interfaces, rather than anything actually connected to GL, and we now know why.

    Any project with a 'Khronos' member involved should be abandoned immediately. There is no future, obviously. It seems really difficult for Khronos members to understand it, but they've ended OpenGL.

    OpenGL is dead. Khronos killed it.

  3. #83
    Junior Member Newbie
    Join Date
    Aug 2008
    Posts
    2

    Re: The ARB announced OpenGL 3.0 and GLSL 1.30 tod

    Quote Originally Posted by Valion
    Any project with a 'Khronos' member involved should be abandoned immediately. There is no future, obviously. It seems really difficult for Khronos members to understand it, but they've ended OpenGL.

    OpenGL is dead. Khronos killed it.
    Khronos did not kill OGL with Longs Peak, but it certainly did not bring it out of the coma.

    Why would a game programmer pick OGL3.x instead of D3D10+ in platforms where both are available?

    I don't have a good answer for that.

    The khronos group has delivered good efforts, Collada and OGLES2.x are examples of that, so i would not flee just yet. I have big hopes for OpenCL but i certainly hope that group opens up and communicates with everyone that is interested.

  4. #84
    Junior Member Newbie
    Join Date
    Feb 2005
    Location
    Australia
    Posts
    27

    Re: The ARB announced OpenGL 3.0 and GLSL 1.30 tod

    I can understand (and I must admit, at first - I even shared) the frustration and infuriation everyone is feeling. But I seriously suggest you look at things carefully, and realistically.

    OpenGL is not dead, and while OpenGL 3.0 isn't perfect - it's the best the ARB could come up with considering complete and utter internal mismanagement, miscommunication, and over-all poor execution.

    OpenGL 3.0 fails to deliver many things (object model, purely resident buffers, geometry shaders, etc) - but ultimately it is a small improvement for OpenGL developers.

    From a driver perspective, the standard OpenGL 3.0 profile is still going to be as bloated/messy as OpenGL 2.1 - but if you read the spec carefully, you'll notice practically ALL of the fixed function pipeline is deprecated, and then some - which should be removed in OpenGL 3.1 - and while this isn't happening 'right now' as we all hoped it would, it will be happening. Until then, we have the forward compatible context, which with a bit of luck - will have their own driver with all the optimizations we would've hoped for from not having to deal with the legacy cruft.
    (I'm yet to see GLX info... were the open source people not kept in the loop?)

    No, it's not everything we hoped for - and yes, the ARB have lost our trust - but OpenGL is not dead, it's just not there yet.

    I have to agree with Dorbie though, OpenGL 3.1 needs critical priority - and needs to be shipped SOONER rather than later - I'm afraid the bad press, and miscommunication may have damaged OpenGL more than we realize.

    In short, calm down - and read the spec again - especially appendix E.

  5. #85
    Junior Member Newbie
    Join Date
    Feb 2007
    Posts
    2

    Re: The ARB announced OpenGL 3.0 and GLSL 1.30 today

    I am not sure if the ARB went in the right direction with OpenGL 3.0. OpenGL users are usually very conservative. They usually like to use old functionnalities (even if they should not). I am a OpenGL driver developper and believe me, OGL applications are most of the time doing very terrible things. They do those terrible things because the OGL API is quite old and it allows doing those terrible things. So in a way, I'm happy that the API gets cleaned up, but I doubt it was the right decision.

    What is now the advantage of using OGL over D3D? OGL XP multi-monitor support used to be better than D3D support but this advantage is gone with Vista. The biggest advantage of OGL has always been that application writers knew that their applications won't need a total rewrite every year. They'll let OGL driver developpers do all the difficult job of supporting all the old features and all the old data path. That's a very big advantage for most application writers. Of course, it makes driver developper's live more complicated, but we can deal with that (it looks like we`ll have to support OGL 2.0 and 3.0 for a while anyway).

    Now, application writers will discover that this advantage just disapeared, since a lot of old functionnalities they used are now deprecated. It's not clear how long those features will be supported. So know, they're probably thinking: Well, I will have to re-write the rendering pipe of my application anyway, so why wouldn't I switch to D3D?

    That's why I think that OGL trying to copy D3D is a bad idea. Both APIs used to have their own advantages. Now, other than being cross-platform, I don't see what OGL does better than D3D.

  6. #86
    Member Regular Contributor
    Join Date
    Apr 2006
    Location
    Irvine CA
    Posts
    299

    Re: The ARB announced OpenGL 3.0 and GLSL 1.30 today


    Some OpenGL paths that are possible for apps to take:

    a) stay on GL 2.x - apps keep working for as long as GL 2.x drivers are available.

    b) move to 3.0 with few or no source changes - apps keep working as long as 3.0 drivers are available. Use of new functionality is simplified by way of integration into core.

    c) go beyond 3.0 as needed - eliminate usage of deprecated features in order to comply with future releases.

    A key point that is getting missed is that vendors can choose which revisions to support (and for how long to support them). On 3.0 and later, the app is going to make an explicit statement about which flavor API it is prepared to operate on.

    At each juncture I would expect vendors to make an assessment of which apps would be impacted if support for a given revision of OpenGL was dropped from the drivers, and decide accordingly.

    OpenGL applications still don't need a total rewrite every year, because drivers need no longer present a "one size fits all" API. A new driver could ship with a "3.1" or "3.2" path available, and still be able to run 3.0 apps if the vendor chooses to provide that support. By the same token, as apps migrate from 2.x to 3.x, it provides a signal as to how long 2.x support must persist.

  7. #87
    Senior Member OpenGL Guru
    Join Date
    Mar 2001
    Posts
    3,576

    Re: The ARB announced OpenGL 3.0 and GLSL 1.30 today

    On 3.0 and later, the app is going to make an explicit statement about which flavor API it is prepared to operate on.
    Except that there's a big problem with that.

    Longs Peak was initially designed for R300/NV30 quality hardware as its baseline hardware. That is, the minimum a Longs Peak implementation would support is that level of hardware.

    GL "3.0" lacks a lot of D3D 10 features, but it has just enough of them that GL "3.0" proper can only be implemented on D3D 10 hardware. So, if you don't need stuff like integer textures (I'd have preferred uniform buffers) and the like, if your rendering path could have run on DX9 hardware, you can't advance. You can't use post-GL 3.0 API features on hardware that doesn't need "3.0" hardware features.

    LP was a clean break, where form and functionality were properly separated. "3.0" is not.

    which should be removed in OpenGL 3.1
    with a bit of luck - will have their own driver with all the optimizations
    One good reason. That's all I ask. One good reason why any reasonable or sane person would trust the ARB after the epic failure of what they've done here.

  8. #88
    Intern Contributor
    Join Date
    Nov 2007
    Posts
    72

    Re: The ARB announced OpenGL 3.0 and GLSL 1.30 today

    Quote Originally Posted by Rob Barris
    c) go beyond 3.0 as needed - eliminate usage of deprecated features in order to comply with future releases.
    Future releases? Aka... after another 2 years?

  9. #89
    Member Regular Contributor
    Join Date
    Mar 2007
    Location
    California
    Posts
    396

    Re: The ARB announced OpenGL 3.0 and GLSL 1.30 today

    That's good, because I don't think there was enough work before this for the driver teams. They have done such a flawless job of supporting OpenGL 2.1, and I think it is time to give them a real challenge. Supporting three versions of OpenGL will surely keep them entertained.

    When did you say OpenGL 3.1 was due out? Another year? I suppose there will be the obligatory year of silence following that, so I look forward to 2010, when we get to see all the new extensions added to OpenGL 3.1!

    I have already downloaded the DX10 SDK and begun learning it. I will not gamble the future of my company on OpenGL.

  10. #90
    Member Regular Contributor
    Join Date
    Apr 2006
    Location
    Irvine CA
    Posts
    299

    Re: The ARB announced OpenGL 3.0 and GLSL 1.30 tod

    Korval, thanks for the reminder - for many sections of GL 3.0 functionality that can be implemented on 2.x - the improved FBO and VBO capabilities for example - new ARB extensions have been specified against 2.x. You could consider adoption of those extensions to represent a variation on "a" above. Those extensions are in the registry now.

    It's correct that OpenGL 3.0 core specification targets the most recent generations of GPU's: roughly speaking the NV G80 and AMD R600 generations and beyond. This hardware floor provided a motivation to provide an extension path for 2.x as well, for specifically those classes of application that want to continue supporting older hardware.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •