rgba2luma shader
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.
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.
>
Yeah, check out this patch, and look at performance when changing the
dims of the texture, and the resulting jit.matrix adapting size:

v a d e //
www.vade.info
abstrakt.vade.info
On Nov 22, 2006, at 9:24 AM, 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.
>>
>
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
FragColor.
Cheers,
Andrew B.
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
> 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.
-Joshua
On Nov 22, 2006, at 6:33 AM, vade wrote:
> 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.
-Joshua
> 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
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!
v a d e //
www.vade.info
abstrakt.vade.info
On Nov 22, 2006, at 1:23 PM, Joshua Kit Clayton wrote:
>> 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?
THanks
I thought that got fixed. Sorry. Here it is in text format:
v a d e //
www.vade.info
abstrakt.vade.info
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
> of this patch or repost it?
>
> THanks