Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 10 of 12

Thread: Vertex Shader Scatter via gl_VertexIDOut and Transform Feedback

Hybrid View

  1. #1
    Junior Member Newbie
    Join Date
    May 2013
    Posts
    17

    Vertex Shader Scatter via gl_VertexIDOut and Transform Feedback

    Hello there.

    I am just wondering if it isn't trivially possible to implement functionality to scatter an output vertex to some arbitrary position into a transform feedback bound buffer via a vertex shader for OpenGL 3 Core?!

    I use TF currently like this:

    Code :
    // Single vertex shader with transform feedback, pseudo:
    in in_vert ;
    out out_vert ;
     
    void main()
    {
        // maps input_buffer[gl_VertexID] -> output_buffer[gl_VertexID]
        out_vert = in_vert ;
    }

    This means, I map input vertices with gl_VertexID to the output buffer where that vertex is placed on index gl_VertexID.
    That just works fine.

    Now the question is, wouldn't it be possible to do something like this
    Code :
    // Single vertex shader with transform feedback, pseudo:
    in in_vert ;
    out out_vert ;
     
    int f( int id ){... do some mapping... }
     
    void main()
    {
        // default: gl_VertexIDOut = gl_VertexID
        gl_VertexIDOut = f(gl_VertexID) ;
        // maps input_buffer[gl_VertexID] -> output_buffer[gl_VertexIDOut]
        out_vert = in_vert ;
    }

    So that the currently processed vertex does not go to position gl_VertexID but to position gl_VertexIDOut.
    That would also be coincident with gl_PrimitiveIDIn and gl_PrimitiveID.

    I use texture buffers a lot and there would be tons of applications which could use that functionality because those application are not requiring the rasterizer nor any fragment shader invocation.

    If such thing would be possible, that would be GPGPU like hell or maybe totally like

    So long.

  2. #2
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    592
    To get random writes, the only thing is GL4 hardware feature: GL_ARB_shader_storage_buffer_object found in GL core 4.3 and above. As for GL3, not that I know of.

  3. #3
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Now the question is, wouldn't it be possible to do something like this
    Um, no.

    That would require:

    1: That a vertex shader knows that it's writing to transform feedback, rather than to the rasterizer. They don't. At link time, they know that they can write to TF, but it's perfectly legal to use shaders with TF params without actually storing the values.

    2: That TF makes any form of sense when writing arbitrarily to the buffer, rather than in incrementing values. It doesn't. How would you even know how many primitives had been collected into a feedback buffer if you have random writes? Indeed, what does random vertex writing even mean? Remember: TF writes primitives, not vertices. So unless you're drawing GL_POINTS (and only a GS can enforce that), it doesn't make sense to randomly write anything. Vertex shaders operate on vertices, not primitives.

    To get random writes, the only thing is GL4 hardware feature: GL_ARB_shader_storage_buffer_object found in GL core 4.3 and above.
    Nonsense. Image Load/Store does random writes just fine. SSBOs are really just a nicer-looking form of buffer texture load stores.

  4. #4
    Junior Member Newbie
    Join Date
    May 2013
    Posts
    17
    In my opinion, that would make a lot of sense unless you dont know the mapping. You are just thinking too ... linear, Alfonse. But you are right, Im just talking about points. So it would be:
    - use GL_POINTS as data items
    - disable raster
    - set TF buffer

    Since I dont have any further understanding of the technical aspect within the GL, I just leave it by that. I was just curious.
    Last edited by noopnoop; 08-05-2013 at 12:18 PM.

  5. #5
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985
    No, you are thinking too... non-sense. Transform feedback is what it is. It is not scattered write functionality. ARB_shader_image_load_store and ARB_shader_storage_buffer_object is scattered write functionality.
    Transform feedback is meant to feed back transformed primitives. Makes sense, right?
    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/

  6. #6
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    592
    Alfhonse is right, GL_ARB_shader_image_store allows one to get random writes to a buffer object via imageBuffer types. Wonder what caused that brain fart of mine.

  7. #7
    Junior Member Newbie
    Join Date
    May 2013
    Posts
    17
    No, you are thinking too... non-sense. Transform feedback is what it is. It is not scattered write functionality. ARB_shader_image_load_store and ARB_shader_storage_buffer_object is scattered write functionality.
    Transform feedback is meant to feed back transformed primitives. Makes sense, right?
    Now, that statement is like no statement. You could even have written nothing. Would be as good as that.

    Except Alfonse, the other posters dont really contribute to the discussion, since those posters, except Alfonse, dont read the original post. I can not see any point in it where I am talking about ARB_shader_image_load_store. So much to that. You just want to ++Posts

    Ok, since there are always people who claim to know everything best, like aqnuep, can someone explain a bit more precisely, why it matters for the vertex shader know about that it is writing into a tf buffer? All the vertex shader is doing, is to pass through the vertices. From input to output. Now, where is the difference in having the vertex shader put a vertex to a specific position?

    If that doesnt make sense, than something like a load/store would also make no sense. It would be exactly the same but doable with transform feedback.

    Only because you can not image use-cases for that doen't mean it "makes no sense". That is all I want to say.

    My biggest concern is that too many people post too much crap. Like aqnuep. I just wanted to participate is a discussion about what would be possible and not about telling people that they are stupid, because something does "make no sense". I will not post anything here anymore. Those two liners are, thinking knowing everything make me ill. Or people like aqnuep. Putting "Disclaimers" in their foot-line about what crapy things they are posting is only "personal profile". Now that "Disclaimer" makes no sense in what so ever. This is like a disclaimer of an 10 year old, like your posts.
    Last edited by noopnoop; 08-07-2013 at 09:11 AM. Reason: forgotten

  8. #8
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    592
    Ok, since there are always people who claim to know everything best, like aqnuep, can someone explain a bit more precisely, why it matters for the vertex shader know about that it is writing into a tf buffer? All the vertex shader is doing, is to pass through the vertices. From input to output. Now, where is the difference in having the vertex shader put a vertex to a specific position?
    If the operations were performed by a CPU, you'd be right. But they are not. Indeed, transform feedback started at GL3, not GL2. It essentially comes down to the issue of what is fixed function and what is programmable on a GPU. There are plenty of bits on a GPU that are not programmable:
    • Rasterization. One can specify to rasterize triangles, lines and point sprites. The rasterizer is a very fixed funtional bit of jazz.
    • Texturing. For texture filtering, one can specify nearest vs bilinear, with mipmaps or not and how to apply them along with anisotropic filtering [and the latter does not have formally defined spec, just a hint system].
    • Blending. Lots of hardware has dedicated bits to do blending that have very fixed-function capability


    Although the hardware is quite programmable, lots of bits of it are fixed function.

    About your idea, what you essentially want is the ability to specify a value and an offset into the buffer where to write the value. As for why GL3 hardware cannot do it, it comes down to what GL3 GPU one is talking about. My bet is that transform feedback is like a switch; under normal jazz, the values are buffered some and then sent to the rasterizer, under transform feedback the buffer writes to a buffer object and likely the little bits of hardware that do the actual writing are not very flexible. Going further, by knowing that the writes to the buffer object are continuous, that makes flushing it back to VRAM (or RAM for unified) loads easier too; it is oodles easier to implement it so that it performs better. Perfect candidate for hardware implementation: simple and by making it fixed faster.

    Going further, when I look at the evolution of the hardware capabilities: GL2 to GL3 to GL4, a great of the advances have come in more flexible memory access. GL3 through transform feed back gave ability to feedback values from GL back to buffers and both texture buffer and uniform buffer objects gave more flexible read access from buffer objects [where as before they could only be used as attribute sources]. GL4 generation hardware gave the ability for random writes to texture and buffer objects; before where and how to write was very predictable: buffer objects only could be written by transform feedback or by setting the data by the CPU and textures by setting the data by CPU or rendering to them...now full blown random access.

    As a side note, GL_ARB_shader_image_store and the buffer object one need to be used with care; poor use of them can have unpleasant effects on performance.

Tags for this Thread

Posting Permissions

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