opengl voodo

Nov 21, 2006 at 5:49am

opengl voodo

hi, i have an op image processing chain i used for background removal. i
want to port it to the gpu side
i traced most of the way, but am having problems with the op.gt.jsx shader
(took me awhile to understand gt stands for greater a.k.a >).
this patch starts with a uyvy source> converted to argb> difference key> op
greater via a captured videoplane.

i can get this chain to work only if i twiddle with the rtt fbo , ideally i
could have applied a shader and a colormode change directly to a slab but
failed to do so.
so had to capture ,change colormode and apply a texture and shader to a
gridshape.

1. couldn’t get a texture object to accept a shader.
2. couldn’t get a slab to switch colormode to lumalpha (is lumalpha the
rgb2luma of the gl world?)
4. is there a recommended limit for captured textures? can i make a
“capture this gridshape plane” abstraction and worry not?
any tips welcomed.

max v2;
#N vpatcher 32 463 806 926;
#P origin 22 -31;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P comment 592 332 119 9109513 with errors;
#P comment 597 98 119 9109513 3b. play with inscale value;
#P comment 594 79 100 9109513 3. click FBO thn RTT;
#P comment 594 60 100 9109513 2. read diff frame;
#P window linecount 2;
#P message 488 247 91 9109513 ; jitter glreadback fbo;
#P window linecount 1;
#P newex 346 133 93 9109513 loadbang;
#P window linecount 2;
#P message 488 213 86 9109513 ; jitter glreadback rtt;
#P window linecount 1;
#P newex 93 57 53 9109513 t b b b b;
#P message 219 299 36 9109513 shader;
#P message 170 299 47 9109513 shader gt;
#P window linecount 2;
#P newex 189 189 212 9109513 jit.gl.videoplane foo @blend_enable
1@automatic0 @capture goo;
#B color 5;
#P newex 126 260 148 9109513 jit.gl.texture foo @name goo @colormode
lumalpha;
#B color 5;
#P newex 380 345 148 9109513 jit.gl.shader foo @file op.gt.jxs @name gt;
#B color 5;
#P window linecount 1;
#N vpatcher 345 261 1110 796;
#P window setfont “Sans Serif” 9.;
#P user jit.fpsgui 611 362 60 9109513 4;
#P user jit.pwindow 599 391 82 62 0 1 0 0 1 0;
#P window linecount 0;
#P newex 600 340 70 9109513 jit.matrix;
#B color 5;
#P outlet 50 505 15 0;
#P window linecount 3;
#P comment 404 367 117 9109513 open subpatcher to check out a few other
variants of this shader;
#P window linecount 1;
#N vpatcher 20 74 603 294;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P message 326 119 126 9109513 file cc.uyvy2rgba.lite.jxs;
#P window linecount 3;
#P comment 325 77 213 9109513 for an even more lightweight conversion , we
provide another shader which has no color correction parameters or
chromasmoothing;
#P outlet 53 169 15 0;
#P window linecount 1;
#P message 53 119 127 9109513 file cc.uyvy2rgba.exp.jxs;
#P flonum 191 96 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 191 119 96 9109513 param exponent $1;
#P window linecount 4;
#P comment 52 35 259 9109513 exponent is useful for getting gamma corrected
like results with simple math in RGB colorspace , but can be more
computationally expensive , so we provide another shader , with this extra
parameter and calculation;
#P fasten 6 0 4 0 331 159 58 159;
#P fasten 1 0 4 0 196 144 58 144;
#P connect 3 0 4 0;
#P connect 2 0 1 0;
#P pop;
#P newobj 405 407 64 9109513 p variations;
#P window linecount 2;
#P comment 433 234 96 9109513 enable/disable chroma smoothing;
#P window linecount 1;
#P comment 121 330 206 9109513 scale and bias controls in RGB colorspace;
#P window linecount 2;
#P comment 212 233 203 9109513 brightness , contrast , saturation controls
applied in the shader in the YUV colorspace;
#P button 67 193 15 0;
#P toggle 433 261 15 0;
#P window linecount 1;
#P message 433 283 121 9109513 param chromasmooth $1;
#P flonum 91 261 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 207 261 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 320 261 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 320 284 102 9109513 param saturation $1;
#P message 207 284 94 9109513 param contrast $1;
#P message 91 284 103 9109513 param brightness $1;
#P flonum 298 354 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 336 381 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 298 381 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 258 381 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 210 407 125 9109513 pak param bias 0. 0. 0. 0.;
#P flonum 154 354 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 192 381 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 154 381 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 114 381 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 66 407 130 9109513 pak param scale 1. 1. 1. 1.;
#P newex 67 211 145 9109513 mxj quickie cc.uyvy2rgba.jxs;
#P user gswitch2 50 113 39 32 0 0;
#P newex 561 170 169 9109513 jit.gl.texture foo @colormode uyvy;
#P message 67 233 108 9109513 file cc.uyvy2rgba.jxs;
#N vpatcher 45 100 645 500;
#P outlet 160 65 15 0;
#P inlet 161 43 15 0;
#P connect 0 0 1 0;
#P pop;
#P newobj 50 483 32 9109513 p thru;
#P newex 50 442 253 9109513 jit.gl.slab foo @file cc.uyvy2rgba.jxs @dimscale
2. 1.;
#P window linecount 5;
#P comment 354 50 365 9109513 note that jit.gl.slab’s dimscale attribute is
set to handle the uyvy macro-pixel to full chroma rgba dimensions. we dont
use uyvy color mode for either jit.gl.texture or jit.gl.slab as we send to
the graphics card masqueraded as rgba data and perform the color conversion
on the card in a custom shader. we also have a variety of useful controls
for color processing in the same shader.;
#P window linecount 1;
#P comment 86 195 314 9109513 click to edit shader (probably want to make a
backup copy first);
#P inlet 79 93 15 0;
#P fasten 31 0 3 0 410 438 55 438;
#P fasten 5 0 3 0 72 261 55 261;
#P fasten 9 0 3 0 71 431 55 431;
#P fasten 19 0 3 0 96 309 55 309;
#P fasten 20 0 3 0 212 309 55 309;
#P fasten 21 0 3 0 325 309 55 309;
#P fasten 14 0 3 0 215 431 55 431;
#P fasten 25 0 3 0 438 309 55 309;
#P connect 7 0 3 0;
#P fasten 6 0 4 0 566 475 55 475;
#P connect 3 0 4 0;
#P connect 4 0 33 0;
#P connect 27 0 8 0;
#P connect 8 0 5 0;
#P connect 0 0 7 1;
#P connect 24 0 19 0;
#P connect 13 0 10 0;
#P connect 10 0 9 2;
#P connect 11 0 9 3;
#P connect 13 0 11 0;
#P connect 12 0 9 4;
#P connect 13 0 12 0;
#P connect 23 0 20 0;
#P connect 15 0 14 2;
#P connect 18 0 15 0;
#P connect 16 0 14 3;
#P connect 18 0 16 0;
#P connect 17 0 14 4;
#P connect 22 0 21 0;
#P connect 18 0 17 0;
#P connect 26 0 25 0;
#P fasten 7 1 6 0 84 156 566 156;
#P connect 34 0 35 0;
#P connect 34 0 36 0;
#P pop;
#P newobj 189 140 38 9109513 p yuvu;
#P window linecount 2;
#P message 346 155 156 9109513 dispose , read op.absdiff.jxs , param
inscale 1. , param outscale 3.5;
#P window linecount 1;
#P message 189 46 87 9109513 read dvducks.mov;
#B color 6;
#P newex 189 77 262 9109513 jit.qt.movie 320 240 @adapt 1 @colormode uyvy
@unique 1;
#P newex 189 166 148 9109513 jit.gl.slab foo @file op.absdiff.jxs;
#B color 5;
#P message 294 46 125 9109513 importmovie chilis.jpg , bang;
#B color 6;
#P newex 294 120 44 9109513 jit.matrix;
#P window linecount 2;
#P newex 110 323 172 9109513 jit.gl.videoplane foo @scale 1.
0.8@blend_enable 1 @shader gt;
#P toggle 179 370 15 0;
#P window linecount 1;
#P message 179 388 45 9109513 sync $1;
#P toggle 106 370 15 0;
#P newex 67 369 35 9109513 sel 27;
#P message 106 388 68 9109513 fullscreen $1;
#P newex 24 412 145 9109513 jit.window foo @depthbuffer 1;
#P newex 22 369 40 9109513 key;
#P user jit.fpsgui 23 148 60 9109513 0;
#P number 46 21 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P toggle 1 21 15 0;
#P newex 1 47 55 9109513 qmetro 20;
#P newex 1 97 55 9109513 t b b erase;
#P newex 1 181 80 9109513 jit.gl.render foo;
#P flonum 380 302 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 380 323 85 9109513 param inscale $1;
#P window setfont “Sans Serif” 20.;
#P window linecount 6;
#P comment 591 178 100 9109524 only after switching from fbo to rtt i get
op.gt to work.;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P comment 594 45 100 9109513 1. read movie;
#P user panel 140 228 290 16;
#X brgb 191 191 191;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P connect 8 0 7 0;
#P connect 7 0 6 0;
#P connect 6 0 5 0;
#P connect 6 2 5 0;
#P connect 6 1 10 0;
#P fasten 16 0 12 0 184 407 29 407;
#P fasten 13 0 12 0 111 407 29 407;
#P connect 9 0 7 1;
#P fasten 11 0 14 0 27 388 64 388 64 367 72 367;
#P fasten 6 1 31 0 28 136 81 136 81 53 98 53;
#P fasten 14 0 15 0 72 387 103 387 103 367 111 367;
#P connect 15 0 13 0;
#P connect 31 0 18 0;
#P fasten 29 0 18 0 175 319 115 319;
#P connect 27 0 18 0;
#P fasten 30 0 18 0 224 319 115 319;
#P connect 31 1 27 0;
#P connect 17 0 16 0;
#P fasten 23 0 22 0 194 71 194 71;
#P connect 31 3 22 0;
#P connect 22 0 25 0;
#P connect 25 0 21 0;
#P connect 31 2 28 0;
#P connect 21 0 28 0;
#P fasten 20 0 19 0 299 115 299 115;
#P fasten 24 0 21 1 351 162 332 162;
#P fasten 19 0 21 1 299 157 332 157;
#P connect 33 0 24 0;
#P connect 4 0 3 0;
#P connect 3 0 26 0;
#P pop;

