PDA

View Full Version : Buffer Shaders



Fispear
07-26-2011, 07:09 AM
Good evening every body.

To present my self very fast, i'm a french student and i want become a 3D developer. i supose like you ! ;) Now days, i program since 3 years in OpenGL. So i'm very well with all programable shaders and VBOs. I write this message to submit my suggestion for the next release. Since OpenGL 4.0, the graphic shaders pipe line is :

- Vertex Shader
- Tessellation Control Shader
- Tessellation Evaluation Shader
- Geometry Shader
- Fragment Shader

And i enjoy Tessellation Shaders : there are a very nice new technology ! Well Done !
My suggestion is : add a new shader type like this :

- Buffer Shader <- the new shader
- Vertex Shader
- Tessellation Control Shader
- Tessellation Evaluation Shader
- Geometry Shader
- Fragment Shader

This mysterious shader should be create for programming our own memory access to GL_ARRAY_BUFFERs and GL_ELEMENT_ARRAY_BUFFERs. It should be specialize in unsigned integer computation. I think you will understand why.

example code for GL_PATCH_VERTICES = 3:
// ------------------ BUFFER SHADER


#version 420 // (I supose ??? =D)

uniform layout(location = 0) arrayBuffer VertexBuffer ; // it's a 3 float components array store in the GPU's memory
uniform layout(location = 1) arrayBuffer TextureCoordBuffer ; // it's a 2 float components array store in the GPU's memory
uniform layout(location = 2) arrayBuffer TriangleNormalBuffer ; // it's a 3 float components int array store in the GPU's memory
uniform layout(location = 3) arrayBuffer IdBuffer ; // it's a unsigned int array store in the GPU's memory

out vec4 Vertex ;
out vec2 TextureCoord ;
out vec3 TriangleNormal ;

void main ()
{
// ---------- CALCUL VERTEX MEMORY POSITION
uint VertexPosition = getUint(IdBuffer, gl_PatchId * 3 + gl_VertexId);

// ---------- LOAD VERTEX VECTORS
Vertex = vec4(getVec3(VertexBuffer, VertexPosition * 12), 1.0); // 12 = 3 * sizeof(float) = 3 * 4
TextureCoord = getVec2(TextureCoordBuffer, VertexPosition * 8); // 8 = 2 * sizeof(float) = 2 * 4

// ---------- LOAD FACE VECTORS
TriangleNormal = getVec3(TriangleNormalBuffer, gl_PatchId * 12); // 12 = 3 * sizeof(float) = 3 * 4
// compiler should detect that this previous line doesn't change for each Vertex and execute it only one time per patchs
}

// gl_PatchId is the face drawing number
// gl_VertexId is the vertex drawing number varying from 0 to (GL_PATCH_VERTICES - 1)


And a vertex shader to show inputs.
// ------------------ VERTEX SHADER


#version 420 // (I supose ??? =D)

// ---------- VERTEX SHADER

uniform [...]

in vec4 Vertex ;
in vec2 TextureCoord ;
in vec3 TriangleNormal ;

out [...]

void main ()
{
// classic vertex shader with any differences needed from GLSL 4.1
}


And now 2 new functions for OpenGL API
// ------------------ NEW FUNCTIONS


/*
function to assign each buffer to locations (little like textures)
*/
glBindBufferAtLocation (GLenum target, GLuint buffer, GLuint location);

/*
function to draw with varying gl_PatchId of the buffer shader like :
for ( gl_PatchId = start ; gl_PatchId < (start + count) ; gl_PatchId ++ )
*/
glDrawBufferElements (GLenum mode, GLsizei start, GLsizei count);
or // glDrawBufferElements (GLenum mode, GLuint start, GLuint count);


// ------------------ C PROGRAMM


glUseProgram (BufferShaderId);
glPatchParameteri (GL_PATCH_VERTICES, 3);

glBindBufferAtLocation (GL_ARRAY_BUFFER, VertexBufferId, 0);
glBindBufferAtLocation (GL_ARRAY_BUFFER, TextureCoordBufferId, 1);
glBindBufferAtLocation (GL_ARRAY_BUFFER, TriangleNormalBufferId, 2);
glBindBufferAtLocation (GL_ELEMENT_ARRAY_BUFFER, TriangleIndicesBufferId, 3);

