yair reshef

i am not happy with the readback to matrix performance of my patch.

(fool that i am) would like to readback only one plane to jit.matrix.

thinking it will cut on the readback overhead.

gl_FragColor is a vec4- from what i undersatnd from the spec- this is set

and unchangable. only workarounds such as combining planes (grgb) or

dimscaling them as rgba2yuvu can offer better readback performance. it would

be nice to use a boolean type vector (bvec) as gl_Fragcolor or even just

aside from that, a slab with dimscale and dim dont change the the cpu stress

i am not happy with the readback to matrix performance of my patch.
(fool that i am) would like to readback only one plane to jit.matrix.
thinking it will cut on the readback overhead.
but
gl_FragColor is a vec4- from what i undersatnd from the spec- this is set
and unchangable. only workarounds such as combining planes (grgb) or
dimscaling them as rgba2yuvu can offer better readback performance. it would
be nice to use a boolean type vector (bvec) as gl_Fragcolor or even just
zeroing the unused data.
is this path leading nowhere?
aside from that, a slab with dimscale and dim dont change the the cpu stress
much even with dim on 16 16.

rgba2luma-shader

How big is the matrix you are reading back too? I think the matrix 

size also has some impact on performance. Also, what readback 

I for one have found rendering to a texture or using @capture, and 

then jit.gl.texture to -> jit.gl.matrix to be faster than rendering 

direct to a matrix, or using any of the other mechanisms found in the 

On Nov 22, 2006, at 8:29 AM, yair reshef wrote:

> i am not happy with the readback to matrix performance of my patch.

> (fool that i am) would like to readback only one plane to 

> jit.matrix. thinking it will cut on the readback overhead.

> gl_FragColor is a vec4- from what i undersatnd from the spec- this 

> is set and unchangable. only workarounds such as combining planes 

> (grgb) or dimscaling them as rgba2yuvu can offer better readback 

> performance. it would be nice to use a boolean type vector (bvec) 

> as gl_Fragcolor or even just zeroing the unused data.

> aside from that, a slab with dimscale and dim dont change the the 

> cpu stress much even with dim on 16 16.

How big is the matrix you are reading back too? I think the matrix  
size also has some impact on performance. Also, what readback  
mechanism have you decided to use?

I for one have found rendering to a texture or using @capture, and  
then jit.gl.texture to -> jit.gl.matrix to be faster than rendering  
direct to a matrix, or using any of the other mechanisms found in the  
examples folder.

> i am not happy with the readback to matrix performance of my patch.
> (fool that i am) would like to readback only one plane to  
> jit.matrix. thinking it will cut on the readback overhead.
> but
> gl_FragColor is a vec4- from what i undersatnd from the spec- this  
> is set and unchangable. only workarounds such as combining planes  
> (grgb) or dimscaling them as rgba2yuvu can offer better readback  
> performance. it would be nice to use a boolean type vector (bvec)  
> as gl_Fragcolor or even just zeroing the unused data.
> is this path leading nowhere?
> aside from that, a slab with dimscale and dim dont change the the  
> cpu stress much even with dim on 16 16.
>


Yeah, check out this patch, and look at performance when changing the 

dims of the texture, and the resulting jit.matrix adapting size:

> How big is the matrix you are reading back too? I think the matrix 

> size also has some impact on performance. Also, what readback 

> I for one have found rendering to a texture or using @capture, and 

> then jit.gl.texture to -> jit.gl.matrix to be faster than rendering 

> direct to a matrix, or using any of the other mechanisms found in 

> On Nov 22, 2006, at 8:29 AM, yair reshef wrote:

>> i am not happy with the readback to matrix performance of my patch.

>> (fool that i am) would like to readback only one plane to 

>> jit.matrix. thinking it will cut on the readback overhead.

>> gl_FragColor is a vec4- from what i undersatnd from the spec- this 

>> is set and unchangable. only workarounds such as combining planes 

>> (grgb) or dimscaling them as rgba2yuvu can offer better readback 

>> performance. it would be nice to use a boolean type vector (bvec) 

>> as gl_Fragcolor or even just zeroing the unused data.

>> aside from that, a slab with dimscale and dim dont change the the 

>> cpu stress much even with dim on 16 16.

Yeah, check out this patch, and look at performance when changing the  
dims of the texture, and the resulting jit.matrix adapting size:

