PDA

View Full Version : New(er) spec means new begging.



kRogue
07-27-2010, 08:26 AM
Firstly, I would like to say thankyou in a big way to the people who make the GL specification, I did not expect GL4.1 to come so soon and I am very, very happy about GL_ARB_seperate_shader_objects.

Now onto my begging:
1) Read stencil buffer values from a depth_stencil texture.

2) revisit transform feedback, essentially capture "by resource" instead of by name. Additionally to change what is captured, either by allowing a buffer destination to be 0 (analogous to GL_NONE on glDrawBuffers) or to respecify what is captured (like the NV_transform_feedback).

3) This is an odd request, here goes:
a) allow glDepthRange to do unclamped values for n and f (ala GL_NV_depth_buffer_float)
b) allow to disable z-clipping -w_c <= z_c <= w_c (but still w_c>=0 is there anyways along with x_c and y_c clipping)
c) once z-clipping disabled, then z_n does NOT get clamped to [-1,1]

The idea here is that for floating point depth buffers, one can take "more advantage" of them.

4) I would really love for something like GL_NV_shader_buffer_load to make it into core, but I am not really expecting it. But if the other IHV's can do it, then please, please put it there. It really opens up so much more in shaders.

Best Regards

CrazyButcher
07-28-2010, 02:08 AM
very happy about separate shaders as well, but indeed point 2) "by resource" would allow a convenient workflow with transform feedback, as was provided with the first NV extension.

1) would be indeed powerful to avoid shader image atomics

it's also nice to see that ATI has included EXT_direct_state_access in their latest drivers, and that separate shaders also brings more direct-state functions to core. Bind free manipulation of buffers and textures/renderbuffers is probably the last big feature missing from core. Probably needs a new ES specification in sync with that object-style manipulation.

elFarto
07-28-2010, 02:58 AM
I have to say, almost everything I could want from OpenGL is there now, except for one thing. Those damn texture units! I just want to be able to bind a sample or texture object directly to the shader's sampler uniform. And I'd like samplers to work with UBOs so that I can swap in all the required parameters for a shader in one go.

And I'd like a cherry on top, thanks :).

kRogue
07-28-2010, 07:55 AM
Those damn texture units! I just want to be able to bind a sample or texture object directly to the shader's sampler uniform.


There is actually a use case that specifying which texture unit to use is quite helpful: one can set the texture units and then just change shaders. Also, it is not that much work to just make your own wrapper I'd think to do just what you are asking for. I freely admit that the first time one uses GL it is a surprise, but the current system seems a touch more flexible to me.. that and I do not have to worry if a GLSL program uses a particular texture, only what texture unit it uses (since GLSL programs restore the values of the uniforms when glUseProgram is called)... if they referred directly to a texture (and sampler) it could get ugly when one deletes a texture or sampler..



And I'd like samplers to work with UBOs so that I can swap in all the required parameters for a shader in one go.


I have to confess I do not follow the request... UBO you change what buffer one sources from for a bunch of uniforms... what do you have in mind for samplers to work with UBO's ?

elFarto
07-28-2010, 10:07 AM
Those damn texture units! I just want to be able to bind a sample or texture object directly to the shader's sampler uniform.


There is actually a use case that specifying which texture unit to use is quite helpful: one can set the texture units and then just change shaders. Also, it is not that much work to just make your own wrapper I'd think to do just what you are asking for. I freely admit that the first time one uses GL it is a surprise, but the current system seems a touch more flexible to me.. that and I do not have to worry if a GLSL program uses a particular texture, only what texture unit it uses (since GLSL programs restore the values of the uniforms when glUseProgram is called)... if they referred directly to a texture (and sampler) it could get ugly when one deletes a texture or sampler..
Certainly there are pros for both methods. I guess it comes down to what is quicker, rebinding a texture to a texture unit, or updating a sampler uniform on a shader (bearing in mind, I'm assuming it's being used with the UBO method below).