glDrawBufferElements (GL_PATCH, TriangleStartId, TriangleCount);
// may be a GL_PATCH_STRIP ?


Of course all new name i have invented here is only to show how it should work with maximum explicit intentions.
I think this new kind of shader can bring a lot memory size and band-witch optimizations, because in this example, we can separate vertex access and face access, and do lot of other things !
What do you thing about ?

I will be very excited if you like and add my idea to opengl ! Thank you for reading. Please excuse me for my english.

ZbuffeR
07-26-2011, 07:44 AM
This buffer shader sound a bit like a generic OpenCL kernel. Not sure it would useful/possible to support that on GL side.

Groovounet
07-26-2011, 10:56 AM
This is actually a programmable vertex puller which might be doable for AMD or NVIDIA GPUs but unlikely for tiled base GPUs which has dedicated and very optimised hardware for the purpose of pulling vertices.

In any case this is more likely to be a OpenGL 5 (or 6) feature kind of thing as it would require new hardware.

Ilian Dinev
07-26-2011, 11:57 AM
This shader is about to destroy any possible hardware accel of attrib-fetch (which remains on geforces afaik), and complicate things a bit;
for what purpose?
(you know there's transform-feedback, that can do what you're after, right?).

PS, besides, you can already do all that inside the vertex-shader; for which there was a recent discussion about drawing without attrib data.

Groovounet
07-26-2011, 06:54 PM
PS, besides, you can already do all that inside the vertex-shader; for which there was a recent discussion about drawing without attrib data.

I am actually curious to say the performance cost!

But I can see how this approach belong to a certain direction of GPU architectures, I am not sure if this is the right direction.

It does mean that you need to handle yourself the vertex caching, good luck with that, but this is probably possible with EXT_shader_load_and_store.

Damn, I wish I had some time to experiment on this!

Fispear
07-27-2011, 04:36 AM
May be we can program our self a very optimized vertices loading too. Likely tessellation evaluations shaders, we can bring a lot of optimizations. Surly not fast as current vertices loading, but memory size optimization can make the difference. We only should have all infos about hardware band-whish. I also understand OpenGL ES may not have a such shader to keep the maximum speed for vertices loading. ;)
May be it need to change the current buffer shader struct to a more sophisticated. May be with multi call back like tessellation divided with control and evaluation. And what about PATHCH ? I thinks they didn't have a memory band-whish optimized like a GL_TRIANGLE_STRIP. So may be we should program our custom loading to recreate a GL_TRIANGLE_STRIP like.

Can you explain me why this kind of shader need a new hardware OpenGL 5 (or 6) ? I don't understand because it's like a OpenCL kernel who are support on hardwares. And a lot of those hardwares support OpenGL 3.


This shader is about to destroy any possible hardware accel of attrib-fetch (which remains on geforces afaik), and complicate things a bit; for what purpose?
Well, this shaders should be in options of course like tessellation shaders and geometry shader. But now days, with tessellations, displacement map are more and more present, so graphic memory size is becoming very limited for ARRAY_BUFFER. Personally, i'm not a student who is excited with a simple tessellated 3D cub on a black background. Surly my experience isn't as long as your's. :D I recently program a fractal trees generation, and i wanted that each trees are unique. Therefore on a big map, trees' ARRAY_BUFFERS cost a lot of GPU memory. I have optimize a lot with less vertices informations for far trees, and other technics, but i'm sure i can win 40% of actual buffers size with a such shaders. And i'm sure there are a many other renders who need such technic to optimize memory.

Groovounet
07-27-2011, 07:20 AM
Things are probably not as flexible in a GPU as you may expect, especially in term of wires.

Adding this as a proper separate stage would require the "scheduler" to be modified to add this new stage.