> How big is the matrix you are reading back too? I think the matrix  
> size also has some impact on performance. Also, what readback  
> mechanism have you decided to use?
>
> I for one have found rendering to a texture or using @capture, and  
> then jit.gl.texture to -> jit.gl.matrix to be faster than rendering  
> direct to a matrix, or using any of the other mechanisms found in  
> the examples folder.
>
>
> v a d e //
>
> www.vade.info
> abstrakt.vade.info
>
>
> On Nov 22, 2006, at 8:29 AM, yair reshef wrote:
>
>> i am not happy with the readback to matrix performance of my patch.
>> (fool that i am) would like to readback only one plane to  
>> jit.matrix. thinking it will cut on the readback overhead.
>> but
>> gl_FragColor is a vec4- from what i undersatnd from the spec- this  
>> is set and unchangable. only workarounds such as combining planes  
>> (grgb) or dimscaling them as rgba2yuvu can offer better readback  
>> performance. it would be nice to use a boolean type vector (bvec)  
>> as gl_Fragcolor or even just zeroing the unused data.
>> is this path leading nowhere?
>> aside from that, a slab with dimscale and dim dont change the the  
>> cpu stress much even with dim on 16 16.
>>
>


i capture a sketch with a [drawobject foo 0] message > texture > slab with [

the texture is connected also to a videoplane for further gl processing

the sketch method was recommended by wes before and its very intuitive and

i process at 640 480 but need half as much for cv.jit

depthbuffer 2 , sync 0 give me 10% better results.

> How big is the matrix you are reading back too? I think the matrix size

> also has some impact on performance. Also, what readback mechanism have you

> I for one have found rendering to a texture or using @capture, and then

> jit.gl.texture to -> jit.gl.matrix to be faster than rendering direct to a

> matrix, or using any of the other mechanisms found in the examples folder.

> (fool that i am) would like to readback only one plane to jit.matrix.

> thinking it will cut on the readback overhead.

> gl_FragColor is a vec4- from what i undersatnd from the spec- this is set

> and unchangable. only workarounds such as combining planes (grgb) or

> dimscaling them as rgba2yuvu can offer better readback performance. it would

> be nice to use a boolean type vector (bvec) as gl_Fragcolor or even just

> aside from that, a slab with dimscale and dim dont change the the cpu

i capture a sketch with a [drawobject foo 0] message > texture > slab with [
cc.rgba2grgb @dimscale 0.5 0.5]
the texture is connected also to a videoplane for further gl processing
the sketch method was recommended by wes before and its very intuitive and
give good results.
i process at 640 480 but need half as much for cv.jit
depthbuffer 2 , sync 0 give me 10% better results.

On 11/22/06, vade  wrote:
>
> How big is the matrix you are reading back too? I think the matrix size
> also has some impact on performance. Also, what readback mechanism have you
> decided to use?
> I for one have found rendering to a texture or using @capture, and then
> jit.gl.texture to -> jit.gl.matrix to be faster than rendering direct to a
> matrix, or using any of the other mechanisms found in the examples folder.
> *
> *
> *
> *
> *v a d e //*
> *
> *
> *www.vade.info*
> *abstrakt.vade.info*
>
>
> On Nov 22, 2006, at 8:29 AM, yair reshef wrote:
>
> i am not happy with the readback to matrix performance of my patch.
> (fool that i am) would like to readback only one plane to jit.matrix.
> thinking it will cut on the readback overhead.
> but
> gl_FragColor is a vec4- from what i undersatnd from the spec- this is set
> and unchangable. only workarounds such as combining planes (grgb) or
> dimscaling them as rgba2yuvu can offer better readback performance. it would
> be nice to use a boolean type vector (bvec) as gl_Fragcolor or even just
> zeroing the unused data.
> is this path leading nowhere?
> aside from that, a slab with dimscale and dim dont change the the cpu
> stress much even with dim on 16 16.
>
>
>
>
>
>
>

An rgba2luma shader could be made by extracting the luminance 

calculations from co.lumakey.jxs or and then assigning that value to the 

An rgba2luma shader could be made by extracting the luminance 
calculations from co.lumakey.jxs or and then assigning that value to the 
FragColor.

On Nov 22, 2006, at 8:38 AM, Andrew Benson wrote:

> An rgba2luma shader could be made by extracting the luminance 

> calculations from co.lumakey.jxs or and then assigning that value 

Sure, but it still writes a vec4 to the color buffer, which is the 

What you could conceivably do is interleave your luminance data into 

a vec4 (@dimscale 0.25 1.) in a similar fashion to the uyvy or grgb 

code, and then once on the CPU, use [jit.coerce 1 char] to unfold the 

> An rgba2luma shader could be made by extracting the luminance  
> calculations from co.lumakey.jxs or and then assigning that value  
> to the FragColor.

Sure, but it still writes a vec4 to the color buffer, which is the  
only means of transfer provided.

What you could conceivably do is interleave your luminance data into  
a vec4 (@dimscale 0.25 1.) in a similar fashion to the uyvy or grgb  
code, and then once on the CPU, use [jit.coerce 1 char] to unfold the  
data.

> Yeah, check out this patch, and look at performance when changing 

> the dims of the texture, and the resulting jit.matrix adapting size:

This is an excellent example. One additional thing worth noting in 

vade's patch is that to see the improved performance (above the fps 

of your monitor refresh), you'll need to disable @sync for the 

