Official feedback on OpenGL 4.1 thread

[Groovounet]

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.

[aqnuep]

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.

[kRogue]

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.

[aqnuep]

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.

[Foobarbazqux]

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.

[aqnuep]

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.

[Alfonse Reinheart]

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.

[malexander]

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.

[mdriftmeyer]

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.

[Gedolo]

Pasted text in wrong topic and forum.