You also end up juggling all your textures into the 32 (IIRC) texture units. I agree it's fairly straight forward to rebind the textures as needed, it just seems...inefficient somehow.

Deleting the texture could get quite ugly too.




And I'd like samplers to work with UBOs so that I can swap in all the required parameters for a shader in one go.


I have to confess I do not follow the request... UBO you change what buffer one sources from for a bunch of uniforms... what do you have in mind for samplers to work with UBO's ?
Currently, samplers are not allowed to be in uniform blocks. This means if you're using UBOs as a sort of material (storing all the required parameters), you need an extra step of rebinding all the textures to the correct texture unit.

The idea being you bind your fragment shader to the pipeline (yay for separatable shaders) then bind you material properties to the correct UBO binding, and then you can render.

Regards
elFarto

kRogue
07-28-2010, 11:10 AM
Currently, samplers are not allowed to be in uniform blocks. This means if you're using UBOs as a sort of material (storing all the required parameters), you need an extra step of rebinding all the textures to the correct texture unit.

The idea being you bind your fragment shader to the pipeline (yay for separatable shaders) then bind you material properties to the correct UBO binding, and then you can render.


So you would like to do something like this:



uniform Material
{
sampler2D texture;
vec4 something;
vec2 etc;
}


Hmm.. I can see why you would like to do that, but looking at what buffer objects are, just a blob of bytes, what would it mean to put "a sampler in there"? I guess the sampler2D is really just an int, so the buffer object would then store which texture unit to use, but not the texture itself.

Alternatively, if you are willing to use texture arrays you can do:





sampler2DArray lots_of_textures;

uniform Material
{
int which_texture; //index into lots_of_textures
vec4 something;
vec2 etc;
}


I suppose in theory one could start placing lots of textures into one GL_TEXTURE_2D_ARRAY, but gets kind of awkward to do, and it forces the textures to be all in one block of memory (I suppose), and "adding" textures would be ugly.. but it is like a "mega" texture atlas.

There is something you can to some limited extent do though, using GL_NV_shader_buffer_load,




uniform Material
{
vec4 **texture; //unfiltered values as "2D array"
vec4 something;
vec2 etc;
}


and the pointer to pointer texture is a GPU 64bit address of an array of 64bit GPU addresses of the texture data is. This would be raw data from a buffer object. Then you could use subroutine stuff of GL4 to set how to filter.. but I think that the idea of putting image data as a part of a buffer object does not sound right to me... texture units (on some hardware) do something usually and there a limited number too, which implies they do something.

Eosie
07-28-2010, 02:56 PM
Texture units are something like explicit sampler locations. We need them to make texture bindings independent of shaders. Removing the concept of texture units would make our lives harder, not easier.

skynet
07-28-2010, 03:45 PM
I very much agree that textures and samplers (shaders) should stay connected via texture unit ids (although the name "texture unit" is already far stretched in this context).
The same holds for vertex shader input attributes which are connected to VBOs via glBindAttribLocation, UBOs (via glUniformBlockBinding) and fragment shader ouputs (via glBindFragDataLocation).

But what I'd like to see is to be able to initialize sampler uniforms just like any other uniform, too - just in the sense of ARB_explicit_attrib_location.

My own usage pattern for sampler uniforms is:
1) create the shader program
2) fill the sampler uniforms _once_ to predefined texture unit IDs and never touch them again
3) repeatedly bind textures to the predefined units as the program renders various stuff through this shader

So it would be nice to set the samplers to their destined unit right in the shader code.

Have you ever come across any other usage pattern for sampler uniforms?

elFarto
07-29-2010, 05:49 AM
Fair enough, you've all convinced me that my idea would be a Bad Thing™.

Setting the texture unit in the shader itself seems like a good idea.

Regards
elFarto