#28798
Nov 21, 2006 at 6:07am

jit.gl.texture wont accept jit.sl.shader. A shader needs some OB3D
style geometry (actual verts to bind to, afaik (?) ), you’d want to
use a slab instead, to do stream processing on textures, which is
iirc a texture bound to a videoplane with transform reset 2 and
@capture set, outputting a texture.

also, iirc, lumalpha is for a ‘single plane’ style texture, imagine
just the alpha channel. Im not 100% positive about it, as I dont
really work with it, but I believe that is correct.

I havent looked at your patch, but perhaps thats enough to help out.

v a d e //

http://www.vade.info
abstrakt.vade.info

On Nov 21, 2006, at 12:49 AM, yair reshef wrote:

> hi, i have an op image processing chain i used for background
> removal. i want to port it to the gpu side
> i traced most of the way, but am having problems with the op.gt.jsx
> shader (took me awhile to understand gt stands for greater a.k.a >).
> this patch starts with a uyvy source> converted to argb> difference
> key> op greater via a captured videoplane.
>
> i can get this chain to work only if i twiddle with the rtt fbo ,
> ideally i could have applied a shader and a colormode change
> directly to a slab but failed to do so.
> so had to capture ,change colormode and apply a texture and shader
> to a gridshape.
>
> 1. couldn’t get a texture object to accept a shader.
> 2. couldn’t get a slab to switch colormode to lumalpha (is lumalpha
> the rgb2luma of the gl world?)
> 4. is there a recommended limit for captured textures? can i make
> a “capture this gridshape plane” abstraction and worry not?
> any tips welcomed.
>
> max v2;
> #N vpatcher 32 463 806 926;
> #P origin 22 -31;
> #P window setfont “Sans Serif” 9.;
> #P window linecount 1;
> #P comment 592 332 119 9109513 with errors;
> #P comment 597 98 119 9109513 3b. play with inscale value;
> #P comment 594 79 100 9109513 3. click FBO thn RTT;
> #P comment 594 60 100 9109513 2. read diff frame;
> #P window linecount 2;
> #P message 488 247 91 9109513 ; jitter glreadback fbo;
> #P window linecount 1;
> #P newex 346 133 93 9109513 loadbang;
> #P window linecount 2;
> #P message 488 213 86 9109513 ; jitter glreadback rtt;
> #P window linecount 1;
> #P newex 93 57 53 9109513 t b b b b;
> #P message 219 299 36 9109513 shader;
> #P message 170 299 47 9109513 shader gt;
> #P window linecount 2;
> #P newex 189 189 212 9109513 jit.gl.videoplane foo @blend_enable
> 1@automatic 0 @capture goo;
> #B color 5;
> #P newex 126 260 148 9109513 jit.gl.texture foo @name goo
> @colormode lumalpha;
> #B color 5;
> #P newex 380 345 148 9109513 jit.gl.shader foo @file op.gt.jxs
> @name gt;
> #B color 5;
> #P window linecount 1;
> #N vpatcher 345 261 1110 796;
> #P window setfont “Sans Serif” 9.;
> #P user jit.fpsgui 611 362 60 9109513 4;
> #P user jit.pwindow 599 391 82 62 0 1 0 0 1 0;
> #P window linecount 0;
> #P newex 600 340 70 9109513 jit.matrix;
> #B color 5;
> #P outlet 50 505 15 0;
> #P window linecount 3;
> #P comment 404 367 117 9109513 open subpatcher to check out a few
> other variants of this shader;
> #P window linecount 1;
> #N vpatcher 20 74 603 294;
> #P window setfont “Sans Serif” 9.;
> #P window linecount 1;
> #P message 326 119 126 9109513 file cc.uyvy2rgba.lite.jxs;
> #P window linecount 3;
> #P comment 325 77 213 9109513 for an even more lightweight
> conversion , we provide another shader which has no color
> correction parameters or chromasmoothing;
> #P outlet 53 169 15 0;
> #P window linecount 1;
> #P message 53 119 127 9109513 file cc.uyvy2rgba.exp.jxs;
> #P flonum 191 96 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P message 191 119 96 9109513 param exponent $1;
> #P window linecount 4;
> #P comment 52 35 259 9109513 exponent is useful for getting gamma
> corrected like results with simple math in RGB colorspace , but
> can be more computationally expensive , so we provide another
> shader , with this extra parameter and calculation;
> #P fasten 6 0 4 0 331 159 58 159;
> #P fasten 1 0 4 0 196 144 58 144;
> #P connect 3 0 4 0;
> #P connect 2 0 1 0;
> #P pop;
> #P newobj 405 407 64 9109513 p variations;
> #P window linecount 2;
> #P comment 433 234 96 9109513 enable/disable chroma smoothing;
> #P window linecount 1;
> #P comment 121 330 206 9109513 scale and bias controls in RGB
> colorspace;
> #P window linecount 2;
> #P comment 212 233 203 9109513 brightness , contrast , saturation
> controls applied in the shader in the YUV colorspace;
> #P button 67 193 15 0;
> #P toggle 433 261 15 0;
> #P window linecount 1;
> #P message 433 283 121 9109513 param chromasmooth $1;
> #P flonum 91 261 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P flonum 207 261 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P flonum 320 261 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P message 320 284 102 9109513 param saturation $1;
> #P message 207 284 94 9109513 param contrast $1;
> #P message 91 284 103 9109513 param brightness $1;
> #P flonum 298 354 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P flonum 336 381 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P flonum 298 381 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P flonum 258 381 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 210 407 125 9109513 pak param bias 0. 0. 0. 0.;
> #P flonum 154 354 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P flonum 192 381 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P flonum 154 381 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P flonum 114 381 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 66 407 130 9109513 pak param scale 1. 1. 1. 1.;
> #P newex 67 211 145 9109513 mxj quickie cc.uyvy2rgba.jxs;
> #P user gswitch2 50 113 39 32 0 0;
> #P newex 561 170 169 9109513 jit.gl.texture foo @colormode uyvy;
> #P message 67 233 108 9109513 file cc.uyvy2rgba.jxs;
> #N vpatcher 45 100 645 500;
> #P outlet 160 65 15 0;
> #P inlet 161 43 15 0;
> #P connect 0 0 1 0;
> #P pop;
> #P newobj 50 483 32 9109513 p thru;
> #P newex 50 442 253 9109513 jit.gl.slab foo @file cc.uyvy2rgba.jxs
> @dimscale 2. 1.;
> #P window linecount 5;
> #P comment 354 50 365 9109513 note that jit.gl.slab’s dimscale
> attribute is set to handle the uyvy macro-pixel to full chroma rgba
> dimensions. we dont use uyvy color mode for either jit.gl.texture
> or jit.gl.slab as we send to the graphics card masqueraded as rgba
> data and perform the color conversion on the card in a custom
> shader. we also have a variety of useful controls for color
> processing in the same shader.;
> #P window linecount 1;
> #P comment 86 195 314 9109513 click to edit shader (probably want
> to make a backup copy first);
> #P inlet 79 93 15 0;
> #P fasten 31 0 3 0 410 438 55 438;
> #P fasten 5 0 3 0 72 261 55 261;
> #P fasten 9 0 3 0 71 431 55 431;
> #P fasten 19 0 3 0 96 309 55 309;
> #P fasten 20 0 3 0 212 309 55 309;
> #P fasten 21 0 3 0 325 309 55 309;
> #P fasten 14 0 3 0 215 431 55 431;
> #P fasten 25 0 3 0 438 309 55 309;
> #P connect 7 0 3 0;
> #P fasten 6 0 4 0 566 475 55 475;
> #P connect 3 0 4 0;
> #P connect 4 0 33 0;
> #P connect 27 0 8 0;
> #P connect 8 0 5 0;
> #P connect 0 0 7 1;
> #P connect 24 0 19 0;
> #P connect 13 0 10 0;
> #P connect 10 0 9 2;
> #P connect 11 0 9 3;
> #P connect 13 0 11 0;
> #P connect 12 0 9 4;
> #P connect 13 0 12 0;
> #P connect 23 0 20 0;
> #P connect 15 0 14 2;
> #P connect 18 0 15 0;
> #P connect 16 0 14 3;
> #P connect 18 0 16 0;
> #P connect 17 0 14 4;
> #P connect 22 0 21 0;
> #P connect 18 0 17 0;
> #P connect 26 0 25 0;
> #P fasten 7 1 6 0 84 156 566 156;
> #P connect 34 0 35 0;
> #P connect 34 0 36 0;
> #P pop;
> #P newobj 189 140 38 9109513 p yuvu;
> #P window linecount 2;
> #P message 346 155 156 9109513 dispose , read op.absdiff.jxs ,
> param inscale 1. , param outscale 3.5;
> #P window linecount 1;
> #P message 189 46 87 9109513 read dvducks.mov;
> #B color 6;
> #P newex 189 77 262 9109513 jit.qt.movie 320 240 @adapt 1
> @colormode uyvy @unique 1;
> #P newex 189 166 148 9109513 jit.gl.slab foo @file op.absdiff.jxs;
> #B color 5;
> #P message 294 46 125 9109513 importmovie chilis.jpg , bang;
> #B color 6;
> #P newex 294 120 44 9109513 jit.matrix;
> #P window linecount 2;
> #P newex 110 323 172 9109513 jit.gl.videoplane foo @scale 1. 0.8
> @blend_enable 1 @shader gt;
> #P toggle 179 370 15 0;
> #P window linecount 1;
> #P message 179 388 45 9109513 sync $1;
> #P toggle 106 370 15 0;
> #P newex 67 369 35 9109513 sel 27;
> #P message 106 388 68 9109513 fullscreen $1;
> #P newex 24 412 145 9109513 jit.window foo @depthbuffer 1;
> #P newex 22 369 40 9109513 key;
> #P user jit.fpsgui 23 148 60 9109513 0;
> #P number 46 21 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P toggle 1 21 15 0;
> #P newex 1 47 55 9109513 qmetro 20;
> #P newex 1 97 55 9109513 t b b erase;
> #P newex 1 181 80 9109513 jit.gl.render foo;
> #P flonum 380 302 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P message 380 323 85 9109513 param inscale $1;
> #P window setfont “Sans Serif” 20.;
> #P window linecount 6;
> #P comment 591 178 100 9109524 only after switching from fbo to rtt
> i get op.gt to work.;
> #P window setfont “Sans Serif” 9.;
> #P window linecount 1;
> #P comment 594 45 100 9109513 1. read movie;
> #P user panel 140 228 290 16;
> #X brgb 191 191 191;
> #X frgb 0 0 0;
> #X border 1;
> #X rounded 0;
> #X shadow 0;
> #X done;
> #P connect 8 0 7 0;
> #P connect 7 0 6 0;
> #P connect 6 0 5 0;
> #P connect 6 2 5 0;
> #P connect 6 1 10 0;
> #P fasten 16 0 12 0 184 407 29 407;
> #P fasten 13 0 12 0 111 407 29 407;
> #P connect 9 0 7 1;
> #P fasten 11 0 14 0 27 388 64 388 64 367 72 367;
> #P fasten 6 1 31 0 28 136 81 136 81 53 98 53;
> #P fasten 14 0 15 0 72 387 103 387 103 367 111 367;
> #P connect 15 0 13 0;
> #P connect 31 0 18 0;
> #P fasten 29 0 18 0 175 319 115 319;
> #P connect 27 0 18 0;
> #P fasten 30 0 18 0 224 319 115 319;
> #P connect 31 1 27 0;
> #P connect 17 0 16 0;
> #P fasten 23 0 22 0 194 71 194 71;
> #P connect 31 3 22 0;
> #P connect 22 0 25 0;
> #P connect 25 0 21 0;
> #P connect 31 2 28 0;
> #P connect 21 0 28 0;
> #P fasten 20 0 19 0 299 115 299 115;
> #P fasten 24 0 21 1 351 162 332 162;
> #P fasten 19 0 21 1 299 157 332 157;
> #P connect 33 0 24 0;
> #P connect 4 0 3 0;
> #P connect 3 0 26 0;
> #P pop;
>