However, I don't believe it's not necessary to have a new stage for that and it would work perfectly with EXT_shader_load_and_store, probably more naturally on NVIDIA with GL_NV_shader_buffer_load (and NV_shader_buffer_store?) and using rendering without data (http://ogl-samples.git.sourceforge.net/git/gitweb.cgi?p=ogl-samples/ogl-samples;a=blob;f=samples/ogl-330-draw-empty.cpp;h=6e5611ddc187ed3e49228ea6c856c73c575573 75;hb=HEAD).

Performance wise, I am getting really curious but this might be an opportunity to get rid off the VAO. (and the FBO actually for some cases)

aqnuep
07-27-2011, 08:14 AM
As Groovounet said, this can be solved already with EXT_shader_image_load_store.

You still get good cache support from both pre- and post-transform caches. Why?

Nowadays texturing and buffer access (including vertex attrib fetch) share the same L1/L2 cache hierarchy, and post-transform cache caches varyings anyway, so there's no difference there.

What you lose is that hardware tends to pre-fetch data in case of vertex attrib fetches and as you do it manually, you can expect some latency as a result (this can be frustrating especially if you use indexed primitives, or some custom multilevel fetching as each additional indirection imposes some latency).

aqnuep
07-27-2011, 08:17 AM
PS, besides, you can already do all that inside the vertex-shader; for which there was a recent discussion about drawing without attrib data.

Ilian, can you point me to the discussion mentioned? I'm interested in what type of attrib dataless drawing was the discussion about.

Groovounet
07-27-2011, 08:57 AM
I can't find the post anymore :p

It was just about binding a VAO with no attrib set in it.

Aleksandar
07-27-2011, 12:18 PM
As you've already said, that's one reason more not to use VAO. ;)
I really appreciate NVIDIA's approach in not making VAO mandatory, as well as enabling attributless rendering in both core and compatibility profile. Furthermore, bindless removes need for VAO even in cases where significant number of attributes are enables. It would be nice to make a benchmark to compare efficiency of VAO and bindless side by side.


Ilian, can you point me to the discussion mentioned? I'm interested in what type of attrib dataless drawing was the discussion about.
I don't know if Ilian meant about Rendering without Data: Bugs for AMD and NVIDIA (http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&amp;Main=57198&amp;Number=2967 80#Post296780) , but it was the most recent discussion (about 3 months ago) that I remember.

Alfonse Reinheart
07-27-2011, 12:33 PM
Surly not fast as current vertices loading, but memory size optimization can make the difference.

Do you have any evidence for this position?


Can you explain me why this kind of shader need a new hardware OpenGL 5 (or 6) ?

It's the same reason why Geometry shaders that magnified vertex data had terrible performance until DX11/GL4 hardware: because, even though the hardware can do it, it isn't designed to do so efficiently. So if you want this to actually be worthwhile, you would need hardware that's designed to make it worthwhile. With optimal caches and such.


Nowadays texturing and buffer access (including vertex attrib fetch) share the same L1/L2 cache hierarchy, and post-transform cache caches varyings anyway, so there's no difference there.

For which hardware is this true? Furthermore, textures generally do not generally support indexed accessing. You could implement it as shader logic, but it wouldn't be nearly as fast.

Also, I seriously doubt the post-T&amp;L cache can even work without an index. Since that's what it uses to decide to pull from the cache: if the index for a vertex is in the cache, it pulls from there. That index is the only thing that makes two vertices equal. The post T&amp;L cache can only work when pulling vertex data normally with actual indices.

This is one of the reasons why a general solution would require new hardware to be reasonably fast.


I really appreciate NVIDIA's approach in not making VAO mandatory

Yes, I too appreciate how NVIDIA completely ignores the OpenGL specification whenever it suits them. It's great for a cross-platform API to have one of its chief members treat it like a suggestion rather than a requirement. It certainly helps make OpenGL development that much easier for everyone involved.

:rolleyes:

Aleksandar
07-27-2011, 12:54 PM
Yes, I too appreciate how NVIDIA completely ignores the OpenGL specification whenever it suits them. It's great for a cross-platform API to have one of its chief members treat it like a suggestion rather than a requirement. It certainly helps make OpenGL development that much easier for everyone involved.
I really like your sarcasm. :)
It is bitter but true. Although, I don't think it is such a critical thing. Everything that works on AMD works also on NVIDIA. The opposite, of course, is not true.

