...just throwing this out to anyone: I've come across a problem that has me stumped...it occurs when I'm working on a shader and change the number of uniform variables between loadings, such that re- linking causes a crash at:
m_symname[i]=gensym(m_name[i]);
...this is in a loop that grabs results of active uniform variables, and it seems we're not cleaning up correctly either m_name[i] or m_symname[i]...I've also noticed that sometimes m_name[0] will not correctly be filled in, and therefore it doesn't show up in printInfo ()...
...I tried something like the following for m_name, m_symname, and m_params, but it's not enough:
if (m_name) { for (int i = 0; i < m_uniformCount; i++) free(m_name[i]); free(m_name); }
...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?
jamie
james tittle wrote:
...just throwing this out to anyone: I've come across a problem that has me stumped...it occurs when I'm working on a shader and change the number of uniform variables between loadings, such that re- linking causes a crash at:
m_symname[i]=gensym(m_name[i]);
...this is in a loop that grabs results of active uniform variables, and it seems we're not cleaning up correctly either m_name[i] or m_symname[i]...I've also noticed that sometimes m_name[0] will not
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.
correctly be filled in, and therefore it doesn't show up in printInfo ()...
...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.
i did a lot of other changes which shouldn't affect the behaviour. now it works for me (i just committed it)
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...?
happy glsling
mfg,asdr IOhannes
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
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@iem.at http://lists.puredata.info/listinfo/gem-dev
Quoting james tittle tigital@mac.com:
...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 am not sure. a diff between the 2 last versions did not show up the change i made (though i noticed that you did change one "<=" to "<") - probably there were 2 of them...
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?
well, i moved the actual LinkProgram() to be called from within render() and not directly from the linkMess(). the linkMess() just tells the [glsl_program], that at the next render cycle the objects should be linked. probably this does not matter, however i wanted to be sure, that we have a valid GL-context; the only moment we can be sure that there is a valid GL-context is during one of the render()-function calls (this includes postrender(), startRender() and so on)
...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
oh, i am not using the toon.vp and toon.fp shaders (which are ARB), but some others, which i am quite sure that they are GLSL. probably i found them somewhere "at the internet".
easily in glsl, and it would likely have "gl_ModelViewProjectionMatrix" as an active uniform: this is usually
are there implicit active uniforms (which i don't have to declare as such) ?
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...
yes, i really have to get the orange book (and open my copy of the red book once in a while ;-))
mfg,.adsr. IOhannes
PS: ben, the patch is really the one, jamie sent some weeks ago on this list. however, i can send it tomorrow.
On Feb 28, 2006, at 4:47 PM, zmoelnig@iem.at wrote:
Quoting james tittle tigital@mac.com:
...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?
well, i moved the actual LinkProgram() to be called from within render() and not directly from the linkMess(). the linkMess() just tells the [glsl_program], that at the next render cycle the objects should be linked. probably this does not matter, however i wanted to be sure, that we have a valid GL-context; the only moment we can be sure that there is a valid GL-context is during one of the render()-function calls (this includes postrender(), startRender() and so on)
...ok, just checked it out and it's working great on this end: thanks for the cleanup, I always forget and try to do c instead of using c++ features such as new[] and delete[] and...
easily in glsl, and it would likely have "gl_ModelViewProjectionMatrix" as an active uniform: this is usually
are there implicit active uniforms (which i don't have to declare as such) ?
...there are a bunch of built-in uniforms (ex. gl_ModelViewMatrix, gl_LightSource[2].spotDirection), attributes (ex. gl_Color, gl_Normal), and varying (ex. gl_FrontColor, gl_TexCoord[]) variables...any opengl state variable can be accessed with the reserved prefix "gl_*", and there's obviously some shared between vertex and fragment shaders, and some are just plain different...if you don't wanna get the orange book, grab the glsl spec:
http://opengl.org/documentation/oglsl.html
PS: ben, the patch is really the one, jamie sent some weeks ago on this list. however, i can send it tomorrow.
...I'm sending it to him again off-list...
back to other things, jamie
-
B. Bogart -
IOhannes m zmoelnig -
james tittle -
zmoelnig＠iem.at