#88739
Nov 21, 2006 at 6:18am

> also, iirc, lumalpha is for a ‘single plane’ style texture, imagine just the
> alpha channel. Im not 100% positive about it, as I dont really work with it,
> but I believe that is correct.
>

Almost…lumalpha is for 2 plane matrices. First plane is the alpha
channel and second is the luma channel.

wes

#88740
Nov 21, 2006 at 8:25am

can you unpack planes in gl?
aside from that this patch is problematic, everything has to be load banged
and there is some strange sequence of initialization to make it work.

here is a rivised patch that i was able to make work with a loadbang, notice
the fbo rtt + delay.
i dont know if this is xp specific, but i will continue with what i have
until a better method pops up.

max v2;
#N vpatcher 32 463 806 926;
#P origin 22 -58;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 187 42 219 9109513 t b b b b b;
#P message 1 136 50 9109513 1;
#P newex 471 239 49 9109513 delay 400;
#P button 451 216 15 0;
#P newex 71 348 40 9109513 route init;
#P newex 470 209 93 9109513 t b b;
#P message 384 304 26 9109513 1.01;
#P window linecount 2;
#P message 553 282 91 9109513 ; jitter glreadback fbo;
#P window linecount 1;
#P newex 187 18 93 9109513 loadbang;
#P window linecount 2;
#P message 466 283 86 9109513 ; jitter glreadback rtt;
#P window linecount 1;
#P newex 93 84 55 9109513 t b b b;
#P message 251 357 36 9109513 shader;
#P message 171 357 47 9109513 shader gt;
#P window linecount 2;
#P newex 146 224 212 9109513 jit.gl.videoplane foo @blend_enable
1@automatic0 @capture goo;
#B color 5;
#P newex 162 315 148 9109513 jit.gl.texture foo @name goo @colormode
lumalpha;
#B color 5;
#P newex 380 372 148 9109513 jit.gl.shader foo @file op.gt.jxs @name gt;
#B color 5;
#P window linecount 3;
#P message 424 154 144 9109513 dispose , read op.absdiff.jxs , param
inscale 1. , param outscale 3.5;
#P window linecount 1;
#P message 209 80 180 9109513 read cap_20_11_2006_10_40_39_203.avi;
#P newex 146 112 263 9109513 jit.qt.movie 640 480 @adapt 1 @unique 1;
#P newex 146 201 148 9109513 jit.gl.slab foo @file op.absdiff.jxs;
#B color 5;
#P message 416 113 158 9109513 importmovie Frame_001.BMP , bang;
#P newex 285 153 109 9109513 jit.matrix;
#P window linecount 2;
#P newex 146 378 172 9109513 jit.gl.videoplane foo @scale 1.
0.8@blend_enable 1 @shader gt;
#P toggle 179 397 15 0;
#P window linecount 1;
#P message 179 415 45 9109513 sync $1;
#P toggle 106 397 15 0;
#P newex 67 396 35 9109513 sel 27;
#P message 106 415 68 9109513 fullscreen $1;
#P newex 24 439 145 9109513 jit.window foo @depthbuffer 1;
#P newex 22 396 40 9109513 key;
#P user jit.fpsgui 23 285 60 9109513 0;
#P number 46 158 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P toggle 1 158 15 0;
#P newex 1 184 55 9109513 qmetro 20;
#P newex 1 234 55 9109513 t b b erase;
#P newex 1 318 80 9109513 jit.gl.render foo;
#P flonum 382 325 35 9 0 0 0 139 0 0 0 255 227 23 222 222 222 0 0 0;
#P message 382 346 85 9109513 param inscale $1;
#P connect 37 0 36 0;
#P connect 36 0 5 0;
#P connect 5 0 4 0;
#P connect 4 0 3 0;
#P connect 3 0 2 0;
#P fasten 3 2 2 0 50 266 6 266;
#P connect 3 1 7 0;
#P fasten 13 0 9 0 184 434 29 434;
#P fasten 10 0 9 0 111 434 29 434;
#P connect 6 0 4 1;
#P fasten 8 0 11 0 27 415 64 415 64 394 72 394;
#P fasten 2 1 33 0 76 342 76 342;
#P fasten 3 1 27 0 28 258 81 258 81 80 98 80;
#P fasten 11 0 12 0 72 414 103 414 103 394 111 394;
#P connect 12 0 10 0;
#P fasten 20 0 19 0 214 106 151 106;
#P connect 27 2 19 0;
#P connect 19 0 18 0;
#P connect 27 1 24 0;
#P connect 18 0 24 0;
#P connect 25 0 15 0;
#P connect 23 0 15 0;
#P connect 26 0 15 0;
#P connect 27 0 15 0;
#P connect 27 0 23 0;
#P connect 14 0 13 0;
#P connect 29 0 37 0;
#P connect 37 1 20 0;
#P fasten 21 0 18 1 429 197 289 197;
#P connect 16 0 18 1;
#P fasten 17 0 16 0 421 148 290 148;
#P connect 0 0 22 0;
#P connect 31 0 1 0;
#P connect 1 0 0 0;
#P connect 37 2 31 0;
#P connect 37 4 17 0;
#P connect 37 3 21 0;
#P connect 33 0 34 0;
#P connect 35 0 28 0;
#P fasten 34 0 32 0 475 208;
#P connect 32 0 35 0;
#P connect 32 1 30 0;
#P pop;

On 11/21/06, Wesley Smith wrote:
>
> > also, iirc, lumalpha is for a ‘single plane’ style texture, imagine just
> the
> > alpha channel. Im not 100% positive about it, as I dont really work with
> it,
> > but I believe that is correct.
> >
>
> Almost…lumalpha is for 2 plane matrices. First plane is the alpha
> channel and second is the luma channel.
>
> wes
>

#88741
Nov 21, 2006 at 8:46am

On 11/21/06, yair reshef wrote:
> can you unpack planes in gl?

In a shader you can ack and unpack with swizzle and mask operations.

If I have float4 color;

I can do color = color.grba. or color = color.rrgg for example.

wes

#88742
Nov 21, 2006 at 8:57am

thnx wes,
one more enquiry,
when using rtt or ctt it looks like jitter is doing some things in software
rendering.

example:
take jit.gl.slab.gauss6x-example.pat
add
;jitter glreadback fbo
;jitter glreadback rtt
;jitter glreadback ctt

when in rtt or ctt (default) mode, cpu usage is 43-45%
moving to fbo cpu is 13-17%

On 11/21/06, Wesley Smith wrote:
>
> On 11/21/06, yair reshef wrote:
> > can you unpack planes in gl?
>
> In a shader you can ack and unpack with swizzle and mask operations.
>
> If I have float4 color;
>
> I can do color = color.grba. or color = color.rrgg for example.
>
> wes
>

#88743
Nov 21, 2006 at 9:07am

This is entirely driver dependent. ctt uses glCopyTexSubImage2D to
copy the back buffer. rtt uses pbuffer and fbo uses FBOs. fbos are
the most modern thing. pbuffers are next and ctt is the oldest. I
don’t know much about the performance of pbuffers vs fbos on windows,
but on OSX they have pbuffers are actually a bit faster (at least last
time I checked).

wes

On 11/21/06, yair reshef wrote:
> thnx wes,
> one more enquiry,
> when using rtt or ctt it looks like jitter is doing some things in software
> rendering.
>
> example:
> take jit.gl.slab.gauss6x-example.pat
> add
> ;jitter glreadback fbo
> ;jitter glreadback rtt
> ;jitter glreadback ctt
>
> when in rtt or ctt (default) mode, cpu usage is 43-45%
> moving to fbo cpu is 13-17%
>
> On 11/21/06, Wesley Smith < wesley.hoke@gmail.com> wrote:
> >
> > On 11/21/06, yair reshef < yair99@gmail.com> wrote:
> > > can you unpack planes in gl?
> >
> > In a shader you can ack and unpack with swizzle and mask operations.
> >
> > If I have float4 color;
> >
> > I can do color = color.grba. or color = color.rrgg for example.
> >
> > wes
> >
>
>
>
>
>

#88744
Nov 21, 2006 at 10:30am

problem is can only get op.gt to work with rtt and (without consuming half
my cpu) gaussian.2p blur shader with fbo.

