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 4 of 19 FirstFirst ... 2345614 ... LastLast
Results 31 to 40 of 184

Thread: Official feedback on OpenGL 4.0 thread

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

    Re: Official feedback on OpenGL 4.0 thread

    very nice work and keep up the great pacing (thanks for #include and transform_feedback3)!

    sampler objects look good to me (same as dx10 I think).

    I would have hoped that GL_ARB_explicit_attrib_location would also work for vertex shader outputs, and therefore bring along separate_shader_objects as well... that and some form of binary representation for load times, would also be my picks for very useful additions.

    The buffer centric workflow GL offers is really nice, but Dx still has an edge when it comes to shader convenience. (and tools, can't khronos not just sponsor gdebugger for all)

  2. #32
    Senior Member OpenGL Guru
    Join Date
    Dec 2000
    Location
    Reutlingen, Germany
    Posts
    2,042

    Re: Official feedback on OpenGL 4.0 thread

    Quote Originally Posted by Alfonse Reinheart
    Oh, and BTW: someone (I forget who) will be very happy with ARB_blend_func_extended. Especially since it's core 3.3, which means that most if not all 3.x hardware will be able to use it.
    That would be me! (http://www.opengl.org/discussion_boards/...1694#Post251694)

    And yes, i am VERY happy about that, i did not think that anybody would take it seriously.

    Jan.
    GLIM - Immediate Mode Emulation for GL3

  3. #33
    Member Regular Contributor
    Join Date
    Mar 2001
    Posts
    468

    Re: Official feedback on OpenGL 4.0 thread

    ARB_blend_func_extended is called dual source blending in DX10, but got dropped in DX11 afaik.

  4. #34
    Junior Member Regular Contributor Heiko's Avatar
    Join Date
    Aug 2008
    Location
    the Netherlands
    Posts
    170

    Re: Official feedback on OpenGL 4.0 thread

    And I see there is a link on the front page for an OpenGL 4.0 quick reference card! Also the link announcing online OpenGL 3.2 reference pages is changed so that it now announces OpenGL 4.0 reference pages. Still under construction though, I hope these will be available soon... I still peek at the 2.1 pages sometimes to check quickly how a certain function worked again.

  5. #35
    Member Regular Contributor
    Join Date
    Apr 2006
    Location
    Irvine CA
    Posts
    299

    Re: Official feedback on OpenGL 4.0 thread

    Quote Originally Posted by ScottManDeath
    ARB_blend_func_extended is called dual source blending in DX10, but got dropped in DX11 afaik.
    Can you elaborate on "dropped" ?

    DX11 cards still need to be able to run DX9/DX10 software, so I don't see how this feature could be cut from silicon unless it has simply become another programmable behavior masquerading as FF behavior.. or do you mean that it's just not in the DX11 API any more.

  6. #36
    Junior Member Newbie
    Join Date
    May 2009
    Posts
    12

    Re: Official feedback on OpenGL 4.0 thread

    First of all, great job for the releases. It is really good to see covering dx10 features (Indirect draw commands, seperate sampler states ...) and having support on dx11 before market is going mad about it...

    I want to comment on sampler objects; we bind samplers to texture units but when we want to bind a texture to same unit, we need to set active texture unit and then bind texture to the related target on same unit. We need actual DSA in here. Newborn features seem to expose DSA behaviour but old habits (binding points) cause crawling in my skin... Actually what I want is management of such state values in shader code (material idiom). CgFX got this, HLSL got this, but when we want some material approach in OpenGL we need to coordinate GL code with GLSL code all the time and need to "trust" each other

  7. #37
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Official feedback on OpenGL 4.0 thread

    ARB_blend_func_extended is called dual source blending in DX10, but got dropped in DX11 afaik.
    ... why? What, did they think having more powerful blending function was a bad idea?

    Newborn features seem to expose DSA behaviour
    That's actually a good thing. While it makes the API a bit inconsistent, it means that whenever they do get around to a DSA-style overhaul, that there will be fewer legacy-style functions lying around.

  8. #38
    Administrator Regular Contributor Khronos_webmaster's Avatar
    Join Date
    Apr 2007
    Location
    Montreal
    Posts
    148

    Re: Official feedback on OpenGL 4.0 thread

    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
    ---------------------
    Webmaster Khronos.org and OpenGL.org

  9. #39
    Junior Member Regular Contributor
    Join Date
    Aug 2006
    Posts
    218

    Re: Official feedback on OpenGL 4.0 thread

    Quote Originally Posted by Rob Barris
    Quote Originally Posted by elFarto
    Epic fail for GL_ARB_sampler_objects
    If you have any more ... constructive ? detailed ? ... thoughts to add on that topic, could you type them in here?
    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).

    Regards
    elFarto

  10. #40
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Official feedback on OpenGL 4.0 thread

    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.

Posting Permissions

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