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 9 of 10 FirstFirst ... 78910 LastLast
Results 81 to 90 of 92

Thread: Official feedback on OpenGL 4.1 thread

  1. #81
    Super Moderator Frequent Contributor Groovounet's Avatar
    Join Date
    Jul 2004
    Posts
    934

    Re: direct_state_access_memory?

    I think we will need updated hardware (OpenGL 5.0!) for such feature (2) but I follow it definitely.

    To come back to the image1D != or == to buffer I would like to say that hardware doesn't necessary use the exact same wires (in the chip) to fetch images or buffers data... this is really implementation differences. An close example is uniform buffer vs texture buffer. Very close conceptually, could be identical in the use but there are performances.

  2. #82
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985

    Re: direct_state_access_memory?

    Uniform buffers are a bit different as they have such small size that they can fit in local memory (64KB).
    RW buffers and RW textures are global memory objects thus they are very similar. I still stay at my statement as texture buffers are much like any other buffer object thus RW texture buffers and RW 2D textures are the way to go (I'm pretty sure that DX11 does this the same way even though the terminology is different).
    The NVIDIA extension is also about global memory buffers.
    I don't say that it wouldn't be nice to have a RW buffer type that allows local memory storage but (and I think it should work on current hardware, according to OpenCL spec). But anyway, that's a completely different issue.
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

  3. #83
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    578

    Re: direct_state_access_memory?

    Just an FYI: GL_NV_shader_buffer_store gives atomic read/write operations to data of a buffer object.

    In my eyes GL_NV_shader_buffer_load/store give almost everything one could want in terms of accessing (read and write) of buffer objects (well almost everything atomic reads and writes are restricted to integer types).

    But the bits about smaller, more local bits, I do not know of an extension that gives "arbitrary" read/write access as the NVIDIA extensions.

  4. #84
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985

    Re: direct_state_access_memory?

    Yes, I don't know such either. OpenGL never talks explicitly about shared local memory.

    I think the only way to do such a thing is by using OpenCL and I hardly believe that OpenGL will include any soon explicit info and functionality related to shared local memory. It simply doesn't fit into the current design.
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

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

    Re: direct_state_access_memory?


    Yes, I don't know such either. OpenGL never talks explicitly about shared local memory.
    In http://www.opengl.org/registry/specs...ion_shader.txt TESS_CONTROL shaders sort of have shared memory.

  6. #86
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985

    Re: direct_state_access_memory?

    Quote Originally Posted by Foobarbazqux
    In http://www.opengl.org/registry/specs...ion_shader.txt TESS_CONTROL shaders sort of have shared memory.
    You are right, but this seems rather an exception than a rule. Anyway, I'm pretty sure soon there will be more and more talk about it.
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

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

    Re: direct_state_access_memory?

    There are a large number of issues with separate shader objects.

    This is the "official" feedback thread, so I'm hoping that someone who's responsible for dealing with bugs will deal with these. Granted, there's likely going to be a new spec at GDC, if the previous pattern holds, so it's unlikely that these will be fixed by then. But

    Also, it's clear that the ARB needs to slow down. They released a terrible spec in ARB_separate_shader_objects, one so bad that they didn't even get the state tables for it right. My guess is that SIGGRAPH was too soon after GDC. My suggestion is for the ARB to stop using these arbitrary deadlines and simply release versions when they're ready.

    Don't forget that extensions exist for a reason. Functionality doesn't have to instantly jump from extension to core. It can live as an extension for a while, to make sure that it is specified well enough to make the jump to core. You know, work out the bugs in it before essentially fixing that functionality. If OpenGL is going to have backwards compatibility forever, then the ARB needs to be more selective about what it adds to the core.

  8. #88
    Member Regular Contributor malexander's Avatar
    Join Date
    Aug 2009
    Location
    Ontario
    Posts
    304

    Re: direct_state_access_memory?

    I agree with Alfonse on this one. I'd much prefer to see extensions released as EXT, trickling out as they are completed and then promoted to ARB with changes from developer feedback. Every once in a while, these ARB extensions could be wrapped into a new GL version as they reach critical mass. This would hopefully provide better specifications, and avoid the driver space-race that seems to happen every time a new GL version is released (resulting in drivers with new features that aren't useable for several versions).

    I would much rather see stable, robust OpenGL drivers that perform well than new features every six months that take another six months to become usable. Constantly working around driver bugs/issues/peculiarities takes away from the otherwise relatively pleasant experience I have with GL.

  9. #89
    Junior Member Newbie
    Join Date
    Dec 2008
    Location
    WA, Inland Northwest
    Posts
    4

    Re: direct_state_access_memory?

    I'd much rather see Nvidia, Intel and AMD expand their teams in OpenGL which affords them to maintain this release often approach but follow up every quarter with the secondary teams having squashed the bugs everyone is rightfully citing as show stoppers. No company moves in a quarterly manner so they have the window to release twice a year and update 4 times a years with refinements.

    Then again, that would require investing in their companies and not sitting around trying to downsize and maximize their net profits in the short-term.

  10. #90
    Intern Contributor
    Join Date
    Aug 2009
    Posts
    66

    Re: direct_state_access_memory?

    Pasted text in wrong topic and forum.

Posting Permissions

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