here is a site that offers card compression by extension support.
Delphi3D – Rapid OpenGL Development
http://www.delphi3d.net/hardware/extsupport.php?extension=GL_EXT_framebuffer_object
and this is my card

http://www.delphi3d.net/hardware/viewreport.php?report=1624

and some more info
3D Nature and Partners Declare ATI drivers Unsuitable for Professional
Visualization

http://3dnature.com/ati.html

*Framebuffer Objects and ATI*

http://www.terathon.com/eric/blog.html

that new geforce 8800 looks amazing.

On 11/21/06, Wesley Smith wrote:
>
> This is entirely driver dependent. ctt uses glCopyTexSubImage2D to
> copy the back buffer. rtt uses pbuffer and fbo uses FBOs. fbos are
> the most modern thing. pbuffers are next and ctt is the oldest. I
> don’t know much about the performance of pbuffers vs fbos on windows,
> but on OSX they have pbuffers are actually a bit faster (at least last
> time I checked).
>
> wes
>
> On 11/21/06, yair reshef wrote:
> > thnx wes,
> > one more enquiry,
> > when using rtt or ctt it looks like jitter is doing some things in
> software
> > rendering.
> >
> > example:
> > take jit.gl.slab.gauss6x-example.pat
> > add
> > ;jitter glreadback fbo
> > ;jitter glreadback rtt
> > ;jitter glreadback ctt
> >
> > when in rtt or ctt (default) mode, cpu usage is 43-45%
> > moving to fbo cpu is 13-17%
> >
> > On 11/21/06, Wesley Smith < wesley.hoke@gmail.com> wrote:
> > >
> > > On 11/21/06, yair reshef < yair99@gmail.com> wrote:
> > > > can you unpack planes in gl?
> > >
> > > In a shader you can ack and unpack with swizzle and mask operations.
> > >
> > > If I have float4 color;
> > >
> > > I can do color = color.grba. or color = color.rrgg for example.
> > >
> > > wes
> > >
> >
> >
> >
> >
> >
>

#88745
Nov 21, 2006 at 11:10am

It would be helpful if you could post your OS, graphics card model etc.

wes

#88746
Nov 21, 2006 at 11:19am

< << System Summary >>>

> Mainboard : Gigabyte 8I945GMF

> Chipset : Intel i945G/GZ

> Processor : Intel Pentium D 820 @ 2800 MHz

> Physical Memory : 1024 MB (2 x 512 DDR2-SDRAM )

> Video Card : ATI Technologies Inc Radeon X800 Series

> Hard Disk : WDC (250 GB)

> DVD-Rom Drive : _NEC DVD_RW ND-3550A

> Monitor Type : ProView Technology 770 – 17 inchs

> Network Card : Marvell Semiconductor (Was: Galileo Technology Ltd) Yukon
88E8053 PCI-E Gigabit Ethernet Controller (Copper)

> Operating System : Microsoft Windows XP Home Edition 5.01.2600 Service
Pack 2

> DirectX : Version 9.0c

latest ati driver
max 1.62. jitter 1.63b1a

On 11/21/06, Wesley Smith wrote:
>
> It would be helpful if you could post your OS, graphics card model etc.
>
> wes
>

#88747
Nov 22, 2006 at 1:53am

Hi Yair,
I finally had a chance to look at your patch. I’m trtying it on
Windows XP with Jitter 1.6.3 B1 and an ATI x1600. It’s the same
product line as your graphics card, so you should have the same
capabilities with less throughput.

Your problem with op.absdiff.jxs had me stumped for a bit, but it was
so silly in the end. The problem was with inscale was 1 1 1 1 and
in2scale was 1 1 1 1. Ifn this case if both alpha channels on the
incoming textures are also 1, the output alpha color will be zero and
you will see nothing. In the patch, I set these explicitly in the
jitter object to be inscale (leave as default) and in2scale 1 1 1 0.
I also changed the jxs file to do this by default on my system. It’s
probably a good idea for you to do this as well because otherwise the
default params of op.absdiff.jxs will show nothing which is really
counterintuitive. The problem with op.gt.jxs is exactly the same.

As far as pbuffers, FBOs and CTT are concerned, I can use all 3 with
no issues. I do get a one-time warning from the pbuffers though.

wes

Here’s the patch:
—————————————
#P window setfont “Sans Serif” 9.;
#P number 256 32 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P user jit.fpsgui 236 134 60 9109513 0;
#P window linecount 1;
#P message 284 231 47 9109513 shader gt;
#P message 243 231 36 9109513 shader;
#P message 216 302 60 9109513 file op.gt.jxs;
#P message 243 174 82 9109513 file op.absdiff.jxs;
#P window linecount 2;
#P message 473 38 89 9109513 ; jitter glreadback rtt;
#P message 566 38 91 9109513 ; jitter glreadback fbo;
#P message 380 38 88 9109513 ; jitter glreadback ctt;
#P toggle 613 91 15 0;
#P window linecount 1;
#P newex 216 257 302 9109513 jit.gl.videoplane foo @transform_reset 2
@blend_enable 1 @shader gt;
#P toggle 169 158 15 0;
#P message 169 176 45 9109513 sync $1;
#P toggle 96 158 15 0;
#P newex 57 157 35 9109513 sel 27;
#P message 96 176 68 9109513 fullscreen $1;
#P newex 14 200 145 9109513 jit.window foo @depthbuffer 1;
#P newex 12 157 40 9109513 key;
#P newex 79 115 71 9109513 jit.gl.render foo;
#P newex 79 88 45 9109513 t b erase;
#P newex 613 153 42 9109513 gate 1 1;
#P newex 613 177 44 9109513 jit.matrix;
#P message 272 59 78 9109513 read dishes.mov;
#P toggle 216 33 15 0;
#P newex 216 52 50 9109513 qmetro 33;
#P newex 216 87 91 9109513 jit.qt.movie 320 240;
#P newex 216 202 407 9109513 jit.gl.slab foo @file op.absdiff.jxs
@param in2scale 1. 1. 1. 0. @param outscale 3.5 3.5 3.5 3.5;
#P window linecount 2;
#P newex 216 323 221 9109513 jit.gl.shader foo @file op.gt.jxs @name
gt @param inscale 1.01 1.01 1.01 1.01 @in2scale 1. 1. 1. 0.;
#P window linecount 1;
#P comment 510 92 97 9109513 close to fix frame =>;
#P fasten 13 0 12 0 101 195 19 195;
#P fasten 16 0 12 0 174 195 19 195;
#P fasten 11 0 14 0 17 176 54 176 54 155 62 155;
#P fasten 4 0 9 0 221 75 84 75;
#P connect 9 0 10 0;
#P fasten 9 1 10 0 119 111 84 111;
#P fasten 14 0 15 0 62 175 93 175 93 155 101 155;
#P connect 15 0 13 0;
#P connect 17 0 16 0;
#P connect 5 0 4 0;
#P fasten 6 0 3 0 277 82 221 82;
#P connect 4 0 3 0;
#P connect 3 0 2 0;
#P fasten 23 0 2 0 248 196 221 196;
#P fasten 26 0 18 0 289 252 221 252;
#P fasten 25 0 18 0 248 252 221 252;
#P connect 2 0 18 0;
#P connect 24 0 1 0;
#P fasten 3 0 27 0 221 127 241 127;
#P connect 28 0 4 1;
#P connect 19 0 8 0;
#P connect 8 0 7 0;
#P connect 7 0 2 1;
#P fasten 3 0 8 1 221 117 650 117;
#P window clipboard copycount 29;

#88748
Nov 22, 2006 at 3:10am

Wes, would you mind going a bit in depth with regard to the
difference between the frame buffer backend and the RTT backend
(which I dont even know what it stands for).

Im curious what advantages (if any) these too have, and I think it
would be good to have a little explanation on the list.

Thanks,

v a d e //

http://www.vade.info
abstrakt.vade.info

On Nov 21, 2006, at 8:53 PM, Wesley Smith wrote:

>
> As far as pbuffers, FBOs and CTT are concerned, I can use all 3 with
> no issues. I do get a one-time warning from the pbuffers though.
>

#88749
Nov 22, 2006 at 6:10am

the rtt backend is done with pbuffers. Pbuffers were the solution for
render to texture for a while before fbos were standardized. pbuffers
are platform dependent as they are based on the OS’ windowing API. As
such, they carry all of the state context overhead that a full-fledged
opengl window has. FBOs on the other hand are much more pared down.
The have a color buffer, and optionally a depth buffer and a stencil
buffer and nothing else. They are basically textures + a little more.
FBOs are the way forward as far as opengl is concerned. Right now,
their support is not uniform and drivers don’t always provide speedy
implementations of them.

wes

On 11/21/06, vade wrote:
> Wes, would you mind going a bit in depth with regard to the difference
> between the frame buffer backend and the RTT backend (which I dont even know
> what it stands for).
>
> Im curious what advantages (if any) these too have, and I think it would be
> good to have a little explanation on the list.
>
> Thanks,
>
>
>
> v a d e //
>
> http://www.vade.info
> abstrakt.vade.info
>
> On Nov 21, 2006, at 8:53 PM, Wesley Smith wrote:
>
>
>
>
>
> As far as pbuffers, FBOs and CTT are concerned, I can use all 3 with
>
> no issues. I do get a one-time warning from the pbuffers though.
>
>
>
>
>
>
>

#88750
Nov 22, 2006 at 7:37am

thnkx wes!
clearer now, those param for math shaders are vec4.
ill name my next patch after you

On 11/22/06, Wesley Smith wrote:
>
> the rtt backend is done with pbuffers. Pbuffers were the solution for
> render to texture for a while before fbos were standardized. pbuffers
> are platform dependent as they are based on the OS’ windowing API. As
> such, they carry all of the state context overhead that a full-fledged
> opengl window has. FBOs on the other hand are much more pared down.
> The have a color buffer, and optionally a depth buffer and a stencil
> buffer and nothing else. They are basically textures + a little more.
> FBOs are the way forward as far as opengl is concerned. Right now,
> their support is not uniform and drivers don’t always provide speedy
> implementations of them.
>
> wes
>
> On 11/21/06, vade wrote:
> > Wes, would you mind going a bit in depth with regard to the difference
> > between the frame buffer backend and the RTT backend (which I dont even
> know
> > what it stands for).
> >
> > Im curious what advantages (if any) these too have, and I think it would
> be
> > good to have a little explanation on the list.
> >
> > Thanks,
> >
> >
> >
> > v a d e //
> >
> > http://www.vade.info
> > abstrakt.vade.info
> >
> > On Nov 21, 2006, at 8:53 PM, Wesley Smith wrote:
> >
> >
> >
> >
> >
> > As far as pbuffers, FBOs and CTT are concerned, I can use all 3 with
> >
> > no issues. I do get a one-time warning from the pbuffers though.
> >
> >
> >
> >
> >
> >
> >
>

