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 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 48

Thread: A quote from - Mark J. Kilgard Principal System Software Engineer nVidia

  1. #11
    Junior Member Newbie
    Join Date
    Jun 2013
    Posts
    25
    Personally, I'm a firm believer in encouraging new people to use the most painless, easy to use and configure API features available and they will have the best chance of succeeding, especially if they don't need fancy-pants methods.

    Except for the dangers of unavoidable situations like the OpenGL ES 2.0 spec which severed the incredibly valuable link between the old and the new. Those devices support both, however those machines have such tight memory space and bandwidth constraints that this unfortunate situation is understandable and necessary.
    Yes it is absolutely absurd to expect mobile devices to have 100 MB+ drivers packages that would allow for a robust and fully-featured OpenGL environment... for now!

    In the future this is likely going to happen and they will soon all be able to give the Dynamic Duo of desktop machines a run for their money in shear diversity of API combinations available.

    Please don't get me wrong here! Bang, exclamation point. In no way shape or form should any present or future development be made on 'immediate mode." That would be like carpenters investing time and money into developing new types of screws. There would be no point.

    The nVidia documents that stongly indicates that no legacy features will be removed also state that no future consideration will be given to them. They have already been optimized and tested and refined. They will take up nobody else's time. There is no concern that research time and effort are being wasted on that stuff. They are not reinventing the wheel over and over again with legacy code. That legacy code ran on machines that are nothing but pocket watches compared to machines today. There is no way that stuff is running slower now than it did on crappy, old machines.

    Legacy has not caught up in sheer raw, large scale performance, so what, why use a car in a situation where a bicycle will do?. Legacy will not go anywhere unless it is specifically conflicting with modern functions. Why should it? It takes me 5 minutes to download the absurdly large driver packages.

    If you want to eliminate bugs from your code, the best way to do it is to always test your software on as many GPU's as possible, as often as possible. I keep two old junk laptops on hand for this very purpose. One is a very old, and very weak, x1150 mobile Radeon that my friend's girlfriend spilled juice on. The drivers for that machine are buggy to begin with. I know that if it runs on that machine then it will run on almost any computer that is newer than 5 years old.

    I also keep a mobile Intel GPU machine that was made right when Intel finally caught up with ATI/nVidia shader model 2.0/3.0 hardware. I also know that if it works on this then it will work on everything without any fear of bugs creeping in on someone else's computer.

    I also test using the WINE emulator on a regular basis when I've been making substantial changes using features that behave differently under different circumstances.

    Using newer features such as floating point textures is a poop-field so far as truly cross-platform goes. What works beautifully on some cards cannot be implemented properly on another made by someone else.

    To resolve this issue, we all have to work together to build a cheat-sheet that has input from hundreds of people that has all been tested on hundreds of machine configurations. Either that or we have to wait for the various manufactures to play catch-up with one another. We can wait for them to do it or we can do it ourselves. Then people will be able to use it safely and reliably, and the GPU maunfacturers will have clear, documented evidence that will help them eliminate bugs in their drivers and circuits.

    OpenGL 4.0+ currently has a big problem since a five stage shader and all the accompanying features have a lot of kinks to be worked out. Most people that come here do not have huge teams of software designers and testers at their disposal to get this working consistently across many platforms.
    We have to do this ourselves or there will once again be huge repositories of bug ridden code several years from now.

    It would be better if we make listings of people's efforts with trial and error. Under many different circumstances.

    For instance, "Which newer extensions are giving people problems, and on which machines?"
    and also, "Which of the newer extensions are known to work consistently on all available platforms?"

    If we create a repository of these basic facts then we will have helped to resolve this issue of GPU manufacturers being unwilling to share results with one another.

    Bug testing something as seemingly simple as a floating point texture is out of the reach of most people since there are no reliable threads where people have listed what is working for them and what is not. The old standard of people listing their machine specs has all but disappeared. That's probably a good thing since I used to think these forums were nothing but horrible hardware and API flame-wars. This has changed a lot over the years and places like this have become more civilized and productive... usually.

    After not bothering with forums for half a decade I can now honestly say that they are now doing people some good. Arrogant, demeaning attitudes have toned down a lot. This is a good thing. Learning this stuff will do a person no good if they are also learning to act like a condescending, arrogant know-it-all
    jerk at the same time.

    What we do not have is a comprehensive list of what works and what does not. We need a bug list, a cheat-sheet that spans back over 15 years of people's experience with OpenGL, the new and the old. All updated, current and with nearly bug-free solutions because it's all of our combined experience with these various API changes and additions over the years.

    We have to do this ourselves, if I were to share some known bugs and pitfalls for beginners that none of them would likely find written anywhere unless they already knew what to look for, then it would be something the following.

    It would start a "benefits and bugs" wiki page that looks something like the following.

    //-================================================== ================
    Section-> (Fixed-function tied to GLSL)
    //------------------------------------------------------------------------------------------------------------------------
    PRO's: Very easy to use. A beginner could write and configure animation and lighting shader's very easily.
    //------------------------------------------------------------------------------------------------------------------------
    CON Not yet possible on mobile devices!)
    //------------------------------------------------------------------------------------------------------------------------
    CON: Most source code for this style was written when only a few driver models were automatically performing casting.
    There is a lot of very interesting source-code from that era, but even to this day, all of those horrible casting errors are still tripping
    up a lot of the new player's in the GPU arena. Driver's on mobile devices can't handle that much crap being thrown at them.
    //------------------------------------------------------------------------------------------------------------------------
    PRO: The Dynamic Duo are champs at fixing these problems with very little overhead.
    //------------------------------------------------------------------------------------------------------------------------
    Specific Bug listing A_1: gl_frontmaterial.shininess will not yield consistent results across many GPU's. Apparently, different manufactures are using a different procedures behind the scenes for this one. It's the only one I've found to be unreliable for cross-hardware/platform of all the common ones.
    //------------------------------------------------------------------------------------------------------------------------
    CON: Any time that a fixed-function material or lighting variable is used in GLSL: All possible fixed function material and lighting parameters available to GLSL will be added to the compiled shader even if they are not all being used. This is not as bad as it sounds, this method was working reasonably fast enough back in the Radeon9800/nVidia FX days so it's not going to slow down something made in the last few years. It's not practical for mobile devices yet but will not trip up a modern machine in the least. Not so far as most people go in their first several years. There are bigger fish to fry.
    //------------------------------------------------------------------------------------------------------------------------
    PRO: Learning to pass in your own Uniform variables is an easy enough optimization to consider once you've finally gotten your feet wet and you are not feeling so overwhelmed.

    //-================================================== ================================================== =============

    If the manufacturers will not give us a modern , up-to-date, fully backwards compatible bug repository then we will have to do it ourselves.

    Once a format for a wiki like this is decided upon, these bits of accumulated 'wisdom' can be posted to a wiki so people browsing the free repositories are not constantly stepping in poop.

    Just think back to when you had various successes and problems with all the different methods over the years. Give the good and the bad, how did using a feature make your life easier as a beginner? How did you overcome the pitfalls that you ran into? Things like this built into a wiki will make OpenGL a force that will knock people's socks off, but only if it includes everything OpenGL from beginning to end, 15 years of backwards compatibility that should become rock-solid stable and easy to learn.

    If I see any of it, I'll cut and paste it to a file that will eventually turn into a posting that can be attached to all the links of legacy open source code. Now that stuff won't be broken anymore. People will have instructions on how to fix it all when they use it.

    All those older pages should not be thrown away, they could be made productive and useful again, with little effort on our parts.
    //-----------------------------------------------------------------------------------------------------------------------------------------------
    Tip: For a lot of GPU's, even today, 1 and 1.0 are not the same thing! Don't rely on the driver to fix that for you. Certainly don't expect the shader to always work if you ignore this because it happens to work on your computer.
    Last edited by marcClintDion; 07-05-2013 at 05:41 AM. Reason: grammatical corrections/ proof-reading

  2. #12
    Member Regular Contributor
    Join Date
    Jun 2013
    Posts
    495
    Quote Originally Posted by marcClintDion View Post
    Yes it is absolutely absurd to expect mobile devices to have 100 MB+ drivers packages that would allow for a robust and fully-featured OpenGL environment... for now!
    Capacity isn't the issue here. The issue is that mobile devices don't have any legacy code to run, so there's no need for them to support the legacy API.

    Quote Originally Posted by marcClintDion View Post
    The nVidia documents that stongly indicate that no legacy features will be removed also state that no future consideration will be given to them.
    Herein lies the problem. While the legacy API as a whole may not disappear, you are increasingly going to be faced with an either-or choice. You can use the legacy API or you can use the new features, but not both.

    Apple have already said that new features will not be added to the compatibility profile context, so if you want to use them you need to use a core profile context, where immediate mode and the fixed function pipeline don't exist.

    Another issue is that interactions between newer features and the legacy API are frequently resolved in ways which make use of both impractical. E.g. newer features may have state which can't be pushed and popped, so frameworks which rely upon objects' render methods restoring the state preclude the use of newer features. Newer features may not be usable inside display lists (e.g. instanced rendering is prohibited).

  3. #13
    Junior Member Newbie
    Join Date
    Jun 2013
    Posts
    25
    Quote Originally Posted by GClements View Post
    Capacity isn't the issue here. The issue is that mobile devices don't have any legacy code to run, so there's no need for them to support the legacy API.
    Every single last mobile device supports OpenGL 1.1. Almost every device in use has this general capability, people have been even been using this style of code to program HomeBrew apps for the Wii for many years now. Not everybody is interested in making games that attempt to look like big-budget CG movies. This misinformation is exactly like the flaming arguments that have people fighting over whether DirectX is better than OpenGL or whether or not AMD is better than nVidia. People fight over whether or not C# is better than C++.

    Now this nonsense has turned into an OpenGL vs. OpenGL bicker fest. There is room for all of it and to teach people otherwise is wrong.
    Last edited by marcClintDion; 07-05-2013 at 11:32 AM.

  4. #14
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,212
    Quote Originally Posted by marcClintDion View Post
    Every single last mobile device supports OpenGL 1.1.
    No, they don't. Mobile devices use OpenGL ES which is a completely different API which just happens to be modelled on OpenGL. ES 1.0 and 1.1 are not comparable to OpenGL 1.1, no matter what you may wish to believe.

    You made the same mistake earlier on when you said:

    Quote Originally Posted by marcClintDion View Post
    Mac, iOS, Android, Linux, PS3, Windows, Blackberry, WebGL, etc....
    This is misinformation. This is FALSE. This is damaging misinformation that is as bad as the infamous Wolfire blog post because all it does is serve to perpetuate lies. You're undermining your own argument because you're showing yourself up as someone who's prepared to use lies as a prop for that argument. If you want your position on this to be taken seriously you really need to stop doing that now.

  5. #15
    Member Regular Contributor
    Join Date
    Jun 2013
    Posts
    495
    Quote Originally Posted by mhagain View Post
    Mobile devices use OpenGL ES which is a completely different API which just happens to be modelled on OpenGL.
    Also:
    • No version of OpenGL ES supports glBegin/glEnd; vertex arrays must be used.
    • OpenGL ES doesn't have a compatibility profile. 1.x has a fixed-function pipeline, 2.x has shaders, and never the twain shall meet (i.e. you can't mix the two).

    WebGL is based upon OpenGL ES 2.x, i.e. it has no fixed-function pipeline. Additionally, it doesn't support client-side arrays (anything which can use a buffer object in desktop or embedded OpenGL must use a buffer object in WebGL).

  6. #16
    Junior Member Newbie
    Join Date
    Jun 2013
    Posts
    25
    Quote Originally Posted by mhagain View Post
    You're undermining your own argument because you're showing yourself up as someone who's prepared to use lies as a prop for that argument.
    This is the kind of person that you have proven yourself to be. You have just lied to everyone here by intentionally misquoting what I said.

    You said
    Quote Originally Posted by mhagain View Post
    OpenGL didn't lose the API war through shenanigans; it lost it through design short-sightedness
    Then I responded

    Quote Originally Posted by mhagain View Post
    OpenGL is not going anywhere and it's only getting better as everyone's drivers become more robust and diverse.

    Mac, iOS, Android, Linux, PS3, Windows, Blackberry, WebGL, etc.... Just to name a few big hitters who are all firmly in the scene.
    You said that OpenGL lost a "war" and I responded that OpenGL is not going anywhere.
    I did not say anything about those devices supporting immediate mode.


    Now I'm going to address your lying by quoting you

    Quote Originally Posted by mhagain View Post
    You're undermining your own argument because you're showing yourself up as someone who's prepared to use lies as a prop for that argument. If you want your position on this to be taken seriously you really need to stop doing that now.

  7. #17
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    Quote Originally Posted by marcClintDion
    This is the kind of person that you have proven yourself to be. You have just lied to everyone here by intentionally misquoting what I said.
    You clearly stated that

    Quote Originally Posted by marcClintDion
    Every single last mobile device supports OpenGL 1.1
    which is not even partially incorrect, this is outright wrong. Yet you don't make any effort to show that you're not sure about it, like prefacing it with something like "I think". Well, I think everyone would take that as an intentional statement. An intentional statement which conveys false information is, by definition, a lie. Thanks for playing.

    Quote Originally Posted by marcClintDion
    I did not say anything about those devices supporting immediate mode.
    Do you have any transitive thinking capabilities? Ok, let's work this out. You said OpenGL, which you consider to be used on the following platforms

    Quote Originally Posted by marcClintDion
    Mac, iOS, Android, Linux, PS3, Windows, Blackberry, WebGL, etc....
    isn't going anywhere. Looking at the list, I see at least 3 mobile platforms in there - don't know what subset of OpenGL the famous "etc." uses but what the hell.

    Now, since you mentioned at least 3 mobile platforms and you stated that

    Quote Originally Posted by marcClintDion
    Every single last mobile device supports OpenGL 1.1
    So you imply that immediate mode is supported on those devices due to the fact that it's a OpenGL 1.1 core feature. This directly contradicts you saying

    Quote Originally Posted by marcClintDion
    I did not say anything about those devices supporting immediate mode.
    Quote Originally Posted by marcClintDion
    Now this nonsense has turned into an OpenGL vs. OpenGL bicker fest. There is room for all of it and to teach people otherwise is wrong.
    No, it hasn't. Everyone participating here is unsupportive of your claims. Normally no one should give a brownie about such idle ramblings, but I for one regularly get pissed off at people trying to head back to the early- to mid-90s. All you get is more code and higher complexity which, to quote Bjarne Stroustrup, simply lead to "more bugs". If you really love legacy OpenGL, you have to let it go man.
    Last edited by thokra; 07-08-2013 at 05:08 AM.

  8. #18
    Member Regular Contributor
    Join Date
    Apr 2004
    Location
    UK
    Posts
    420
    Quote Originally Posted by marcClintDion View Post
    Mac, iOS, Android, Linux, PS3, Windows, Blackberry, WebGL, etc.... Just to name a few big hitters who are all firmly in the scene.
    The PS3 does NOT use OpenGL.
    There is an OpenGL|ES wrapper but no one in their right mind touches it because it's too slow.

    I do wish people would stop repeating this incorrectly...

  9. #19
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    600
    At the risk of.. something I am going to add my 2 cents.

    Here goes, on the deprecation stuff:
    1. Removal of immediate mode is in general a good thing; the only loser is those getting started with OpenGL.. the removal just makes the getting started with OpenGL more of pain now
    2. Removal of fixed function pipeline is borderline. The basic mentality to this is that chances are an implementation of the fixed function pipeline made by the vendor will likely be better than doing it via shaders. Additionally, for a large number of situations the fixed function pipeline gets the job done. On the other hand, the interface for multi-texturing in the fixed function pipeline is quite awful so I am glad to see it gone in addition all the state associated to the fixed function pipeline was a pain too.
    3. Removal of QUAD primitive types was, IMO, a mistake. One can simulate it with a geometry shader, but that seems awfully silly. As a side note, OpenGL ES3 does NOT have geometry shaders.
    4. Removal of client side arrays (i.e. non-buffer object backed index and vertex buffers) was IMO a mistake as well. The use case of vertex and index data changing from frame to frame got ickier. With client side arrays, the GL implementation did the right thing for you. Now we play, as Dark Photon has called it, buffer object Ouija board for streaming the data. As a side note, OpenGL ES2 and ES3 DO allow for client side arrays.
    5. glLineWidth... this was weird. It was marked as deprecated but it is not removed. I am grateful it was not removed, but well......
    6. Removal of display lists was not done correctly in my opinion. My reasoning is simple. With a display list, one could define and queue up rendering sequences easily. In an ideal world, the GL implementation did magicks to optimize it. That was great functionality. What did suck was how those commands (display lists) were defined, what would be *great* is a replacement for them.

  10. #20
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,212
    In general I agree with kRogue's comments here, but do differ on a few points.

    Immediate mode served a purpose other than just as an easy entry-point for learning. It was great for rapid prototyping and proof-of-concept work. Even in a scenario where the more traditional immediate mode is removed, I would have liked to have seen glBegin/glArrayElement/glEnd retained (immediate-mode indexing - yayyy!)

    FFP is emulated by the driver via shaders in almost all hardware for close on 10 years. Some elements of FFP however remained useful (I'm thinking primarily fog here) and removing of them just made exponential shader explosion even worse. ARB assembly programs had the right idea.

    Quads should have stayed.

    Client-side arrays should have stayed (but via glVertexAttribPointer with the old glEnableClientState removed). I'm detecting a bit of "D3D envy" in the removal of these (and speaking of "D3D envy" it's tragicomic that in 2013 OpenGL still doesn't have a dynamic buffer object updating API as good as D3D's - no more driver hints! - give us explicitly requested behaviour that you're guaranteed to get instead, please - D3D has had this problem solved since 1999, for crying out loud, there's no need for modern GL to be so over-cautious about it).

    Some hardware doesn't accelerate lines > 1 wide. Deprecating but not removing seems both a concession to that hardware and a cop-out for hardware that does.

    Display lists were far too complex in the old API, with lots of weird edge cases and fiddly rules about what can and cannot be put into them (also refer to the document I posted on the previous page for some lovely examples of interaction between display lists and immediate mode). Agreed that a clean replacement for them would be nice.

Posting Permissions

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