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 7 of 22 FirstFirst ... 5678917 ... LastLast
Results 61 to 70 of 212

Thread: Official feedback on OpenGL 3.2 thread

  1. #61
    Intern Contributor
    Join Date
    Apr 2001
    Location
    Sofia, Bulgaria
    Posts
    65

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by Eosie
    You can't avoid the copy with glBufferData...
    There is only one way to access this memory directly and so to avoid the copy - glMapBuffer....
    If I understand correctly, you want to have a fine-grained control over PCIe transfers...
    No, I don't want that. I want a modification of glBufferData/glBufferSubData that will not copy the data right away but will return immediately and then the driver will wait for the GPU buffer to be available before DMA-copying the data from my original pointer. When this is done the driver will use the new sync objects API to signal that this data is now safe to be deleted or modified. If the app at some time wants the data to be available for deletion or modification before it's copying is ready - it can force this by calling ClientWaitSync.

    See my first two posts in this thread and John Leech's answer for more details on pages 3 and 4.

  2. #62
    Member Regular Contributor
    Join Date
    Apr 2006
    Location
    Irvine CA
    Posts
    299

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by GeLeTo
    Quote Originally Posted by Eosie
    You can't avoid the copy with glBufferData...
    There is only one way to access this memory directly and so to avoid the copy - glMapBuffer....
    If I understand correctly, you want to have a fine-grained control over PCIe transfers...
    No, I don't want that. I want a modification of glBufferData/glBufferSubData that will not copy the data right away but will return immediately and then the driver will wait for the GPU buffer to be available before DMA-copying the data from my original pointer. When this is done the driver will use the new sync objects API to signal that this data is now safe to be deleted or modified. If the app at some time wants the data to be available for deletion or modification before it's copying is ready - it can force this by calling ClientWaitSync.
    Are you not able to accomplish what you want to do using MapBufferRange? Pay careful attention to the extra mapping options it provides that are not available to the original MapBuffer call.

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

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by Brolingstanz
    A big sloppy kiss for the quick ref cards!
    Yes, I noticed them as well. Very nice! I've been thinking about printing them in full colour and seal them.

  4. #64
    Member Regular Contributor
    Join Date
    Nov 2003
    Location
    Czech Republic
    Posts
    317

    Re: Official feedback on OpenGL 3.2 thread

    Nice, Please also make RefCard for Core profile.

  5. #65
    Intern Contributor
    Join Date
    Apr 2001
    Location
    Sofia, Bulgaria
    Posts
    65

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by Rob Barris
    Are you not able to accomplish what you want to do using MapBufferRange? Pay careful attention to the extra mapping options it provides that are not available to the original MapBuffer call.
    No.
    I am moving this discussion here:
    http://www.opengl.org/discussion_boa...;Number=261827

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

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by kRogue

    ... 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.

    I fully agree !!!

    The suggested method to bind attributes to locations from within the shader is an extremely good idea.

    This will make writing GL applications soo much easier AND it would bring us a big step forward in the "binary blob" issue.

    A central part of my GL code is either inefficient or wastes a lot of memory for caching all those states for attribute locations, uniform locations and such. I automatically build shader combos, which generates a few hundred versions of a shader and all those need to be kept track of.
    Often i simply rebind everything, just to make sure, because it would be too complex to keep track of everything.

    I'd say, the current method could be kept as fallback, but allowing the shader writer to fix locations would be great. And the GL could detect, when all locations are fixed, and then allow to query for the shaders binary blob.

    Also an engine could reject a shader, where someone forgot to fix some attribute's location.

    Well, thinking a bit more about it, it is a very complicated issue. For example you will definitely have a problem when you want to do this with uniforms, because an engine could provide so many different uniforms, that when their locations are fixed, some shader will always need some, that would clash.

    Jan.
    GLIM - Immediate Mode Emulation for GL3

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

    Re: Official feedback on OpenGL 3.2 thread

    Would folks be interested in purchasing a pre-printed and plasticized Quick Reference Card? If so how much would be considered the right price.

    PDF would remain free to download course.
    Webmaster Khronos.org and OpenGL.org

  8. #68
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,136

    Re: Official feedback on OpenGL 3.2 thread

    Has anyone tried to program using new NV drivers? I have a problem with them (190.56 beta for XP32), because when try to bind VAO (e.g. glBindVertexArray(m_vaoID[0]) CPU is 100% utilized (both cores on C2D CPU), and program is stopped. It happens even if I use GL 3.0 or 3.1 rendering context. Till these drivers everything worked perfectly using GL 3.1 forward compatible context. Any clue?

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

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by Khronos_webmaster
    Would folks be interested in purchasing a pre-printed and plasticized Quick Reference Card? If so how much would be considered the right price.

    PDF would remain free to download course.
    Perhaps... did a quick lookup on some prices for full colour plasticized prints at a copy shop (assuming double sided prints to safe on plasticizing costs) and that made a total of 20 euro's. Of course this can be done cheaper if mass produced... and they have to be shipped as well (not a big package, but still).

    So I assume for something like 10-15 dollars/euros including shipment I would be interested.

    [edit]I agree with rsp91 (below) that a reference card with only the OpenGL 3.2 core and GLSL 1.50 core functions on it would be even more appreciated. Of course, this means less pages, but I'd still buy it for about 10 euros.[/edit]

  10. #70
    Junior Member Newbie
    Join Date
    Jul 2008
    Location
    Stockholm, Sweden
    Posts
    19

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by Khronos_webmaster
    Would folks be interested in purchasing a pre-printed and plasticized Quick Reference Card? If so how much would be considered the right price.

    PDF would remain free to download course.
    I'm not interested in the quick ref card at all until there is one without the fixed pipeline functions on it... Other than that it looks good and I'd be willing to get one in real life as well as some other nerd gear like an OpenGL baseball cap or something...

Posting Permissions

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