#88751
Nov 26, 2006 at 8:02am

another question.
this patch shows on my system a cpu increase when moving over 12 slab
processes.
from looking at my cards spec. i can see it has 16 pixel pipelines.
does that mean any shader applied over 16 will be processed by the cpu?

max v2;
#N vpatcher 21 86 822 614;
#P origin 0 -57;
#P window setfont “Sans Serif” 9.;
#P window linecount 2;
#P comment 232 100 81 9109513 adding 12 more slab rises cpu;
#P window linecount 1;
#P comment 465 62 81 9109513 < < low cpu;
#P window linecount 2;
#P message 369 86 91 9109513 ; jitter glreadback rtt;
#P window linecount 1;
#P newex 211 328 185 9109513 jit.gl.videoplane foo @scale 1.333 1. 1.;
#P user gswitch2 185 97 39 32 0 0;
#P newex 211 174 109 9109513 jit.gl.slab.gauss6x foo;
#P newex 211 137 109 9109513 jit.gl.slab.gauss6x foo;
#P window linecount 2;
#P message 369 52 91 9109513 ; jitter glreadback fbo;
#P user jit.fpsgui 563 411 60 9109513 3;
#P user jit.pwindow 394 418 162 122 0 0 0 0 1 0;
#P window linecount 1;
#P newex 396 392 55 9109513 jit.matrix;
#P newex 454 391 73 9109513 jit.uyvy2luma;
#P window linecount 2;
#P newex 396 355 167 9109513 jit.gl.slab foo @file cc.rgba2uyvy.jxs@dimscale
0.5 1.;
#P window linecount 1;
#P message 350 163 17 9109513 1.;
#P newex 350 217 27 9109513 * 2.;
#P comment 395 182 74 9109513 blur amount;
#P newex 211 251 109 9109513 jit.gl.slab.gauss6x foo;
#P flonum 350 184 35 9 0. 0 1 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 211 214 109 9109513 jit.gl.slab.gauss6x foo;
#P message 243 41 79 9109513 read dozer.mov;
#P message 211 41 28 9109513 read;
#P newex 211 73 104 9109513 jit.qt.movie 320 240;
#P toggle 295 411 15 0;
#P message 295 429 45 9109513 sync $1;
#P toggle 222 411 15 0;
#P newex 183 410 35 9109513 sel 27;
#P message 222 429 68 9109513 fullscreen $1;
#P newex 140 453 145 9109513 jit.window foo @depthbuffer 1;
#P newex 138 410 40 9109513 key;
#P user jit.fpsgui 123 235 60 9109513 0;
#P number 146 123 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P toggle 101 123 15 0;
#P newex 101 149 55 9109513 qmetro 20;
#P newex 101 184 55 9109513 t b b erase;
#P newex 101 484 80 9109513 jit.gl.render foo;
#P window setfont “Sans Serif” 12.;
#P window linecount 2;
#P comment 393 202 187 9109516 this example uses 24 passes of a separated
gaussian blur filter;
#P user panel 183 94 167 38;
#X brgb 243 138 138;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P connect 5 0 4 0;
#P connect 4 0 3 0;
#P connect 3 0 2 0;
#P fasten 3 2 2 0 150 217 106 217;
#P connect 3 1 7 0;
#P fasten 10 0 9 0 227 448 145 448;
#P fasten 13 0 9 0 300 448 145 448;
#P connect 6 0 4 1;
#P fasten 8 0 11 0 143 429 180 429 180 408 188 408;
#P fasten 3 1 15 0 128 207 216 71;
#P fasten 16 0 15 0 216 67 216 67;
#P fasten 17 0 15 0 248 67 216 67;
#P connect 32 1 30 0;
#P connect 30 0 31 0;
#P connect 31 0 18 0;
#P fasten 32 0 18 0 196 134;
#P connect 18 0 20 0;
#P connect 20 0 33 0;
#P connect 15 0 32 1;
#P fasten 11 0 12 0 188 428 219 428 219 408 227 408;
#P connect 12 0 10 0;
#P connect 14 0 13 0;
#P connect 19 0 30 1;
#P connect 22 0 31 1;
#P connect 19 0 18 1;
#P connect 22 0 20 1;
#P connect 23 0 19 0;
#P connect 19 0 22 0;
#P fasten 25 0 27 0 459 412 400 412;
#P fasten 20 0 24 0 216 282 401 282;
#P connect 24 0 26 0;
#P connect 26 0 25 0;
#P connect 25 0 28 0;
#P pop;

#88752
Nov 26, 2006 at 8:03am

http://en.wikipedia.org/wiki/Pixel_pipelines
this is a chart with various card pixel pipelines.
mine is the x800

On 11/26/06, yair reshef wrote:
>
> another question.
> this patch shows on my system a cpu increase when moving over 12 slab
> processes.
> from looking at my cards spec. i can see it has 16 pixel pipelines.
> does that mean any shader applied over 16 will be processed by the cpu?
>
> max v2;
> #N vpatcher 21 86 822 614;
> #P origin 0 -57;
> #P window setfont “Sans Serif” 9.;
> #P window linecount 2;
> #P comment 232 100 81 9109513 adding 12 more slab rises cpu;
> #P window linecount 1;
> #P comment 465 62 81 9109513 < < low cpu;
> #P window linecount 2;
> #P message 369 86 91 9109513 ; jitter glreadback rtt;
> #P window linecount 1;
> #P newex 211 328 185 9109513 jit.gl.videoplane foo @scale 1.333 1. 1.;
> #P user gswitch2 185 97 39 32 0 0;
> #P newex 211 174 109 9109513 jit.gl.slab.gauss6x foo;
> #P newex 211 137 109 9109513 jit.gl.slab.gauss6x foo;
> #P window linecount 2;
> #P message 369 52 91 9109513 ; jitter glreadback fbo;
> #P user jit.fpsgui 563 411 60 9109513 3;
> #P user jit.pwindow 394 418 162 122 0 0 0 0 1 0;
> #P window linecount 1;
> #P newex 396 392 55 9109513 jit.matrix;
> #P newex 454 391 73 9109513 jit.uyvy2luma;
> #P window linecount 2;
> #P newex 396 355 167 9109513 jit.gl.slab foo @file cc.rgba2uyvy.jxs@dimscale
> 0.5 1.;
> #P window linecount 1;
> #P message 350 163 17 9109513 1.;
> #P newex 350 217 27 9109513 * 2.;
> #P comment 395 182 74 9109513 blur amount;
> #P newex 211 251 109 9109513 jit.gl.slab.gauss6x foo;
> #P flonum 350 184 35 9 0. 0 1 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 211 214 109 9109513 jit.gl.slab.gauss6x foo;
> #P message 243 41 79 9109513 read dozer.mov;
> #P message 211 41 28 9109513 read;
> #P newex 211 73 104 9109513 jit.qt.movie 320 240;
> #P toggle 295 411 15 0;
> #P message 295 429 45 9109513 sync $1;
> #P toggle 222 411 15 0;
> #P newex 183 410 35 9109513 sel 27;
> #P message 222 429 68 9109513 fullscreen $1;
> #P newex 140 453 145 9109513 jit.window foo @depthbuffer 1;
> #P newex 138 410 40 9109513 key;
> #P user jit.fpsgui 123 235 60 9109513 0;
> #P number 146 123 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P toggle 101 123 15 0;
> #P newex 101 149 55 9109513 qmetro 20;
> #P newex 101 184 55 9109513 t b b erase;
> #P newex 101 484 80 9109513 jit.gl.render foo;
> #P window setfont “Sans Serif” 12.;
> #P window linecount 2;
> #P comment 393 202 187 9109516 this example uses 24 passes of a separated
> gaussian blur filter;
> #P user panel 183 94 167 38;
> #X brgb 243 138 138;
> #X frgb 0 0 0;
> #X border 1;
> #X rounded 0;
> #X shadow 0;
> #X done;
> #P connect 5 0 4 0;
> #P connect 4 0 3 0;
> #P connect 3 0 2 0;
> #P fasten 3 2 2 0 150 217 106 217;
> #P connect 3 1 7 0;
> #P fasten 10 0 9 0 227 448 145 448;
> #P fasten 13 0 9 0 300 448 145 448;
> #P connect 6 0 4 1;
> #P fasten 8 0 11 0 143 429 180 429 180 408 188 408;
> #P fasten 3 1 15 0 128 207 216 71;
> #P fasten 16 0 15 0 216 67 216 67;
> #P fasten 17 0 15 0 248 67 216 67;
> #P connect 32 1 30 0;
> #P connect 30 0 31 0;
> #P connect 31 0 18 0;
> #P fasten 32 0 18 0 196 134;
> #P connect 18 0 20 0;
> #P connect 20 0 33 0;
> #P connect 15 0 32 1;
> #P fasten 11 0 12 0 188 428 219 428 219 408 227 408;
> #P connect 12 0 10 0;
> #P connect 14 0 13 0;
> #P connect 19 0 30 1;
> #P connect 22 0 31 1;
> #P connect 19 0 18 1;
> #P connect 22 0 20 1;
> #P connect 23 0 19 0;
> #P connect 19 0 22 0;
> #P fasten 25 0 27 0 459 412 400 412;
> #P fasten 20 0 24 0 216 282 401 282;
> #P connect 24 0 26 0;
> #P connect 26 0 25 0;
> #P connect 25 0 28 0;
> #P pop;
>
>
>
>

#88753
Nov 26, 2006 at 8:22am