> Yeah, check out this patch, and look at performance when changing  
> the dims of the texture, and the resulting jit.matrix adapting size:
>
>

This is an excellent example. One additional thing worth noting in  
vade's patch is that to see the improved performance (above the fps  
of your monitor refresh), you'll need to disable @sync for the  
jit.windows.

> On Nov 22, 2006, at 6:33 AM, vade wrote:

Sorry for the extra noise, but I also thought I'd mention another 

thing. I noticed you had @antialias 1 in jit.gl.slab in your patch, 

which won't give any different results in this instance. @antialias 

is *only* for line antialiasing, not polygon antialiasing or FSAA.

I think you might benefit from rendering to a quadruple size texture 

(2xwidth,2xheight), and sending "read cf.convolve.jxs, dimscale 0.5 

0.5" to jit.gl.slab here instead. This will downscale with nice 

multisampled antialiasing. You can change how much multi-sampling is 

affecting each pixel with the param width and param height controls- 

e.g. a width and height of 0.5 instead of the default 1 looks pretty 

This gives you HW multisampling when rendering to texture. It's also 

a useful trick if you need a multi-sampled render to texture on the 

card (i.e. not transferring back to CPU).

For even better looking up/downsampling in this fashion, you can also 

use two instances of jit.gl.slab with separable filters such as the 

cf.gaussian.2p.jxs example. Gaussians are a little blurry, but this 

shader could be modified to have a sinc or Mitchell filter instead of 

a gaussian filter. For more info on the subject of sampling and 

separable filters, there's tons of information online.

I might personally recommend the ""Sampling and Reconstruction" 

chapter from Matt Pharr's excellent book, "Physically Based Ray 

Tracing", though it requires you understand a little bit of C++. 

http://graphics.stanford.edu/~mmp/chapters/pbrt_chapter7.pdf

> On Nov 22, 2006, at 6:33 AM, vade wrote:
>
>> [render to matrix solution]

Sorry for the extra noise, but I also thought I'd mention another  
thing. I noticed you had @antialias 1 in jit.gl.slab in your patch,  
which won't give any different results in this instance. @antialias  
is *only* for line antialiasing, not polygon antialiasing or FSAA.

I think you might benefit from rendering to a quadruple size texture 
(2xwidth,2xheight), and sending "read cf.convolve.jxs, dimscale 0.5  
0.5" to jit.gl.slab here instead. This will downscale with nice  
multisampled antialiasing. You can change how much multi-sampling is  
affecting each pixel with the param width and param height controls-  
e.g. a width and height of 0.5 instead of the default 1 looks pretty  
nice in this instance.

This gives you HW multisampling when rendering to texture. It's also  
a useful trick if you need a multi-sampled render to texture on the  
card (i.e. not transferring back to CPU).

For even better looking up/downsampling in this fashion, you can also  
use two instances of jit.gl.slab with separable filters such as the  
cf.gaussian.2p.jxs example. Gaussians are a little blurry, but this  
shader could be modified to have a sinc or Mitchell filter instead of  
a gaussian filter. For more info on the subject of sampling and  
separable filters, there's tons of information online.

I might personally recommend the ""Sampling and Reconstruction"  
chapter from Matt Pharr's excellent book, "Physically Based Ray  
Tracing", though it requires you understand a little bit of C++.  
http://pbrt.org/

Direct link to chapter:
http://graphics.stanford.edu/~mmp/chapters/pbrt_chapter7.pdf

Thanks ! Ill check into that. Glad you like the patch. Feel free to 

include it in the examples (or a modified version) if you think it 