Dark Photon
07-27-2011, 05:31 PM
Furthermore, bindless removes need for VAO even in cases where significant number of attributes are enables. It would be nice to make a benchmark to compare efficiency of VAO and bindless side by side.
Yes. I can tell you that I've benched them side-by-side on our large-scale app with a lot of real-world data. In those tests:
VAOs alone helped some, Bindless alone helped more, and Bindless+VAOs was slower than bindless alone. Dan Bartlett also benched and had similar disappointments with VAOs.

* link1 (http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&amp;Number=273112&amp;Words=bi ndless+VAO+VAOs&amp;Search=true#Post273112)
* link2 (http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&amp;Number=274549&amp;Words=bi ndless+VAO+VAOs&amp;Search=true#Post274549)
* link3 (http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&amp;Number=274589&amp;Words=bi ndless+VAO+VAOs&amp;Search=true#Post274566)
* link4 (http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&amp;Number=274589&amp;Words=bi ndless+VAO+VAOs&amp;Search=true#Post274589)

So, I'm not using VAOs at all now but am using bindless (on NVidia GPUs). No sense in wasting CPU time in the driver when you can use it to push more content to your users.

l_belev
07-28-2011, 06:22 AM
Fispear, what exactly is the current problem that your proposal intends to solve?

You mentioned about optimizing memory size and bandwidth. But the vertex buffer bandwidth/size is seldom a problem. Most of the time the textures far overshadow the vertex buffers.
Furthermore even now you can do custom data pulling by using vertex textures and/or doing your custom unpacking/decoding of the vertex data in the vertex shader. What more would the new shader let you do that cant be done now?

Also what is the actual difference between the "buffer shader" and the vertex shader. Remember that the purpose of the vertex shader is to process the vertex data. Your "buffer shader" appears to have the same purpose... Why don't you propose just extending the vertex shader instead, if you think has some deficiency.

Fispear
08-12-2011, 11:05 AM
Excuse me for the late.

Well, i didn't know the using of a custom unpacking/decoding of the vertex data in the vertex shader since few days. I tried it on my fractal trees render. So you right, this new shader isn't necessary. :)

But, something that it could be very nice, is one (or may be more) "index" shaders to pass more integers to vertex shader, or opengl load "him self" vertex data for each inputs of the vertex shader. Because if we can have custom input like gl_VertexID, generate by custom algorithm, we doesn't need index buffer any more for fractal or other generation techniques ! gl_VertexID is nice, but i'm sure we can do better with customs integers generation !

Surly a such shader isn't necessary for classics objects load from files (3ds, obj ...).

aqnuep
08-15-2011, 11:07 AM
Also, I seriously doubt the post-T&amp;L cache can even work without an index.

Definitely not without an index, but you can still do some nice stuff even if you use the fixed function indexing. Anyway, I take back my words about post-T&amp;L cache as as more I think more I realize that the hardware cannot figure out when it can reuse previously determined data (this is true even by simply using the built-in gl_VertexID as using it may change the result of the vertex shader even with the exact same input attribute data).



Nowadays texturing and buffer access (including vertex attrib fetch) share the same L1/L2 cache hierarchy, and post-transform cache caches varyings anyway, so there's no difference there.

For which hardware is this true? Furthermore, textures generally do not generally support indexed accessing. You could implement it as shader logic, but it wouldn't be nearly as fast.

On this, however, I still hold my word. This is true for many SM4 GPUs and generally true for SM5 GPUs. Obviously indexing or any other indirection introduces additional overhead but this is not the only case when we have to sacrifice some performance in the favor of flexibility.

kyle_
08-15-2011, 11:47 AM
Anyway, I take back my words about post-T&amp;L cache as as more I think more I realize that the hardware cannot figure out when it can reuse previously determined data (this is true even by simply using the built-in gl_VertexID as using it may change the result of the vertex shader even with the exact same input attribute data).

Why? gl_VertexID _is_ index, so it can cache output of vsh using it safely.
In fact it (HW) probably cant cache shaders using (at least that well) gl_InstanceID and (at all) atomics. Perhaps some other cases elude me, but they are not many afaik.

I also cant see how having programmable vertex puller would prevent caching post transform data. It could be specified in a way that makes it impossible to write shader that pulls differently for the same index (ie make it logically evaluate only once for each index).

Ilian Dinev
08-15-2011, 11:50 AM
the built-in gl_VertexID as using it may change the result of the vertex shader even with the exact same input attribute data
Wait. GPUs aren't memcmp()'ing attributes to see if a processed vertex exists in cache, they're probably using the gl_VertexID - which is quite coherent in its meaning. It's the index, used from glDrawElements, or the automatically-generated index when drawing glDrawArrays (in the latter case vtx-cache cannot be used ever).
Right?

Ilian Dinev
08-15-2011, 12:10 PM
I also cant see how having programmable vertex puller would prevent caching post transform data.

image_load_store :)
But anyway, the greatest argument was that it destroys the HW-accelerated attrib-fetch. And there's the problem of - attribute formats, almost 60 of them :) . Will need lots of built-in glsl functions to be added to decompress them. And if certain gpus don't have hw-accelerated attribfetch (modern Radeons iirc), the custom fetch will definitely have more overhead than what the drivers have for "fixed-func". (e.g. grouping DMA requests in interleaved-attribs nicely, calculating addresses more efficiently)

kyle_
08-15-2011, 12:24 PM
image_load_store :)

whoops, yeah ;)
Didn't have a chance to play with this, so i mentally dump it together with atomics. Doesn't change the fact that features disabling caching are only a few.