The thing that’s nice about shaders is their parallelism. This is why
they’re so fast. Each vertex is processed independently of its
neighbors. Each fragment is processed independently of its neighbors.
The pixel pipeline figure has to do with how many simultaneous
calculations can be made. If you have a fragment shader running, it
can send data down 16 pipelines simultaneously. This has nothing to
do with how many shaders you can use, but how much data can be
prcessed in paralell. If I remember correctly, the pixel pipelin
figure doesn’t correspond exactly to how many pixels can be processed
simultanously as I believe that in modern ATI and Nvidia hardware,
each pipeline has 4 subunits that each handle a pixel making the total
processing 4*16 pixels in your case. Things only move to the CPU if
your hardware can’t handle the shaders you feed it. I don’t think
Jitter has a software shader fallback, so this is definitely not the
case.

wes

On 11/26/06, yair reshef wrote:
> http://en.wikipedia.org/wiki/Pixel_pipelines
> this is a chart with various card pixel pipelines.
> mine is the x800
>
>
> On 11/26/06, yair reshef
wrote:
> > another question.
> > this patch shows on my system a cpu increase when moving over 12 slab
> processes.
> > from looking at my cards spec. i can see it has 16 pixel pipelines.
> > does that mean any shader applied over 16 will be processed by the cpu?
> >
> > max v2;
> > #N vpatcher 21 86 822 614;
> > #P origin 0 -57;
> > #P window setfont “Sans Serif” 9.;
> > #P window linecount 2;
> > #P comment 232 100 81 9109513 adding 12 more slab rises cpu;
> > #P window linecount 1;
> > #P comment 465 62 81 9109513 < < low cpu;
> > #P window linecount 2;
> > #P message 369 86 91 9109513 ; jitter glreadback rtt;
> > #P window linecount 1;
> > #P newex 211 328 185 9109513 jit.gl.videoplane foo @scale 1.333 1. 1.;
> > #P user gswitch2 185 97 39 32 0 0;
> > #P newex 211 174 109 9109513 jit.gl.slab.gauss6x foo;
> > #P newex 211 137 109 9109513 jit.gl.slab.gauss6x foo;
> > #P window linecount 2;
> > #P message 369 52 91 9109513 ; jitter glreadback fbo;
> > #P user jit.fpsgui 563 411 60 9109513 3;
> > #P user jit.pwindow 394 418 162 122 0 0 0 0 1 0;
> > #P window linecount 1;
> > #P newex 396 392 55 9109513 jit.matrix;
> > #P newex 454 391 73 9109513 jit.uyvy2luma;
> > #P window linecount 2;
> > #P newex 396 355 167 9109513 jit.gl.slab foo @file cc.rgba2uyvy.jxs
> @dimscale 0.5 1.;
> > #P window linecount 1;
> > #P message 350 163 17 9109513 1.;
> > #P newex 350 217 27 9109513 * 2.;
> > #P comment 395 182 74 9109513 blur amount;
> > #P newex 211 251 109 9109513 jit.gl.slab.gauss6x foo;
> > #P flonum 350 184 35 9 0. 0 1 139 0 0 0 221 221 221 222 222 222 0 0 0;
> > #P newex 211 214 109 9109513 jit.gl.slab.gauss6x foo;
> > #P message 243 41 79 9109513 read dozer.mov;
> > #P message 211 41 28 9109513 read;
> > #P newex 211 73 104 9109513 jit.qt.movie 320 240;
> > #P toggle 295 411 15 0;
> > #P message 295 429 45 9109513 sync $1;
> > #P toggle 222 411 15 0;
> > #P newex 183 410 35 9109513 sel 27;
> > #P message 222 429 68 9109513 fullscreen $1;
> > #P newex 140 453 145 9109513 jit.window foo @depthbuffer 1;
> > #P newex 138 410 40 9109513 key;
> > #P user jit.fpsgui 123 235 60 9109513 0;
> > #P number 146 123 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> > #P toggle 101 123 15 0;
> > #P newex 101 149 55 9109513 qmetro 20;
> > #P newex 101 184 55 9109513 t b b erase;
> > #P newex 101 484 80 9109513 jit.gl.render foo;
> > #P window setfont “Sans Serif” 12.;
> > #P window linecount 2;
> > #P comment 393 202 187 9109516 this example uses 24 passes of a separated
> gaussian blur filter;
> > #P user panel 183 94 167 38;
> > #X brgb 243 138 138;
> > #X frgb 0 0 0;
> > #X border 1;
> > #X rounded 0;
> > #X shadow 0;
> > #X done;
> > #P connect 5 0 4 0;
> > #P connect 4 0 3 0;
> > #P connect 3 0 2 0;
> > #P fasten 3 2 2 0 150 217 106 217;
> > #P connect 3 1 7 0;
> > #P fasten 10 0 9 0 227 448 145 448;
> > #P fasten 13 0 9 0 300 448 145 448;
> > #P connect 6 0 4 1;
> > #P fasten 8 0 11 0 143 429 180 429 180 408 188 408;
> > #P fasten 3 1 15 0 128 207 216 71;
> > #P fasten 16 0 15 0 216 67 216 67;
> > #P fasten 17 0 15 0 248 67 216 67;
> > #P connect 32 1 30 0;
> > #P connect 30 0 31 0;
> > #P connect 31 0 18 0;
> > #P fasten 32 0 18 0 196 134;
> > #P connect 18 0 20 0;
> > #P connect 20 0 33 0;
> > #P connect 15 0 32 1;
> > #P fasten 11 0 12 0 188 428 219 428 219 408 227 408;
> > #P connect 12 0 10 0;
> > #P connect 14 0 13 0;
> > #P connect 19 0 30 1;
> > #P connect 22 0 31 1;
> > #P connect 19 0 18 1;
> > #P connect 22 0 20 1;
> > #P connect 23 0 19 0;
> > #P connect 19 0 22 0;
> > #P fasten 25 0 27 0 459 412 400 412;
> > #P fasten 20 0 24 0 216 282 401 282;
> > #P connect 24 0 26 0;
> > #P connect 26 0 25 0;
> > #P connect 25 0 28 0;
> > #P pop;
> >
> >
> >
> >
>
>
>
>
>

#88754
Nov 26, 2006 at 8:47am

if jitter doesn’t have a cpu fallback what type of error will it throw if it
cant handle the shader ( i presume its not a case of error in the shader
syntax but a situation where the shader just doesn’t have a place on the gpu
pipeline).

well there is a cpu hit when using the guess6 slab. i cant figure why.
moving from [@capture] to [to_texture] helped a bit but still i see a cpu
hit when connecting the “output to matrix” slab before and after the guess6
abstraction. its gives beautiful soft edges and i hate to let it go. using
other shaders like convolution or simple blur doesn’t give the same nice
edges.

i just try to simplify the gpu pipeline so i understand better what i can
and cant expect in gpu processing.
without the gauss6 slab i get very good results with my
[uyvy>luma>trashold>geometrical correction>blur>uyvy>matrix output]
background subtraction chain.
i check email with more resources.

On 11/26/06, Wesley Smith wrote:
>
> The thing that’s nice about shaders is their parallelism. This is why
> they’re so fast. Each vertex is processed independently of its
> neighbors. Each fragment is processed independently of its neighbors.
> The pixel pipeline figure has to do with how many simultaneous
> calculations can be made. If you have a fragment shader running, it
> can send data down 16 pipelines simultaneously. This has nothing to
> do with how many shaders you can use, but how much data can be
> prcessed in paralell. If I remember correctly, the pixel pipelin
> figure doesn’t correspond exactly to how many pixels can be processed
> simultanously as I believe that in modern ATI and Nvidia hardware,
> each pipeline has 4 subunits that each handle a pixel making the total
> processing 4*16 pixels in your case. Things only move to the CPU if
> your hardware can’t handle the shaders you feed it. I don’t think
> Jitter has a software shader fallback, so this is definitely not the
> case.
>
> wes
>
> On 11/26/06, yair reshef wrote:
> > http://en.wikipedia.org/wiki/Pixel_pipelines
> > this is a chart with various card pixel pipelines.
> > mine is the x800
> >
> >
> > On 11/26/06, yair reshef
wrote:
> > > another question.
> > > this patch shows on my system a cpu increase when moving over 12 slab
> > processes.
> > > from looking at my cards spec. i can see it has 16 pixel pipelines.
> > > does that mean any shader applied over 16 will be processed by the
> cpu?
> > >
> > > max v2;
> > > #N vpatcher 21 86 822 614;
> > > #P origin 0 -57;
> > > #P window setfont “Sans Serif” 9.;
> > > #P window linecount 2;
> > > #P comment 232 100 81 9109513 adding 12 more slab rises cpu;
> > > #P window linecount 1;
> > > #P comment 465 62 81 9109513 < < low cpu;
> > > #P window linecount 2;
> > > #P message 369 86 91 9109513 ; jitter glreadback rtt;
> > > #P window linecount 1;
> > > #P newex 211 328 185 9109513 jit.gl.videoplane foo @scale 1.333 1. 1.;
> > > #P user gswitch2 185 97 39 32 0 0;
> > > #P newex 211 174 109 9109513 jit.gl.slab.gauss6x foo;
> > > #P newex 211 137 109 9109513 jit.gl.slab.gauss6x foo;
> > > #P window linecount 2;
> > > #P message 369 52 91 9109513 ; jitter glreadback fbo;
> > > #P user jit.fpsgui 563 411 60 9109513 3;
> > > #P user jit.pwindow 394 418 162 122 0 0 0 0 1 0;
> > > #P window linecount 1;
> > > #P newex 396 392 55 9109513 jit.matrix;
> > > #P newex 454 391 73 9109513 jit.uyvy2luma;
> > > #P window linecount 2;
> > > #P newex 396 355 167 9109513 jit.gl.slab foo @file cc.rgba2uyvy.jxs
> > @dimscale 0.5 1.;
> > > #P window linecount 1;
> > > #P message 350 163 17 9109513 1.;
> > > #P newex 350 217 27 9109513 * 2.;
> > > #P comment 395 182 74 9109513 blur amount;
> > > #P newex 211 251 109 9109513 jit.gl.slab.gauss6x foo;
> > > #P flonum 350 184 35 9 0. 0 1 139 0 0 0 221 221 221 222 222 222 0 0 0;
> > > #P newex 211 214 109 9109513 jit.gl.slab.gauss6x foo;
> > > #P message 243 41 79 9109513 read dozer.mov;
> > > #P message 211 41 28 9109513 read;
> > > #P newex 211 73 104 9109513 jit.qt.movie 320 240;
> > > #P toggle 295 411 15 0;
> > > #P message 295 429 45 9109513 sync $1;
> > > #P toggle 222 411 15 0;
> > > #P newex 183 410 35 9109513 sel 27;
> > > #P message 222 429 68 9109513 fullscreen $1;
> > > #P newex 140 453 145 9109513 jit.window foo @depthbuffer 1;
> > > #P newex 138 410 40 9109513 key;
> > > #P user jit.fpsgui 123 235 60 9109513 0;
> > > #P number 146 123 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> > > #P toggle 101 123 15 0;
> > > #P newex 101 149 55 9109513 qmetro 20;
> > > #P newex 101 184 55 9109513 t b b erase;
> > > #P newex 101 484 80 9109513 jit.gl.render foo;
> > > #P window setfont “Sans Serif” 12.;
> > > #P window linecount 2;
> > > #P comment 393 202 187 9109516 this example uses 24 passes of a
> separated
> > gaussian blur filter;
> > > #P user panel 183 94 167 38;
> > > #X brgb 243 138 138;
> > > #X frgb 0 0 0;
> > > #X border 1;
> > > #X rounded 0;
> > > #X shadow 0;
> > > #X done;
> > > #P connect 5 0 4 0;
> > > #P connect 4 0 3 0;
> > > #P connect 3 0 2 0;
> > > #P fasten 3 2 2 0 150 217 106 217;
> > > #P connect 3 1 7 0;
> > > #P fasten 10 0 9 0 227 448 145 448;
> > > #P fasten 13 0 9 0 300 448 145 448;
> > > #P connect 6 0 4 1;
> > > #P fasten 8 0 11 0 143 429 180 429 180 408 188 408;
> > > #P fasten 3 1 15 0 128 207 216 71;
> > > #P fasten 16 0 15 0 216 67 216 67;
> > > #P fasten 17 0 15 0 248 67 216 67;
> > > #P connect 32 1 30 0;
> > > #P connect 30 0 31 0;
> > > #P connect 31 0 18 0;
> > > #P fasten 32 0 18 0 196 134;
> > > #P connect 18 0 20 0;
> > > #P connect 20 0 33 0;
> > > #P connect 15 0 32 1;
> > > #P fasten 11 0 12 0 188 428 219 428 219 408 227 408;
> > > #P connect 12 0 10 0;
> > > #P connect 14 0 13 0;
> > > #P connect 19 0 30 1;
> > > #P connect 22 0 31 1;
> > > #P connect 19 0 18 1;
> > > #P connect 22 0 20 1;
> > > #P connect 23 0 19 0;
> > > #P connect 19 0 22 0;
> > > #P fasten 25 0 27 0 459 412 400 412;
> > > #P fasten 20 0 24 0 216 282 401 282;
> > > #P connect 24 0 26 0;
> > > #P connect 26 0 25 0;
> > > #P connect 25 0 28 0;
> > > #P pop;
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>

