[GEM-dev] shaders on 64bit systems

[cyrille henry]

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 at iem.at
> http://lists.puredata.info/listinfo/gem-dev