[GEM-dev] [glsl_program] getVariables() prob

[B. Bogart]

Johannes,

can you send me your patch that used that gaussion filter shader that
you did get to work on linux? I'd like to see how my N6600 compares for
the pix_convolve for that shader...

Thanks.
.b.

james tittle wrote:
> On Feb 28, 2006, at 12:40 PM, IOhannes m zmoelnig wrote:
>
>> you should never ever "clean up" a pd-symbol (like m_symname[i]);
>> however, deallocating the m_symname-table (which only holds references
>> to symbols) is fine.
>
>
> ...ok, this could be the prob...?
>
>>> ...also, in getVariables() I've rearranged the order of free-ing
>>> variables so that it occurs before we query the gl object parameters
>>> (ie. before we reset m_uniformCount to it's new value), but this
>>> wasn't
>>> the full answer...any other ideas?
>>
>>
>> wow. that greyed some of my hair...
>> took me till now to find it and it turned out to be a tiny "<="  instead
>> of "<" in line-101.
>
>
> ...yeh, I fixed that in my previous commit (ie. from "<=" to "<"),  but
> I guess my over-free()-ing was a problem:  typical problem of  changing
> too many things at the same time?
>
>> i did a lot of other changes which shouldn't affect the behaviour.
>> now it works for me (i just committed it)
>
>
> ...my modem access atm doesn't allow me to get thru to cvs.sf.net  (?),
> but I looked at your diff and see a variable m_wantLink(0) which  I
> don't have:  are we in sync on this file?
>
> ...also, good call on dropping m_name[]:  I didn't realize we were
> actually comparing paramMess()'s to m_symname[]!
>
>> one last question:
>> when loading the "Toon"-shader (dunno who sent it, i guess jamie),  i get
>> active uniform variables like "gl_ModelViewProjectionMatrix" (apart  from
>> the valid "Phong"); i have no idea where this comes from; anyone...?
>
>
> ...aha, at least something I can answer ;-)  On the one hand, the  toon
> shader in cvs is an arb_program, not glsl...but you could do it  easily
> in glsl, and it would likely have  "gl_ModelViewProjectionMatrix" as an
> active uniform:  this is usually  set up in the vertex shader and passed
> into the fragment  shader...there are actually a whole host of built-in
> active uniform  variables that have to do with different parts of gl's
> pipeline:   check out the spec, the new red book covering 2.0, or the
> orange book  for more info...I don't think these are designed to be
> manipulated by  the user, but they could be...
>
>> happy glsling
>
>
> ...well, it's certainly not a cure-all at present time:  I don't know
> if we're just dealing with early drivers or cards that have few pixel
> pipelines that are causing slower performance than expected...at  least
> the groundwork is laid...now to get the rest of gem up to gl 1.5!
>
> jamie
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20060228/e2e12d75/attachment.pgp>