#88755
Nov 26, 2006 at 8:54am

Anytime you readback from the GPU, you’re going to get a CPU hit. In
an ideal world, you should be send ing to the GPU and not receiving
from it. If you want efficient patches, you should not rely on
readback. It’s incredibly slow with current hardware. It’s getting
better, but I would definitely avoid it at all costs unless you really
have room to spare. As for shaders that the GPU can’t handle, you’ll
get different results dpeending on what shader language you’re using.
>From my experience, GLSL will just give a black frame and Cg will
report back details as to why your shader couldn’t load such as how
many instructions over the limit the shader went.

wes

On 11/26/06, yair reshef wrote:
> if jitter doesn’t have a cpu fallback what type of error will it throw if it
> cant handle the shader ( i presume its not a case of error in the shader
> syntax but a situation where the shader just doesn’t have a place on the gpu
> pipeline).
>
> well there is a cpu hit when using the guess6 slab. i cant figure why.
> moving from [@capture] to [to_texture] helped a bit but still i see a cpu
> hit when connecting the “output to matrix” slab before and after the guess6
> abstraction. its gives beautiful soft edges and i hate to let it go. using
> other shaders like convolution or simple blur doesn’t give the same nice
> edges.
>
> i just try to simplify the gpu pipeline so i understand better what i can
> and cant expect in gpu processing.
> without the gauss6 slab i get very good results with my
> [uyvy>luma>trashold>geometrical correction>blur>uyvy>matrix output]
> background subtraction chain.
> i check email with more resources.
>
>
>
> On 11/26/06, Wesley Smith < wesley.hoke@gmail.com> wrote:
> > The thing that’s nice about shaders is their parallelism. This is why
> > they’re so fast. Each vertex is processed independently of its
> > neighbors. Each fragment is processed independently of its neighbors.
> > The pixel pipeline figure has to do with how many simultaneous
> > calculations can be made. If you have a fragment shader running, it
> > can send data down 16 pipelines simultaneously. This has nothing to
> > do with how many shaders you can use, but how much data can be
> > prcessed in paralell. If I remember correctly, the pixel pipelin
> > figure doesn’t correspond exactly to how many pixels can be processed
> > simultanously as I believe that in modern ATI and Nvidia hardware,
> > each pipeline has 4 subunits that each handle a pixel making the total
> > processing 4*16 pixels in your case. Things only move to the CPU if
> > your hardware can’t handle the shaders you feed it. I don’t think
> > Jitter has a software shader fallback, so this is definitely not the
> > case.
> >
> > wes
> >
> > On 11/26/06, yair reshef
wrote:
> > > http://en.wikipedia.org/wiki/Pixel_pipelines
> > > this is a chart with various card pixel pipelines.
> > > mine is the x800
> > >
> > >
> > > On 11/26/06, yair reshef < yair99@gmail.com> wrote:
> > > > another question.
> > > > this patch shows on my system a cpu increase when moving over 12 slab
> > > processes.
> > > > from looking at my cards spec. i can see it has 16 pixel pipelines.
> > > > does that mean any shader applied over 16 will be processed by the
> cpu?
> > > >
> > > > max v2;
> > > > #N vpatcher 21 86 822 614;
> > > > #P origin 0 -57;
> > > > #P window setfont “Sans Serif” 9.;
> > > > #P window linecount 2;
> > > > #P comment 232 100 81 9109513 adding 12 more slab rises cpu;
> > > > #P window linecount 1;
> > > > #P comment 465 62 81 9109513 < < low cpu;
> > > > #P window linecount 2;
> > > > #P message 369 86 91 9109513 ; jitter glreadback rtt;
> > > > #P window linecount 1;
> > > > #P newex 211 328 185 9109513 jit.gl.videoplane foo @scale 1.333 1. 1.;
> > > > #P user gswitch2 185 97 39 32 0 0;
> > > > #P newex 211 174 109 9109513 jit.gl.slab.gauss6x foo;
> > > > #P newex 211 137 109 9109513 jit.gl.slab.gauss6x foo;
> > > > #P window linecount 2;
> > > > #P message 369 52 91 9109513 ; jitter glreadback fbo;
> > > > #P user jit.fpsgui 563 411 60 9109513 3;
> > > > #P user jit.pwindow 394 418 162 122 0 0 0 0 1 0;
> > > > #P window linecount 1;
> > > > #P newex 396 392 55 9109513 jit.matrix;
> > > > #P newex 454 391 73 9109513 jit.uyvy2luma;
> > > > #P window linecount 2;
> > > > #P newex 396 355 167 9109513 jit.gl.slab foo @file cc.rgba2uyvy.jxs
> > > @dimscale 0.5 1.;
> > > > #P window linecount 1;
> > > > #P message 350 163 17 9109513 1.;
> > > > #P newex 350 217 27 9109513 * 2.;
> > > > #P comment 395 182 74 9109513 blur amount;
> > > > #P newex 211 251 109 9109513 jit.gl.slab.gauss6x foo;
> > > > #P flonum 350 184 35 9 0. 0 1 139 0 0 0 221 221 221 222 222 222 0 0 0;
> > > > #P newex 211 214 109 9109513 jit.gl.slab.gauss6x foo;
> > > > #P message 243 41 79 9109513 read dozer.mov;
> > > > #P message 211 41 28 9109513 read;
> > > > #P newex 211 73 104 9109513 jit.qt.movie 320 240;
> > > > #P toggle 295 411 15 0;
> > > > #P message 295 429 45 9109513 sync $1;
> > > > #P toggle 222 411 15 0;
> > > > #P newex 183 410 35 9109513 sel 27;
> > > > #P message 222 429 68 9109513 fullscreen $1;
> > > > #P newex 140 453 145 9109513 jit.window foo @depthbuffer 1;
> > > > #P newex 138 410 40 9109513 key;
> > > > #P user jit.fpsgui 123 235 60 9109513 0;
> > > > #P number 146 123 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> > > > #P toggle 101 123 15 0;
> > > > #P newex 101 149 55 9109513 qmetro 20;
> > > > #P newex 101 184 55 9109513 t b b erase;
> > > > #P newex 101 484 80 9109513 jit.gl.render foo;
> > > > #P window setfont “Sans Serif” 12.;
> > > > #P window linecount 2;
> > > > #P comment 393 202 187 9109516 this example uses 24 passes of a
> separated
> > > gaussian blur filter;
> > > > #P user panel 183 94 167 38;
> > > > #X brgb 243 138 138;
> > > > #X frgb 0 0 0;
> > > > #X border 1;
> > > > #X rounded 0;
> > > > #X shadow 0;
> > > > #X done;
> > > > #P connect 5 0 4 0;
> > > > #P connect 4 0 3 0;
> > > > #P connect 3 0 2 0;
> > > > #P fasten 3 2 2 0 150 217 106 217;
> > > > #P connect 3 1 7 0;
> > > > #P fasten 10 0 9 0 227 448 145 448;
> > > > #P fasten 13 0 9 0 300 448 145 448;
> > > > #P connect 6 0 4 1;
> > > > #P fasten 8 0 11 0 143 429 180 429 180 408 188 408;
> > > > #P fasten 3 1 15 0 128 207 216 71;
> > > > #P fasten 16 0 15 0 216 67 216 67;
> > > > #P fasten 17 0 15 0 248 67 216 67;
> > > > #P connect 32 1 30 0;
> > > > #P connect 30 0 31 0;
> > > > #P connect 31 0 18 0;
> > > > #P fasten 32 0 18 0 196 134;
> > > > #P connect 18 0 20 0;
> > > > #P connect 20 0 33 0;
> > > > #P connect 15 0 32 1;
> > > > #P fasten 11 0 12 0 188 428 219 428 219 408 227 408;
> > > > #P connect 12 0 10 0;
> > > > #P connect 14 0 13 0;
> > > > #P connect 19 0 30 1;
> > > > #P connect 22 0 31 1;
> > > > #P connect 19 0 18 1;
> > > > #P connect 22 0 20 1;
> > > > #P connect 23 0 19 0;
> > > > #P connect 19 0 22 0;
> > > > #P fasten 25 0 27 0 459 412 400 412;
> > > > #P fasten 20 0 24 0 216 282 401 282;
> > > > #P connect 24 0 26 0;
> > > > #P connect 26 0 25 0;
> > > > #P connect 25 0 28 0;
> > > > #P pop;
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
>
>
>
>
>

