yair reshef

hi, i have an op image processing chain i used for background removal. i

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

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

so had to capture ,change colormode and apply a texture and shader to a

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

4. is there a recommended limit for captured textures? can i make a

"capture this gridshape plane" abstraction and worry not?

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.

opengl-voodo

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 

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.

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 

> 1. couldn't get a texture object to accept a shader.

> 2. couldn't get a slab to switch colormode to lumalpha (is lumalpha 

> 4. is there a recommended limit for captured textures? can i make 

> a "capture this gridshape plane" abstraction and worry not?

> #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 message 488 247 91 9109513 ; jitter glreadback fbo;

> #P message 488 213 86 9109513 ; jitter glreadback rtt;

> #P message 170 299 47 9109513 shader gt;

> #P newex 189 189 212 9109513 jit.gl.videoplane foo @blend_enable 

> #P newex 126 260 148 9109513 jit.gl.texture foo @name goo 

> #P newex 380 345 148 9109513 jit.gl.shader foo @file op.gt.jxs 

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.

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


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

Almost...lumalpha is for 2 plane matrices. First plane is the alpha

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

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

i dont know if this is xp specific, but i will continue with what i have

> > also, iirc, lumalpha is for a 'single plane' style texture, imagine just

> > alpha channel. Im not 100% positive about it, as I dont really work with

> Almost...lumalpha is for 2 plane matrices. First plane is the alpha

> channel and second is the luma channel.

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.

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
>

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

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

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

when using rtt or ctt it looks like jitter is doing some things in software

when in rtt or ctt (default) mode, cpu usage is 43-45%

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

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

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
>

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

> when using rtt or ctt it looks like jitter is doing some things in software

> when in rtt or ctt (default) mode, cpu usage is 43-45%

> On 11/21/06, Wesley Smith < wesley.hoke@gmail.com> wrote:

> > On 11/21/06, yair reshef < yair99@gmail.com> wrote:

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

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

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

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


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.

http://www.delphi3d.net/hardware/extsupport.php?extension=GL_EXT_framebuffer_object

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

3D Nature and Partners Declare ATI drivers Unsuitable for Professional

> 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

> > when using rtt or ctt it looks like jitter is doing some things in

> > when in rtt or ctt (default) mode, cpu usage is 43-45%

> > On 11/21/06, Wesley Smith < wesley.hoke@gmail.com> wrote:

> > > On 11/21/06, yair reshef < yair99@gmail.com> wrote:

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

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

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

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

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

> Processor : Intel Pentium D 820 @ 2800 MHz

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

> Video Card : ATI Technologies Inc Radeon X800 Series

> 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

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

  > Processor : Intel Pentium D 820 @ 2800 MHz

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

  > Video Card : ATI Technologies Inc Radeon X800 Series

  > 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

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
>

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

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.

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.

Here's the patch:
---------------------------------------



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.

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.

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.

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


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

> 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

> Im curious what advantages (if any) these too have, and I think it would be

> good to have a little explanation on the list.

> On Nov 21, 2006, at 8:53 PM, 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.

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


clearer now, those param for math shaders are vec4.

> 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

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

> > Im curious what advantages (if any) these too have, and I think it would

> > good to have a little explanation on the list.

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

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

this patch shows on my system a cpu increase when moving over 12 slab

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?

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?

http://en.wikipedia.org/wiki/Pixel_pipelines

opengl voodo