hi,
i'm currently debugging a problem with shaders on debian/64bit.
the problem shows as follows: - [glsl_vertex] opens a shader-file, compiles it, retrieves the shader-ID, converts it to t_float using reinterpretation cast (t_float/GLuint union) and sends it out - the shaderID shows as "0", [change] doesn't let it through, thus the shader is not linked and not run :-(
this happens with Gem as shipped with debian/sid (and debian/squeeze!, iirc)
if i compile it myself on the very same machine, the shaderID (GLuint)1 will translate to a t_float of approximately 1.4013e-45, which is distinct from 0, thus [change] let's them trough, and the shader works.
with some little debugging object that does the GLuint/t_float reinterpretation casts within the patch, i see that both times, the translation actually produces the correct result, however: - Gem-0.92.3/debian loaded: "1" -> ~0 - Gem-0.92.3/self loaded: "1" -> ~1.4013e-45
clearly this mainly a problem in debian's way to compile Gem (i guess some SSE-enable/disable/cleanup thing), though if anybody can illuminate me so i can fix it, i would be thankful...
otoh, it also shows that [change] is not good enough for detecting shader-changes. (even though Pd shows "0" for (GLuint)1, it seems like the number is only _very_ small (denormal - ha, that's probably the clue!), but still sufficiently distinct from the "0" produced by e.g. (GLuint)2...
so this means we probably do have to get rid of a numeric representation of the shaderIDs alltogether, and switch to a symbolic representation, which would break about all patches using shaders :-(
ideas?
fgmadr IOhannes
hello,
if things need to be broken, then i suggest not to change glsl_vertex, glsl_ etc, but to create other object. so the current patch will work with 32 bit system. and patch using this new objects will work with both 32 and 64 bits systems.
cyrille
Le 01/12/2010 12:44, IOhannes m zmoelnig a écrit :
hi,
i'm currently debugging a problem with shaders on debian/64bit.
the problem shows as follows:
- [glsl_vertex] opens a shader-file, compiles it, retrieves the
shader-ID, converts it to t_float using reinterpretation cast (t_float/GLuint union) and sends it out
- the shaderID shows as "0", [change] doesn't let it through, thus the
shader is not linked and not run :-(
this happens with Gem as shipped with debian/sid (and debian/squeeze!, iirc)
if i compile it myself on the very same machine, the shaderID (GLuint)1 will translate to a t_float of approximately 1.4013e-45, which is distinct from 0, thus [change] let's them trough, and the shader works.
with some little debugging object that does the GLuint/t_float reinterpretation casts within the patch, i see that both times, the translation actually produces the correct result, however:
- Gem-0.92.3/debian loaded: "1" -> ~0
- Gem-0.92.3/self loaded: "1" -> ~1.4013e-45
clearly this mainly a problem in debian's way to compile Gem (i guess some SSE-enable/disable/cleanup thing), though if anybody can illuminate me so i can fix it, i would be thankful...
otoh, it also shows that [change] is not good enough for detecting shader-changes. (even though Pd shows "0" for (GLuint)1, it seems like the number is only _very_ small (denormal - ha, that's probably the clue!), but still sufficiently distinct from the "0" produced by e.g. (GLuint)2...
so this means we probably do have to get rid of a numeric representation of the shaderIDs alltogether, and switch to a symbolic representation, which would break about all patches using shaders :-(
ideas?
fgmadr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On 2010-12-02 14:24, cyrille henry wrote:
hello,
if things need to be broken, then i suggest not to change glsl_vertex, glsl_ etc, but to create other object. so the current patch will work with 32 bit system. and patch using this new objects will work with both 32 and 64 bits systems.
ah no, this doesn't sound like a good idea. i'd rather have to force users to switch now than to maintain 2 separate sets of objects for the rest of Gem's live. but read on!
i investigated a bit further and have created a fix that should be totally transparent from the user's pov, by not using wild reinterpretation-casts but instead using a lookup table where the real GLuint IDs are mapped to small floats.
this should work (check svn)
fgmasdr IOhannes
Hello,
Le 02/12/2010 14:33, IOhannes m zmoelnig a écrit :
On 2010-12-02 14:24, cyrille henry wrote:
hello,
if things need to be broken, then i suggest not to change glsl_vertex, glsl_ etc, but to create other object. so the current patch will work with 32 bit system. and patch using this new objects will work with both 32 and 64 bits systems.
ah no, this doesn't sound like a good idea. i'd rather have to force users to switch now than to maintain 2 separate sets of objects for the rest of Gem's live.
it's possible to provide the old object as abstraction based on new object.
but read on!
i investigated a bit further and have created a fix that should be totally transparent from the user's pov, by not using wild reinterpretation-casts but instead using a lookup table where the real GLuint IDs are mapped to small floats.
this is a very good solution...
this should work (check svn)
i usually don't do any update 1 day befor a big performance using Gem. i will not have time to test very soon. but i'll have a 64 bit computer in 1 or 2 month max...
thx Cyrille
fgmasdr IOhannes
On Wed, 1 Dec 2010, IOhannes m zmoelnig wrote:
- [glsl_vertex] opens a shader-file, compiles it, retrieves the
shader-ID, converts it to t_float using reinterpretation cast (t_float/GLuint union) and sends it out - the shaderID shows as "0", [change] doesn't let it through, thus the shader is not linked and not run :-(
If shader-IDs don't use all the bits in the GLuint, you may be able to cast it to float the normal way... you just need to make sure it's always less than 16777216.
If not, then could you fake it ? Make a table of all the existing IDs and use ID-indices all over, instead of the IDs themselves. It's a bit like we have symbols instead of strings.
clearly this mainly a problem in debian's way to compile Gem (i guess some SSE-enable/disable/cleanup thing), though if anybody can illuminate me so i can fix it, i would be thankful...
It's easier to just drop the reinterpret_cast. Note that if this were a float being reinterpreted as an int and back, it wouldn't be a problem, because the int format has no special values.
so this means we probably do have to get rid of a numeric representation of the shaderIDs alltogether, and switch to a symbolic representation, which would break about all patches using shaders :-(
No, you don't need to turn it into symbols.
ideas?
yes (sometimes).
_______________________________________________________________________ | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On 12/03/2010 05:06 AM, Mathieu Bouchard wrote:
On Wed, 1 Dec 2010, IOhannes m zmoelnig wrote:
- [glsl_vertex] opens a shader-file, compiles it, retrieves the
shader-ID, converts it to t_float using reinterpretation cast (t_float/GLuint union) and sends it out - the shaderID shows as "0", [change] doesn't let it through, thus the shader is not linked and not run :-(
If shader-IDs don't use all the bits in the GLuint, you may be able to cast it to float the normal way... you just need to make sure it's always less than 16777216.
which unfortunately is not true. tis was the reason hy the reinterpret_cast was introduced in the first place, as soe openGL implementations (ati/radeon iirc) were using large uints for representing shader IDs.
If not, then could you fake it ? Make a table of all the existing IDs and use ID-indices all over, instead of the IDs themselves. It's a bit like we have symbols instead of strings.
this is what i've done now.
clearly this mainly a problem in debian's way to compile Gem (i guess some SSE-enable/disable/cleanup thing), though if anybody can illuminate me so i can fix it, i would be thankful...
It's easier to just drop the reinterpret_cast. Note that if this were a float being reinterpreted as an int and back, it wouldn't be a problem, because the int format has no special values.
again, in theory it worked fine (both GLuint and t_float being 32bit) the problem came from the use of [change] in virtually any patch using shaders, and the test for equality wouldn't trigger with some numbers (denormals i believe)
come to think of it, it was probably a bad idea to output the shaderID each render cycle rather than only when the shader was created. if the ID was only output once, there would be no need for a [change] at all. i'll probably add this as well.
fgmasdr IOhannes
-
cyrille henry -
IOhannes m zmoelnig -
IOhannes zmölnig
-
Mathieu Bouchard