On Nov 22, 2006, at 1:23 PM, Joshua Kit Clayton wrote:

>> On Nov 22, 2006, at 6:33 AM, vade wrote:

> Sorry for the extra noise, but I also thought I'd mention another 

> thing. I noticed you had @antialias 1 in jit.gl.slab in your patch, 

> which won't give any different results in this instance. @antialias 

> is *only* for line antialiasing, not polygon antialiasing or FSAA.

> I think you might benefit from rendering to a quadruple size texture 

> (2xwidth,2xheight), and sending "read cf.convolve.jxs, dimscale 0.5 

> 0.5" to jit.gl.slab here instead. This will downscale with nice 

> multisampled antialiasing. You can change how much multi-sampling 

> is affecting each pixel with the param width and param height 

> controls- e.g. a width and height of 0.5 instead of the default 1 

> This gives you HW multisampling when rendering to texture. It's 

> also a useful trick if you need a multi-sampled render to texture 

> on the card (i.e. not transferring back to CPU).

> For even better looking up/downsampling in this fashion, you can 

> also use two instances of jit.gl.slab with separable filters such 

> as the cf.gaussian.2p.jxs example. Gaussians are a little blurry, 

> but this shader could be modified to have a sinc or Mitchell filter 

> instead of a gaussian filter. For more info on the subject of 

> sampling and separable filters, there's tons of information online.

> I might personally recommend the ""Sampling and Reconstruction" 

> chapter from Matt Pharr's excellent book, "Physically Based Ray 

> Tracing", though it requires you understand a little bit of C++. 

Thanks ! Ill check into that. Glad you like the patch. Feel free to  
include it in the examples (or a modified version) if you think it  
would be helpful!

>> On Nov 22, 2006, at 6:33 AM, vade wrote:
>>
>>> [render to matrix solution]
>
> Sorry for the extra noise, but I also thought I'd mention another  
> thing. I noticed you had @antialias 1 in jit.gl.slab in your patch,  
> which won't give any different results in this instance. @antialias  
> is *only* for line antialiasing, not polygon antialiasing or FSAA.
>
> I think you might benefit from rendering to a quadruple size texture 
> (2xwidth,2xheight), and sending "read cf.convolve.jxs, dimscale 0.5  
> 0.5" to jit.gl.slab here instead. This will downscale with nice  
> multisampled antialiasing. You can change how much multi-sampling  
> is affecting each pixel with the param width and param height  
> controls- e.g. a width and height of 0.5 instead of the default 1  
> looks pretty nice in this instance.
>
> This gives you HW multisampling when rendering to texture. It's  
> also a useful trick if you need a multi-sampled render to texture  
> on the card (i.e. not transferring back to CPU).
>
> For even better looking up/downsampling in this fashion, you can  
> also use two instances of jit.gl.slab with separable filters such  
> as the cf.gaussian.2p.jxs example. Gaussians are a little blurry,  
> but this shader could be modified to have a sinc or Mitchell filter  
> instead of a gaussian filter. For more info on the subject of  
> sampling and separable filters, there's tons of information online.
>
> I might personally recommend the ""Sampling and Reconstruction"  
> chapter from Matt Pharr's excellent book, "Physically Based Ray  
> Tracing", though it requires you understand a little bit of C++.  
> http://pbrt.org/
>
> Direct link to chapter:
> http://graphics.stanford.edu/~mmp/chapters/pbrt_chapter7.pdf
>
> -Joshua


I couldn't see the attachment. Finally resubscribed via the mailing list so this doesn't happen anymore. Its a shame, I like the forums better, but so much gets lost. Could someone send me a copy of this patch or repost it?

I couldn't see the attachment. Finally resubscribed via the mailing list so this doesn't happen anymore.  Its a shame, I like the forums better, but so much gets lost.  Could someone send me a copy of this patch or repost it?

I thought that got fixed. Sorry. Here it is in text format:

On Nov 22, 2006, at 2:15 PM, Christopher Overstreet wrote:

> I couldn't see the attachment. Finally resubscribed via the mailing 

> list so this doesn't happen anymore. Its a shame, I like the 

> forums better, but so much gets lost. Could someone send me a copy 

>
> I couldn't see the attachment. Finally resubscribed via the mailing  
> list so this doesn't happen anymore.  Its a shame, I like the  
> forums better, but so much gets lost.  Could someone send me a copy  
> of this patch or repost it?
>
> THanks