But anyway, the greatest argument was that it destroys the HW-accelerated attrib-fetch. And there's the problem of - attribute formats, almost 60 of them :) . Will need lots of built-in glsl functions to be added to decompress them.

Hmmm, not really. We can do bit shifting and type 'casting' so functionally (with glsl) we are all set already.

For performance reasons, we probably would need them, but i dont think this would be ~60. Im sure ARB could come up with slick api that would be small and pretty ;)

But yeah, programmable means slower, and i cant imagine that much work in the puller stage id like to do to justify it. Perhaps hw vendors may justify that expenditure, if we go to far with format counts that need to be supported.

Alfonse Reinheart
08-15-2011, 12:51 PM
Didn't have a chance to play with this, so i mentally dump it together with atomics. Doesn't change the fact that features disabling caching are only a few.

Atomics would do the exact same thing. Atomics is not just about atomically incrementing a variable; you can read from an atomic location and do computations based on it.

In any case, between uniform buffers, buffer textures, and image_load_store, you can do pretty much whatever vertex fetching you want. You just have to pay the price in terms of performance. I don't see what any special API would do to change that price, since the price is, more or less, based on hardware.

Groovounet
08-15-2011, 02:55 PM
I also cant see how having programmable vertex puller would prevent caching post transform data.

image_load_store :)
But anyway, the greatest argument was that it destroys the HW-accelerated attrib-fetch. And there's the problem of - attribute formats, almost 60 of them :) . Will need lots of built-in glsl functions to be added to decompress them. And if certain gpus don't have hw-accelerated attribfetch (modern Radeons iirc), the custom fetch will definitely have more overhead than what the drivers have for "fixed-func". (e.g. grouping DMA requests in interleaved-attribs nicely, calculating addresses more efficiently)

With the packing and unpacking functions we have access to that part of the hardware.

Alfonse Reinheart
08-15-2011, 03:06 PM
With the packing and unpacking functions we have access to that part of the hardware.

No, you have access to the ability. That doesn't mean you're hooked into the optimized attribute loading path. You simply can call GLSL functions that unpack values into floats. That's not the same thing as using the hardware's free attribute conversion scheme.

Groovounet
08-15-2011, 03:53 PM
"hardware's free attribute conversion scheme"

There is nothing free in hardware :p

True for OpenGL 3 hardware but I am not sure if it's still the case.