vertex shader feedback loop


    Jun 12 2008 | 1:31 pm
    Aloha,
    I was wondering if it is theoretically possible to make some vertex displacement shader which is recursively applied? (am I saying this right?)
    e.g. : the shader gets fed the value of 0. 0. 0., and alters it to 0.1 0.1 0.1, now this value is used in that shader and spits out 0.2 0.2 0.2
    I was thinking along the lines of: named matrix > jit.gl.mesh with shader & matrixoutput > named matrix.
    But apart from jit.gl.mesh not working with matrixoutput, I wonder if it is even possible if it would. If so, there's a good reason to have matrixoutput working with jit.gl.mesh after all :)

    • Jun 12 2008 | 2:38 pm
      if you want to feedback a mesh just use a jit.matrix full of vertices, before pshing it into jit.gl.mesh. then do a normal feedback using named matrices, xfade, what ever.
      you can feedback fragment shaders, see the recpies for examples.
      also see this patch
      On Thu, Jun 12, 2008 at 4:31 PM, Brecht Debackere wrote:
      > Aloha, > > I was wondering if it is theoretically possible to make some vertex > displacement shader which is recursively applied? (am I saying this right?) > > e.g. : the shader gets fed the value of 0. 0. 0., and alters it to 0.1 0.1 > 0.1, now this value is used in that shader and spits out 0.2 0.2 0.2 > > I was thinking along the lines of: named matrix > jit.gl.mesh with shader > & matrixoutput > named matrix. > > But apart from jit.gl.mesh not working with matrixoutput, I wonder if it is > even possible if it would. If so, there's a good reason to have matrixoutput > working with jit.gl.mesh after all >
    • Jun 12 2008 | 2:58 pm
      That's indeed how I've been doing it now, but when using several jit.expr objects, with different expressions and weight, it becomes slow very quickly. That's why I was looking for a way to move what the jit.expr objects are doing from the cpu to the gpu where I think they should be.
    • Jun 12 2008 | 3:11 pm
      As far as I know(so, not further than my nose), you can't read back vertex shader results back to cpu, but in theory you should be able to process the geometry on gpu, as a float texture, using fragment shaders. In practice, this still doesen't work reliably... see:
      best, nesa
    • Jun 12 2008 | 3:17 pm
      whats the mesh size? it shouldn't be slow, and you get a lot of flexibility with jit.matrix. shaders work differently then matrices. things happen per vertex (and parallel) and they have no knowledge about other vertex, thats what makes them fast.
      if you post a patch i'd like to see were its going as i have jit.expr problems of my own.
      On Thu, Jun 12, 2008 at 5:58 PM, Brecht Debackere wrote:
      > That's indeed how I've been doing it now, but when using several jit.expr > objects, with different expressions and weight, it becomes slow very > quickly. That's why I was looking for a way to move what the jit.expr > objects are doing from the cpu to the gpu where I think they should be. > > >
    • Jun 12 2008 | 3:19 pm
      CHOIR:
      Hello nesa!
      On Thu, Jun 12, 2008 at 6:17 PM, yair reshef wrote:
      > whats the mesh size? it shouldn't be slow, and you get a lot of flexibility > with jit.matrix. > shaders work differently then matrices. things happen per vertex (and > parallel) and they have no knowledge about other vertex, thats what makes > them fast. > > if you post a patch i'd like to see were its going as i have jit.expr > problems of my own. > > > > On Thu, Jun 12, 2008 at 5:58 PM, Brecht Debackere > wrote: > >> That's indeed how I've been doing it now, but when using several jit.expr >> objects, with different expressions and weight, it becomes slow very >> quickly. That's why I was looking for a way to move what the jit.expr >> objects are doing from the cpu to the gpu where I think they should be. >> >> >> > >
    • Jun 12 2008 | 3:19 pm
      CHOIR:
      Hello nesa!
    • Jun 12 2008 | 4:16 pm
      I've been doing some tests with 100x100 matrices (it "should" be possible to have 10 times as much with a decent framerate, say at least 20, in theory). Ultimately I would like to have that amount of textured planes, but for now it's just points/lines.
      On 12 Jun 2008, at 17:17, yair reshef wrote:
      > whats the mesh size? it shouldn't be slow, and you get a lot of > flexibility with jit.matrix. > shaders work differently then matrices. things happen per vertex > (and parallel) and they have no knowledge about other vertex, thats > what makes them fast. > > if you post a patch i'd like to see were its going as i have > jit.expr problems of my own. > > > On Thu, Jun 12, 2008 at 5:58 PM, Brecht Debackere > wrote: > That's indeed how I've been doing it now, but when using several > jit.expr objects, with different expressions and weight, it becomes > slow very quickly. That's why I was looking for a way to move what > the jit.expr objects are doing from the cpu to the gpu where I > think they should be. > > >
    • Jun 12 2008 | 4:33 pm
      it seems you r talking about 2 diff things
      On Thu, Jun 12, 2008 at 7:16 PM, Brecht Debackere wrote:
      > I've been doing some tests with 100x100 matrices (it "should" be possible > to have 10 times as much with a decent framerate, say at least 20, in > theory). > Ultimately I would like to have that amount of textured planes, but for now > it's just points/lines. > > > On 12 Jun 2008, at 17:17, yair reshef wrote: > > whats the mesh size? it shouldn't be slow, and you get a lot of flexibility > with jit.matrix. > shaders work differently then matrices. things happen per vertex (and > parallel) and they have no knowledge about other vertex, thats what makes > them fast. > > if you post a patch i'd like to see were its going as i have jit.expr > problems of my own. > > > On Thu, Jun 12, 2008 at 5:58 PM, Brecht Debackere > wrote: > >> That's indeed how I've been doing it now, but when using several jit.expr >> objects, with different expressions and weight, it becomes slow very >> quickly. That's why I was looking for a way to move what the jit.expr >> objects are doing from the cpu to the gpu where I think they should be. >> >> >> > > > > > >
    • Jun 12 2008 | 5:09 pm
      Hi Brecht, I believe this is possible using Geometry shaders, which are a LOT more work to put together. For using standard Vertex/Fragment shader programs, you're not going to be able to get recursion. If you post a patch, maybe we can help you find ways to optimize your processes and move things into a vertex program where possible. Keep in mind that 100x100 is 10,000 vertex points, and you might be also encountering drawing bottlenecks.
      Let us know how you get on.
      Andrew B.
    • Jun 12 2008 | 6:40 pm
      I'll get back on it, once I get some stuff cleaned up. I know it is 10 000 vertex points, but looking at some graphics cards tests, the tiangle/primitive count of a number of tested games goes at least 70x higher. I'll see where it strands.
      > it seems you r talking about 2 diff things
      not really, it's basically the same matrix calculations, whether I use the result to draw points, or use them as positions for the planes.
      On 12 Jun 2008, at 19:09, Andrew Benson wrote:
      > > Hi Brecht, > I believe this is possible using Geometry shaders, which are a LOT > more work to put together. For using standard Vertex/Fragment > shader programs, you're not going to be able to get recursion. If > you post a patch, maybe we can help you find ways to optimize your > processes and move things into a vertex program where possible. > Keep in mind that 100x100 is 10,000 vertex points, and you might be > also encountering drawing bottlenecks. > > Let us know how you get on. > > Andrew B. > -- > Andrew B. > -- > Cycling '74 Support
    • Jun 12 2008 | 7:13 pm
      It's certainly possible to render around 100,000 points in realtime and dynamically. When you start rendering planes at this size, you start to hit the fill-rate bound. For triangle meshes, I can reliably do around 70,000 points dynamically and on workstation GPUs around 150,000. It's of course higher with less intensive shaders and more static data.
      The way to get this rate of throughput is via render-to-vertex buffer. Jitter currently does not support this although it is planned for a future release. Also, geometry shaders can do what's called transform-feedback but again Jitter does not currently support this but will probably do so in the future.
      to give you an idea of how it works with the RTVBO path, you use float textures as buffer of vertices and process like normal textures with slabs. Then, when you want to turn them into geometry, you flip a few switches on the GPU to send the float texture data into a VBO, which you can then pass to a vertex shader or draw with the fixed function pipeline.
      wes
      On Thu, Jun 12, 2008 at 11:40 AM, Brecht Debackere wrote: > I'll get back on it, once I get some stuff cleaned up. I know it is 10 000 > vertex points, but looking at some graphics cards tests, the > tiangle/primitive count of a number of tested games goes at least 70x > higher. > I'll see where it strands. > > it seems you r talking about 2 diff things > > not really, it's basically the same matrix calculations, whether I use the > result to draw points, or use them as positions for the planes. > > > On 12 Jun 2008, at 19:09, Andrew Benson wrote: > > Hi Brecht, > I believe this is possible using Geometry shaders, which are a LOT more work > to put together. For using standard Vertex/Fragment shader programs, you're > not going to be able to get recursion. If you post a patch, maybe we can > help you find ways to optimize your processes and move things into a vertex > program where possible. Keep in mind that 100x100 is 10,000 vertex points, > and you might be also encountering drawing bottlenecks. > Let us know how you get on. > Andrew B. > -- > Andrew B. > -- > Cycling '74 Support > > >