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 6 of 22 FirstFirst ... 4567816 ... LastLast
Results 51 to 60 of 212

Thread: Official feedback on OpenGL 3.2 thread

  1. #51
    Administrator Contributor
    Join Date
    Jan 2002
    Location
    Mt. View, CA
    Posts
    97

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by dpoon
    So in the GLSL 1.50 spec the precision predeclaration for the float type should have been highlighted in magenta.
    To speak somewhat in our own defense, the GL and GLSL specs are huge, complex documents that go through many, many revisions during the process of creating a new version. John and I try to keep the change markings sensible but it's not going to be a 100% error free process; they're mostly just a guideline to finding changed stuff, to accompany the new feature summaries. We don't mark the places where a lot of text is removed with strikethroughs, for example. Our focus is on getting the new spec out on schedule, so some stuff like this is always going to fall through the cracks.
    Jon Leech
    Khronos API Registrar
    ARB Ecosystem TSG Chair
    GL/EGL/GLES Spec Editor
    ...and suchlike

  2. #52
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    578

    Re: Official feedback on OpenGL 3.2 thread

    I see the use/reason of having forward compatible and profile selection (i.e. core vs compatibility) separate as they address 2 different issues, but those issues over lap (at this point a great, great deal)... and can you imagine the mess that occurs when trying to teach this stuff to people new to GL? They will scream that one is splitting hairs.

    But I am really surprised that a bindless edit buffer object, I figured that it would have been a kind of no brainer to specify and for driver writers to deal with, something simple as for each buffer object type function glSomeBufferFunction, a new function glSomeBufferFunctionNamed which had one extra parameter, a GLuint of the buffer object; ditto for texture stuff too.

    One point of irony for me right now is the deprecating (or saying only in compatible profiles) is the naming of interpolators in shaders, I prefer, in the language of GL_EXT_separate_shader_objects, "rendezvous by resource" instead of the current "rendezvous by name". The argument of removing an interpolator at link time to optimize I have always found to be kind of thin (especially since for each tuple (vertex,fragment) or (vertex,geometry,fragment) shader one had to have a different program).... does anyone have some reasonable real world examples where one leaves an interpolator present if it would get optimized out?


    Just out of curiosity, is there active movement on:
    1) direct state access
    2) separation of texture data from filtering method
    ?

    I am starting to think, given that 2) is quite hairy to do well, we won't see anything like that till GL 4.0...

    Also, I am really, really overjoyed that the GL API is now getting updated more regularly, is that pace expected to remain? (I suspect that the pace of so many updates will slow once GL core exposes all features that D3D of that time exposes, and then once there only big updates at new GFX card generations and minor updates handling making things "cleaner")

  3. #53
    Administrator Contributor
    Join Date
    Jan 2002
    Location
    Mt. View, CA
    Posts
    97

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by kRogue
    I see the use/reason of having forward compatible and profile selection (i.e. core vs compatibility) separate as they address 2 different issues, but those issues over lap (at this point a great, great deal)... and can you imagine the mess that occurs when trying to teach this stuff to people new to GL? They will scream that one is splitting hairs.
    They overlap but the use cases are very different. The FC context is really only intended as a futureproofing aid for developers, along the lines of the (otherwise so-far mythical) "debug context". Personally I wouldn't even tell someone new to GL about it for quite a while.

    Separation of filters and samplers is on the agenda for a future release, yes. DSA has been brought up as well, though it is perhaps less far along in terms of being seen as desirable by everyone.
    Jon Leech
    Khronos API Registrar
    ARB Ecosystem TSG Chair
    GL/EGL/GLES Spec Editor
    ...and suchlike

  4. #54
    Junior Member Regular Contributor
    Join Date
    Jan 2004
    Location
    Czech Republic, EU
    Posts
    190

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by GeLeTo
    glTexImage being async comes at a cost - it will most likely create a copy of your image data right away. And this is what I want to avoid.
    You can't avoid the copy with glBufferData. The data MUST be stored in page-locked system memory (to make sure your operating system won't move it) before it can be asynchronously transfered to the GPU. There is only one way to access this memory directly and so to avoid the copy - glMapBuffer{Range}. The same applies for textures: use PBO. The buffer object represents both a GPU buffer and a corresponding buffer in page-locked system memory.

    If I understand correctly, you want to have a fine-grained control over PCIe transfers. In CUDA it's easy, you can use cudaMemcpyAsync and place a fence (called "event" in CUDA) after that, and then ask whether all preceding commands have ended. Because you have no such control in OpenGL, it's hard to give advice. ARB_copy_buffer might help here but I am not sure. As someone already said, "only driver guys can tell".
    (usually just hobbyist) OpenGL driver developer

  5. #55
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    578

    Re: Official feedback on OpenGL 3.2 thread

    ... Personally I wouldn't even tell someone new to GL about it for quite a while.
    That is my point, someone new to GL would say "What the?" But it is quite awkward if you look at what effective practice was:

    GL3.0: request forward compatible context to make sure one was not using naughty deprecated stuff, mostly fixed function pipeline.

    GL3.1: ditto, but if you did not request a forward compatible context then expect ARB_compatibility to be present, chances are then code to check if it there; often the context creation code is buried in some platform dependent monster that nobody likes to read, worse for cross platform code.

    GL3.2: now be aware of difference between deprecated features and compatibility features, in theory a twisted one could request a forward compatible context and request a compatible profile (shudders).

    hopefully, no more new context creation attributes will be added.

    On a related note to my post (but not to GL 3.2) reading GL_EXT_separate_shader_objects, I found something that I thought was just plain *bad*

    16. Can you use glBindFragDataLocation to direct varying output
    variables from a fragment shader program created by
    glCreateShaderProgramEXT to specific color buffers?

    UNRESOLVED:

    Tenative resolution: NO for much the same reason you can't do
    this with attributes as described in issue 15. But you could
    create the program with the standard GLSL creation process where
    you attach your own shaders and relink.

    For fragment shader programs created with
    glCreateShaderProgramEXT, there is already the gl_FragData[]
    builtin to output to numbered color buffers. For integer
    framebuffers, we would need to add:

    varying out ivec4 gl_IntFragData[];

    User-defined output fragment shader varyings can still be used
    as long as the application is happy with the linker-assigned
    locations.
    my thoughts on that are *ick*... since if one is doing MRT, then you would possibly need to call glDrawBuffers on every shader switheroo... ick... would be better if they just added a pragma like interface to fragment shaders:

    Code :
    pragma(out vec4 toFrag0, 0)
    pragma(out ivec4 toFrag1, 1)
    or extend the layout() deal in fragment shaders:

    Code :
    layout(fragment_output, 0) out vec4 toFrag0;
    layout(fragment_output, 1) out ivec4 toFrag1;
    and along those lines one could then use that kind of mentality on interpolators, i.e in vertex shaders:

    Code :
    layout(vertex_output, 0) out vec4 myValue;
    layout(vertex_output, 1) out flat myFlatValue;

    and in geometry shaders:

    Code :
    layout(geometry_input, 0) in vec4 myValue;
    layout(geometry_input, 1) in vec4 myFlatValue;
     
    layout(geometry_output, 0) out vec4 myValueForFragging;

    and then even in fragment shaders:

    Code :
    layout(fragment_input, 0) in vec4 myValueForFragging;
    but on closer inspection since out/in qualifier is already there, it can all be collapsed to:

    Code :
    layout(location, N) in/out [flat, centroid, etc] type variable_name;

    The sweet part of this being that one can then dictates where attributes and interpolators are, the lazy could even skip calling glAttrbuteLocation...

    This comment probably would be best in suggestion for next release or some kind of GL_EXT_separate_shader_objects thread.

  6. #56
    Administrator Contributor
    Join Date
    Jan 2002
    Location
    Mt. View, CA
    Posts
    97

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by kRogue
    GL3.2: now be aware of difference between deprecated features and compatibility features, in theory a twisted one could request a forward compatible context and request a compatible profile (shudders).
    You can do that, but as previously noted, nothing is deprecated from the compatibility profile, so a forward-compatible compatibility profile is exactly the same thing as a non-FC CP :-)

    I would be a little surprised if any of the remaining deprecated-but-not-removed features in the core profile are actually removed from core anytime in the near future. It's challenging enough dealing with the number of options we have today.
    Jon Leech
    Khronos API Registrar
    ARB Ecosystem TSG Chair
    GL/EGL/GLES Spec Editor
    ...and suchlike

  7. #57
    Junior Member Regular Contributor
    Join Date
    Mar 2004
    Location
    Austin, TX, USA
    Posts
    109

    Re: Official feedback on OpenGL 3.2 thread

    [quote=kRogue]
    ...
    On a related note to my post (but not to GL 3.2) reading GL_EXT_separate_shader_objects, I found something that I thought was just plain *bad*

    16. Can you use glBindFragDataLocation to direct varying output
    variables from a fragment shader program created by
    glCreateShaderProgramEXT to specific color buffers?

    UNRESOLVED:

    Tenative resolution: NO for much the same reason you can't do
    this with attributes as described in issue 15. But you could
    create the program with the standard GLSL creation process where
    you attach your own shaders and relink.

    For fragment shader programs created with
    glCreateShaderProgramEXT, there is already the gl_FragData[]
    builtin to output to numbered color buffers. For integer
    framebuffers, we would need to add:

    varying out ivec4 gl_IntFragData[];

    User-defined output fragment shader varyings can still be used
    as long as the application is happy with the linker-assigned
    locations.
    my thoughts on that are *ick*... since if one is doing MRT, then you would possibly need to call glDrawBuffers on every shader switheroo...

    ...

    This comment probably would be best in suggestion for next release or some kind of GL_EXT_separate_shader_objects thread.
    I don't like this, either. The previous issue, about vertex input attribute binding locations, has the same problem. I'm used to binding my vertex attributes to known locations when I load a shader, to avoid both excessive vertex array rebinding and to remove the need to query and store the locations of every attribute, for every shader...

  8. #58
    Senior Member OpenGL Pro
    Join Date
    Sep 2004
    Location
    Prombaatu
    Posts
    1,386

    Re: Official feedback on OpenGL 3.2 thread

    A big sloppy kiss for the quick ref cards!

  9. #59
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Official feedback on OpenGL 3.2 thread

    I don't like this, either.
    Which is why this is an nVidia extension (despite the EXT name) and not the eventual solution to this problem. It tries to solve the problem by making OpenGL pretend to do things the D3D way, but without realizing that OpenGL has issues with doing things that way.

  10. #60
    Junior Member Newbie
    Join Date
    Nov 2007
    Posts
    22

    Re: Official feedback on OpenGL 3.2 thread

    By the way, does anyone know if glu.h is ok with the gl3.h header file? I know some of glu is no longer relevant to openGl 3.2, is it compatible at all with a forward context?

    Many thanks

Posting Permissions

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