Chris Lux
07-29-2010, 11:19 AM
But what I'd like to see is to be able to initialize sampler uniforms just like any other uniform, too - just in the sense of ARB_explicit_attrib_location.
I completely agree. According to the GLSL Spec chapter '4.3.5 Uniform' it is possible to initialize uniforms at link time. Problem is we can not do something like this:

uniform sampler2D atlas_texture = 0;

If they would change the type system in the way to allow integer assignments to sampler types this could actually work out.

-chris

Alfonse Reinheart
07-29-2010, 12:26 PM
This is low on the priority list. Like, really low. So low that I'm hesitant to bring it up. But...

Layout location provides great functionality, from allowing shader separation with user-defined varyings to in-shader definition of important constants. And it wouldn't be unreasonable to use them with samplers to assign a (default?) texture image unit.

However, this just doesn't make for good syntax:

layout(location = 0) in vec4 color;

The location specification takes more keystrokes than the actual variable definition. Is there something that could be done about that, something to make defining these things a bit nicer in terms of syntax?


If they would change the type system in the way to allow integer assignments to sampler types this could actually work out.

While it would make for good syntax at the level of the sampler definition, it would push people towards a simple question: if you can initialize it to an integer, why can't you use it like an integer later? Something like the layout location seems more consistent with samplers being a special type with special handling.

kyle_
07-29-2010, 02:03 PM
While it would make for good syntax at the level of the sampler definition, it would push people towards a simple question: if you can initialize it to an integer, why can't you use it like an integer later?
Depending on how you look at it, it could be viewed as pretty consistent, lets just say, that there is no conversion sampler <-> int, but sampler is initializable by int, and thats it.

Edit:
Afaik, not that long ago it was illegal to add float to int, you still could initialize float with an int though.

Dark Photon
08-01-2010, 09:51 AM
However, this just doesn't make for good syntax:

layout(location = 0) in vec4 color;

The location specification takes more keystrokes than the actual variable definition. Is there something that could be done about that
Yeah, I've thought about that too, and as you say, small fish. All that gobbletygook at the front makes the code harder to read -- the "in vec4 color" is the most important part, and the syntax buries it after a bunch of "stuff".

Personally, I've always liked the "semantic" syntax. Maybe something like:

in vec4 color : ATTR(0);

though I don't know how well it meshes with GLSL language rules. That said, I don't use the layout location syntax, as I'm fine right now with the glBindAttribLocation approach.

Dark Photon
08-01-2010, 09:57 AM
4) I would really love for something like GL_NV_shader_buffer_load to make it into core, but I am not really expecting it. But if the other IHV's can do it, then please, please put it there. It really opens up so much more in shaders.
Yes, please. And I'd request its sister extension NV_vertex_buffer_unified_memory (http://developer.download.nvidia.com/opengl/specs/GL_NV_vertex_buffer_unified_memory.txt) even more, because it can do so much for batch submission performance, merely by not wasting so much time in pointless cache misses on the CPU. With this, VBO perf doesn't suck by default, OpenGL performs better by default, and you have more time to render even more content or do other "useful work" during a frame.

Ilian Dinev
08-01-2010, 10:49 AM
#if IS_VERTEX
#define attr0 layout(location = 0) in
#define attr1 layout(location = 1) in

#define varying out
#define varying0 layout(location = 0) out
#define varying1 layout(location = 1) out

#elif IS_FRAGMENT
#define varying in
#define varying0 layout(location = 0) in
#define varying1 layout(location = 1) in
#endif

Groovounet
08-02-2010, 06:31 AM
What about a new level of deprecation?

kRogue
08-02-2010, 07:05 AM
or even one step further:



#if IS_VERTEX
#define attr(X) layout(location = X) in
#define varying(X) layout(location = X) out
#else //ect for other stages and to work with GL_ARB_SEPERATE_SHADER_OBJECTS

Groovounet
09-16-2010, 02:54 AM
New spec mean new wishes:
http://www.g-truc.net/post-0330.html