#88756
Nov 28, 2006 at 1:09pm

just to follow, i get better performance with glreadpixels as shown in the
slab example dir and exampled in “[jitter] software rendering on win” thread

On 11/26/06, Wesley Smith < wesley.hoke@gmail.com> wrote:
>
> Anytime you readback from the GPU, you’re going to get a CPU hit. In
> an ideal world, you should be send ing to the GPU and not receiving
> from it. If you want efficient patches, you should not rely on
> readback. It’s incredibly slow with current hardware. It’s getting
> better, but I would definitely avoid it at all costs unless you really
> have room to spare. As for shaders that the GPU can’t handle, you’ll
> get different results dpeending on what shader language you’re using.
> >From my experience, GLSL will just give a black frame and Cg will
> report back details as to why your shader couldn’t load such as how
> many instructions over the limit the shader went.
>
> wes
>
>
> On 11/26/06, yair reshef wrote:
> > if jitter doesn’t have a cpu fallback what type of error will it throw
> if it
> > cant handle the shader ( i presume its not a case of error in the shader
> > syntax but a situation where the shader just doesn’t have a place on the
> gpu
> > pipeline).
> >
> > well there is a cpu hit when using the guess6 slab. i cant figure why.
> > moving from [@capture] to [to_texture] helped a bit but still i see a
> cpu
> > hit when connecting the “output to matrix” slab before and after the
> guess6
> > abstraction. its gives beautiful soft edges and i hate to let it go.
> using
> > other shaders like convolution or simple blur doesn’t give the same nice
> > edges.
> >
> > i just try to simplify the gpu pipeline so i understand better what i
> can
> > and cant expect in gpu processing.
> > without the gauss6 slab i get very good results with my
> > [uyvy>luma>trashold>geometrical correction>blur>uyvy>matrix output]
> > background subtraction chain.
> > i check email with more resources.
> >
> >
> >
> > On 11/26/06, Wesley Smith < wesley.hoke@gmail.com> wrote:
> > > The thing that’s nice about shaders is their parallelism. This is why
>
> > > they’re so fast. Each vertex is processed independently of its
> > > neighbors. Each fragment is processed independently of its neighbors.
> > > The pixel pipeline figure has to do with how many simultaneous
> > > calculations can be made. If you have a fragment shader running, it
> > > can send data down 16 pipelines simultaneously. This has nothing to
> > > do with how many shaders you can use, but how much data can be
> > > prcessed in paralell. If I remember correctly, the pixel pipelin
> > > figure doesn’t correspond exactly to how many pixels can be processed
> > > simultanously as I believe that in modern ATI and Nvidia hardware,
> > > each pipeline has 4 subunits that each handle a pixel making the total
> > > processing 4*16 pixels in your case. Things only move to the CPU if
> > > your hardware can’t handle the shaders you feed it. I don’t think
> > > Jitter has a software shader fallback, so this is definitely not the
> > > case.
> > >
> > > wes
> > >
> > > On 11/26/06, yair reshef < yair99@gmail.com> wrote:
> > > > http://en.wikipedia.org/wiki/Pixel_pipelines
> > > > this is a chart with various card pixel pipelines.
> > > > mine is the x800
> > > >
> > > >
> > > > On 11/26/06, yair reshef < yair99@gmail.com> wrote:
> > > > > another question.
> > > > > this patch shows on my system a cpu increase when moving over 12
> slab
> > > > processes.
> > > > > from looking at my cards spec. i can see it has 16 pixel
> pipelines.
> > > > > does that mean any shader applied over 16 will be processed by the
>
> > cpu?
> > > > >
> > > > > max v2;
> > > > > #N vpatcher 21 86 822 614;
> > > > > #P origin 0 -57;
> > > > > #P window setfont “Sans Serif” 9.;
> > > > > #P window linecount 2;
> > > > > #P comment 232 100 81 9109513 adding 12 more slab rises cpu;
> > > > > #P window linecount 1;
> > > > > #P comment 465 62 81 9109513 < < low cpu;
> > > > > #P window linecount 2;
> > > > > #P message 369 86 91 9109513 ; jitter glreadback rtt;
> > > > > #P window linecount 1;
> > > > > #P newex 211 328 185 9109513 jit.gl.videoplane foo @scale 1.333 1.
> 1.;
> > > > > #P user gswitch2 185 97 39 32 0 0;
> > > > > #P newex 211 174 109 9109513 jit.gl.slab.gauss6x foo;
> > > > > #P newex 211 137 109 9109513 jit.gl.slab.gauss6x foo;
> > > > > #P window linecount 2;
> > > > > #P message 369 52 91 9109513 ; jitter glreadback fbo;
> > > > > #P user jit.fpsgui 563 411 60 9109513 3;
> > > > > #P user jit.pwindow 394 418 162 122 0 0 0 0 1 0;
> > > > > #P window linecount 1;
> > > > > #P newex 396 392 55 9109513 jit.matrix;
> > > > > #P newex 454 391 73 9109513 jit.uyvy2luma;
> > > > > #P window linecount 2;
> > > > > #P newex 396 355 167 9109513 jit.gl.slab foo @file
> cc.rgba2uyvy.jxs
> > > > @dimscale 0.5 1.;
> > > > > #P window linecount 1;
> > > > > #P message 350 163 17 9109513 1.;
> > > > > #P newex 350 217 27 9109513 * 2.;
> > > > > #P comment 395 182 74 9109513 blur amount;
> > > > > #P newex 211 251 109 9109513 jit.gl.slab.gauss6x foo;
> > > > > #P flonum 350 184 35 9 0. 0 1 139 0 0 0 221 221 221 222 222 222 0
> 0 0;
> > > > > #P newex 211 214 109 9109513 jit.gl.slab.gauss6x foo;
> > > > > #P message 243 41 79 9109513 read dozer.mov;
> > > > > #P message 211 41 28 9109513 read;
> > > > > #P newex 211 73 104 9109513 jit.qt.movie 320 240;
> > > > > #P toggle 295 411 15 0;
> > > > > #P message 295 429 45 9109513 sync $1;
> > > > > #P toggle 222 411 15 0;
> > > > > #P newex 183 410 35 9109513 sel 27;
> > > > > #P message 222 429 68 9109513 fullscreen $1;
> > > > > #P newex 140 453 145 9109513 jit.window foo @depthbuffer 1;
> > > > > #P newex 138 410 40 9109513 key;
> > > > > #P user jit.fpsgui 123 235 60 9109513 0;
> > > > > #P number 146 123 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0
> 0;
> > > > > #P toggle 101 123 15 0;
> > > > > #P newex 101 149 55 9109513 qmetro 20;
> > > > > #P newex 101 184 55 9109513 t b b erase;
> > > > > #P newex 101 484 80 9109513 jit.gl.render foo;
> > > > > #P window setfont “Sans Serif” 12.;
> > > > > #P window linecount 2;
> > > > > #P comment 393 202 187 9109516 this example uses 24 passes of a
> > separated
> > > > gaussian blur filter;
> > > > > #P user panel 183 94 167 38;
> > > > > #X brgb 243 138 138;
> > > > > #X frgb 0 0 0;
> > > > > #X border 1;
> > > > > #X rounded 0;
> > > > > #X shadow 0;
> > > > > #X done;
> > > > > #P connect 5 0 4 0;
> > > > > #P connect 4 0 3 0;
> > > > > #P connect 3 0 2 0;
> > > > > #P fasten 3 2 2 0 150 217 106 217;
> > > > > #P connect 3 1 7 0;
> > > > > #P fasten 10 0 9 0 227 448 145 448;
> > > > > #P fasten 13 0 9 0 300 448 145 448;
> > > > > #P connect 6 0 4 1;
> > > > > #P fasten 8 0 11 0 143 429 180 429 180 408 188 408;
> > > > > #P fasten 3 1 15 0 128 207 216 71;
> > > > > #P fasten 16 0 15 0 216 67 216 67;
> > > > > #P fasten 17 0 15 0 248 67 216 67;
> > > > > #P connect 32 1 30 0;
> > > > > #P connect 30 0 31 0;
> > > > > #P connect 31 0 18 0;
> > > > > #P fasten 32 0 18 0 196 134;
> > > > > #P connect 18 0 20 0;
> > > > > #P connect 20 0 33 0;
> > > > > #P connect 15 0 32 1;
> > > > > #P fasten 11 0 12 0 188 428 219 428 219 408 227 408;
> > > > > #P connect 12 0 10 0;
> > > > > #P connect 14 0 13 0;
> > > > > #P connect 19 0 30 1;
> > > > > #P connect 22 0 31 1;
> > > > > #P connect 19 0 18 1;
> > > > > #P connect 22 0 20 1;
> > > > > #P connect 23 0 19 0;
> > > > > #P connect 19 0 22 0;
> > > > > #P fasten 25 0 27 0 459 412 400 412;
> > > > > #P fasten 20 0 24 0 216 282 401 282;
> > > > > #P connect 24 0 26 0;
> > > > > #P connect 26 0 25 0;
> > > > > #P connect 25 0 28 0;
> > > > > #P pop;
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
> >
> >
>

#88757

You must be logged in to reply to this topic.