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 5 of 19 FirstFirst ... 3456715 ... LastLast
Results 41 to 50 of 184

Thread: Official feedback on OpenGL 4.0 thread

  1. #41
    Junior Member Newbie
    Join Date
    Aug 2008
    Posts
    3

    Re: Official feedback on OpenGL 4.0 thread

    Quote Originally Posted by Khronos_webmaster
    Someone posted a comment on the OpenGL homepage news story. Hopefully they won't mind if I move the comment over here so it can get some clarification and worthy feedback:

    ---------------------
    First, congratulations on the milestone. Second, as a cross-platform developer I would like to use OpenGL exclusively but itís commercially inviable to use it on Windows, due to the fact that OpenGL just doesnít work on most machines by default, which forces me to target my game to both DirectX and OpenGL. The OpenGL shortcomings on Windows arenít a big deal for hardcore games where the users are gonna have good drivers (although they are a cause of too many support calls which makes it inviable anyway) but itís a show-stopper for casual games.

    If it was me in charge of OpenGL I wouldnít even bother coming up with new versions of the standard until this situation was rectified. I really donít understand why the effort isnít put in working with Nvidia, Ati and Microsoft to rectify the situation. If Microsoft wont help just bring back glsetup! Having to run an installer on installation of your product would be fine. But currently the user has to find good drivers by himself and then reboot, this is unacceptable. DirectX on the other hand can be streamlined as part of the installation. Until OpenGL isnít expected to just work in any Windows box it is dead in the Windows platform. Do something about this please.

    Posted by: Margott
    ---------------------
    Something like 3dsetup would indeed be a good short-term solution to provide people with modern OpenGL drivers. Too bad that Intel isn't shipping any GL3.x let stand 4.x drivers at this point

    Another thing which is VERY related to this. A lot of developers encounter OpenGL driver bugs. Some implementations are buggier than others and this frustrates a lot of developers and it is also one of the reasons that some companies don't use OpenGL at this point.

    In order to improve OpenGL driver quality I would urge developers when they encounter problems, to submit test cases to the 'piglit' an opengl testing framework hosted at http://people.freedesktop.org/~nh/piglit/. At least open source X.org OpenGL drivers are using it as a test bed but nothing prevents OSX/Windows developers to use it as well.

    Roderick

  2. #42
    Senior Member OpenGL Pro Ilian Dinev's Avatar
    Join Date
    Jan 2008
    Location
    Watford, UK
    Posts
    1,290

    Re: Official feedback on OpenGL 4.0 thread

    Quote Originally Posted by elFarto
    The idea of having a textures and samplers separate is so that you can bind the texture object directly to the shader uniform/uniform buffer so...
    That's too counter-productive, imho. Scenes have 5k+ objects visible, different textures each; fewer programs. It makes more sense to group by program, imho.
    In case you meant to bind all N textures for the given mesh-instance at once, I don't think it's viable either: those GLuint names are not optimally mappable during shader execution (are not pointers, and should not be).

  3. #43
    Member Regular Contributor
    Join Date
    Apr 2006
    Location
    Irvine CA
    Posts
    299

    Re: Official feedback on OpenGL 4.0 thread

    Quote Originally Posted by Alfonse Reinheart
    I really donít understand why the effort isnít put in working with Nvidia, Ati and Microsoft to rectify the situation.
    Because none of them are responsible for it. ATI's drivers are OK, and NVIDIAs are pretty good. The problem is Intel. Their drivers are terrible. And if you're making casual games, you want to be able to play them on Intel integrated chipsets.

    The idea of having a textures and samplers separate is so that you can bind the texture object directly to the shader uniform/uniform buffer so you didn't have to play music texture units when you change the shader (rebinding the right texture object to the right texture unit).
    No it isn't. The purpose of separation is exactly what is said in the overview of the spec: to be able to use the same texture data with different filtering parameters without having to do a bunch of texture parameter state changes. This is very valuable.

    And personally, I've come to rather like the game of "music texture units": it allows me to change exactly what state I want. I can use the same shader with different textures very, very easily.

    Under the system you're suggesting, I have to change the program itself to swap texture sets. This is more expensive, both in terms of the number of function calls and how the hardware handles it.

    Personally, what I would like to see is full separation of program objects (compiled/linked programs) from program object state (uniforms, etc). UBOs are about as close to that as it gets, so I'm fairly content with that compromise.
    Progress!

    What kind of GL app are you working on ?

  4. #44
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,181

    Re: Official feedback on OpenGL 4.0 thread

    Quote Originally Posted by Stephen A
    Quote Originally Posted by Groovounet
    Stephen: You just made the joke of the day!

    It seams more honest from Intel to keep quiet.

    I'm not even waiting for an OpenGL 2 implementation anymore.
    Yeah, it's wishful thinking on my part. But hey, imagine an Intel spokesperson announcing that, "we are planning to ship OpenGL 3.3 support by the end of May!"

    Of course, reality kicks soon, when someone asks for the 100th time on how to perform offscreen rendering:

    - User trying to create an invisible window or other broken hacks: "Why do I keep getting garbage back?"
    - Linking to the OpenGL FAQ: "You are not passing the pixel ownership test. Use FBOs."
    - "But FBOs don't work on Intel."
    - "Try pbuffers."
    - "Nope, no pbuffers either."
    - "How about a sacrifice to Kthulu?"
    - "Wha..?"
    - "Just kidding. Software rendering for you."

    That much for "high performance graphics" on Intel...
    Meanwhile I've been quite happily using SetRenderTarget with D3D9 on Intel chips going back to the 915 without a problem.

    The annoying thing is that the hardware actually does support hardware accelerated offscreen rendering perfectly well.

  5. #45
    Junior Member Newbie
    Join Date
    Sep 2005
    Posts
    29

    Re: Official feedback on OpenGL 4.0 thread

    In section 1.2.1 of the GLSL 3.3 spec (Summary of Changes from Version 1.50) it says
    "Added Appendix A to describe include tree and path semantics/syntax for both the language and the API specifications."
    This appendix or any other information does not appear to be in the GLSL spec or the GL 3.3 spec. The related extension (ARB_shading_language_include) says
    "We decided not to put #include into OpenGL 3.3 / 4.0 yet"

  6. #46
    Advanced Member Frequent Contributor Mars_999's Avatar
    Join Date
    Mar 2001
    Location
    Sioux Falls, SD, USA
    Posts
    519

    Re: Official feedback on OpenGL 4.0 thread

    In a word, "SWEET!" I love the new direction the ARB has taken with OpenGL! Keep it coming.

    BTW as for setup of GL4.0, I haven't read the spec, but I am assuming its no different to setup than GL3.2 and similar usage vs. GL3.2?

    Thanks

  7. #47
    Junior Member Regular Contributor
    Join Date
    Aug 2007
    Posts
    121

    Re: Official feedback on OpenGL 4.0 thread

    Great step forward! I just hope drivers will implement all these features reliably. A spec conformity test suite (ŗ la ACID tests for browsers) would be extremely useful for this.

    I know at least 6 developer at my co. that want the ability to separate shader objects and have a binary shader format. Maybe the shader subroutines will help, depending on their performance.

    DSA would be a nice to have, but not imperative since we wrapped all the object binding logic in classes.

    Command lists as BarnacleJunior suggested would also be very useful. They would allow to get the maximum efficiency in the OpenGL draw thread since it would only execute a compiled list of OpenGL commands; kind of like a display list for each frame or each part of a frame.

  8. #48
    Member Regular Contributor CrazyButcher's Avatar
    Join Date
    Jan 2004
    Location
    Germany
    Posts
    401

    Re: Official feedback on OpenGL 4.0 thread

    Quote Originally Posted by Rob Barris
    Progress!
    I agree to look in the future now. OpenGL vs dx9 on dx9 class hardware (most intel integrated stuff) was clearly lost, FBO came too late, GLSL was also a bit dogy compared to the dx9 sm3 (and even compared to the arb program extensions).
    So one should not try to fix the past up, that's just too much legacy, and not worth the effort. But for the sm4+ hardware things look different now, with both apis very close feature wise, and one being able to expose that functionality on all platforms, including win xp.

    I am not sure what the mobile guys work on, but given the lean nature of the "core" profiles, I would think that GL ES might not be needed anymore, for the next-gen mobile stuff.

    out of curiosity, is there a clear benefit of the "link" mechanism GLSL has (vs the dx like individual shaders) for the IHVs? In theory additional optimization could be done, but is this really being made use of?

  9. #49
    Junior Member Regular Contributor
    Join Date
    Mar 2009
    Posts
    153

    Re: Official feedback on OpenGL 4.0 thread

    To all those requesting DSA: write wrapper classes for OpenGL resources and you have DSA. Works great when done well.

  10. #50
    Junior Member Newbie
    Join Date
    Sep 2009
    Posts
    8

    Re: Official feedback on OpenGL 4.0 thread

    Quote Originally Posted by randall
    To all those requesting DSA: write wrapper classes for OpenGL resources and you have DSA. Works great when done well.
    To all those requesting anything from OpenGL: write your own software renderer and you have it. Works great when done well.

    Binding/state system have no benefits. It is a minor problem for IHV and major problem for game programmers.
    It was especially awful in FF days where every routine had to look like:

    glBindALotOfThings();
    glSetALotOfStates();
    glDoSomethingUseful();
    glSetEverythingBack();

    to ensure that 2 different modules won't overwrite their settings. Now with shaders (no state machine there!) and VAO and other fancy stuff there aren't as much "binding places", but for example binding textures (now with additional sampler objects) and UBOs are still cumbersome.

    Less API calls == better performance == profit.

Posting Permissions

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