Brecht

I was wondering if it is theoretically possible to make some vertex 

displacement shader which is recursively applied? (am I saying this 

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 

I was thinking along the lines of: named matrix > jit.gl.mesh with 

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 :)

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 :)


vertex-shader-feedback-loop

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

you can feedback fragment shaders, see the recpies for examples.

On Thu, Jun 12, 2008 at 4:31 PM, Brecht Debackere 

> 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

> 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

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.

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
>

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 

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.


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:

https://cycling74.com/forums/index.php?t=msg&goto=137498&rid=0&srch=gl+invalid+operation#msg_137498

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:

whats the mesh size? it shouldn't be slow, and you get a lot of flexibility

shaders work differently then matrices. things happen per vertex (and

parallel) and they have no knowledge about other vertex, thats what makes

if you post a patch i'd like to see were its going as i have jit.expr

On Thu, Jun 12, 2008 at 5:58 PM, Brecht Debackere 

> 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.

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.
>
>
>

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

> shaders work differently then matrices. things happen per vertex (and

> parallel) and they have no knowledge about other vertex, thats what makes

> if you post a patch i'd like to see were its going as i have jit.expr

> On Thu, Jun 12, 2008 at 5:58 PM, Brecht Debackere 

>> 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.

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.
>>
>>
>>
>
>

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 

Ultimately I would like to have that amount of textured planes, but 

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 

> shaders work differently then matrices. things happen per vertex 

> (and parallel) and they have no knowledge about other vertex, thats 

> if you post a patch i'd like to see were its going as i have 

> 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 

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.

> 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.
>
>
>


it seems you r talking about 2 diff things

On Thu, Jun 12, 2008 at 7:16 PM, Brecht Debackere 

> 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

> Ultimately I would like to have that amount of textured planes, but for now

> On 12 Jun 2008, at 17:17, yair reshef wrote:

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.
>>
>>
>>
>
>
>
>
>
>

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.

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.

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 

> 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:

> 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 

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.

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.

>
> 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


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

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

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

On Thu, Jun 12, 2008 at 11:40 AM, Brecht Debackere

> 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

> 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:

> 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.

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.

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
>
>
>


vertex shader feedback loop