Hello everybody, I'm new to the list.
I'm working on a multipass glsl blur for Gem which needs downsampling for each pass. I managed to do that easily with a dimen message. It works fine, but [gemframebuffer] is flooding the console with "init" messages for every dimen change.
[gemframebuffer]: using rectmode 1:GL_TEXTURE_RECTANGLE [gemframebuffer]: using type: BYTE [gemframebuffer]: using color: RGB [gemframebuffer]: using texunit: 0
Is there a way to silence [gemframebuffer]? Am I supposed to take a different approach? I'm not an expert but I guess this is not an isolated case, downsampling seems to be a common technique when working with textures for glsl use.
Best, Guido
hello, welcome,
You should create multiple framebuffer during initialisation. one for each size.
I think the main problem with changing framebuffer size is not only the message in the console, but also poor performances.
cheers Cyrille
Le 20/10/2011 11:03, Guido Tamino a écrit :
Hello everybody, I'm new to the list.
I'm working on a multipass glsl blur for Gem which needs downsampling for each pass. I managed to do that easily with a dimen message. It works fine, but [gemframebuffer] is flooding the console with "init" messages for every dimen change.
[gemframebuffer]: using rectmode 1:GL_TEXTURE_RECTANGLE [gemframebuffer]: using type: BYTE [gemframebuffer]: using color: RGB [gemframebuffer]: using texunit: 0
Is there a way to silence [gemframebuffer]? Am I supposed to take a different approach? I'm not an expert but I guess this is not an isolated case, downsampling seems to be a common technique when working with textures for glsl use.
Best, Guido
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Hey thanks,
the problem here is that I need to "downsample" in real time. The framebuffer size is calculated on the amout of blur applied so that the more you blur, the faster is the effect. You can imagine what happens when I change the size for five or more [gemframebuffer] at once, the console gets literally flooded.
There are two more issues:
1. When linking multiple [gemframebuffer] and [pix_texture] with the texture id, the quality mode changes from the default GL_LINEAR to GL_NEAREST. Is this a bug? See this example patch, the right side stay completely harsh until you send a quality message -> http://www.mediafire.com/?qfe1q7d9vo84zlf
2. This is kind of hard to explain: the border of the framebuffer seems to get blended with the background when using GL_LINEAR on a following [pix_texture]. See the image -> http://img835.imageshack.us/img835/9083/gemborder.jpg
Thanks in advance.
Best, Guido
Il giorno 20/ott/11, alle ore 17:25, cyrille henry ha scritto:
hello, welcome,
You should create multiple framebuffer during initialisation. one for each size.
I think the main problem with changing framebuffer size is not only the message in the console, but also poor performances.
cheers Cyrille
Le 20/10/2011 11:03, Guido Tamino a écrit :
Hello everybody, I'm new to the list.
I'm working on a multipass glsl blur for Gem which needs downsampling for each pass. I managed to do that easily with a dimen message. It works fine, but [gemframebuffer] is flooding the console with "init" messages for every dimen change.
[gemframebuffer]: using rectmode 1:GL_TEXTURE_RECTANGLE [gemframebuffer]: using type: BYTE [gemframebuffer]: using color: RGB [gemframebuffer]: using texunit: 0
Is there a way to silence [gemframebuffer]? Am I supposed to take a different approach? I'm not an expert but I guess this is not an isolated case, downsampling seems to be a common technique when working with textures for glsl use.
Best, Guido
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hello,
Le 20/10/2011 19:26, Guido Tamino a écrit :
Hey thanks,
the problem here is that I need to "downsample" in real time. The framebuffer size is calculated on the amout of blur applied so that the more you blur, the faster is the effect. You can imagine what happens when I change the size for five or more [gemframebuffer] at once, the console gets literally flooded.
the flooded consol is really a minor effect of the fact that resizing frambuffer just destroy old framebuffer and recreate a new one. i don't know if openGL allow a more real time safe way to resize framebuffer.
There are two more issues:
- When linking multiple [gemframebuffer] and [pix_texture] with the texture id, the quality mode changes from the default GL_LINEAR to GL_NEAREST. Is this a bug? See this example patch, the right side stay completely harsh until you send a quality message -> http://www.mediafire.com/?qfe1q7d9vo84zlf
hum, things are strange here. the right side is not harsh when loading this patch on my computer. The left side is! sending quality 1 on the left side does affect the right side. so there is a problem. I think one has to investigate and report as bug. i don't know if i'll have time soon.
anyway, you still can send quality 1 everywhere...
- This is kind of hard to explain: the border of the framebuffer seems to get blended with the background when using GL_LINEAR on a following [pix_texture]. See the image -> http://img835.imageshack.us/img835/9083/gemborder.jpg
use "repeat 0" message in order not to interpolate with looped image.
Cyrille
Thanks in advance.
Best, Guido
Il giorno 20/ott/11, alle ore 17:25, cyrille henry ha scritto:
hello, welcome,
You should create multiple framebuffer during initialisation. one for each size.
I think the main problem with changing framebuffer size is not only the message in the console, but also poor performances.
cheers Cyrille
Le 20/10/2011 11:03, Guido Tamino a écrit :
Hello everybody, I'm new to the list.
I'm working on a multipass glsl blur for Gem which needs downsampling for each pass. I managed to do that easily with a dimen message. It works fine, but [gemframebuffer] is flooding the console with "init" messages for every dimen change.
[gemframebuffer]: using rectmode 1:GL_TEXTURE_RECTANGLE [gemframebuffer]: using type: BYTE [gemframebuffer]: using color: RGB [gemframebuffer]: using texunit: 0
Is there a way to silence [gemframebuffer]? Am I supposed to take a different approach? I'm not an expert but I guess this is not an isolated case, downsampling seems to be a common technique when working with textures for glsl use.
Best, Guido
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Hi Cyrille,
thanks for committing the [pix_texture] bug. Here is attached the fast blur patch I'm working on. The patch is commented and pretty self- explainatory, I wrote down a list of bugs to be figured out (like the quality and repeat thing). I'm getting some nice results on osx, don't know about other platforms. I guess there is a lot of redundant stuff that could be optimized, tips and feedback are welcome.
http://www.mediafire.com/?7e8pgg5dc5j1jqr
Best, Guido
hello Guido,
thanks for pointing the pix_texture bug. You should thanks Iohannes who correct it yesterday (I did not test it yet)
congratulation for your patch, result really look great.
about "bugs to be fixed" comment in this patch : 1 - should be fixed since yesterday thanks to Iohannes 2 - i don't think i have this problem on my computer. (i add a translate on the scene B in order to have the square cut by the edge of the windows, and the blur did not appear on the other side of the window.) see : http://chnry.free.fr/blur.png did i miss the problem, or did it work better on my computer than on your's? 3 - as i did mention earlier, the problem is not the console, but the fact that the framebuffer are destroy and created. i have no idea on how to improve this. (does anyone have an idea?) but there is a way to bypass this problem : you can render only in a part of the framebuffer. by example, you can multiply texture coordinate by 10, and render only on 1/10 of the frambuffer. ok, it's a hack, but it should not be to bad regarding performance.
you could also only simulate the downsampling of the image using a step fonction to read the texture, but this is certainly worst for performance.
i'll investigate point 2.
Cyrille
Le 25/10/2011 11:37, Guido Tamino a écrit :
Hi Cyrille,
thanks for committing the [pix_texture] bug. Here is attached the fast blur patch I'm working on. The patch is commented and pretty self-explainatory, I wrote down a list of bugs to be figured out (like the quality and repeat thing). I'm getting some nice results on osx, don't know about other platforms. I guess there is a lot of redundant stuff that could be optimized, tips and feedback are welcome.
http://www.mediafire.com/?7e8pgg5dc5j1jqr
Best, Guido
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-25 12:24, cyrille henry wrote:
about "bugs to be fixed" comment in this patch : 1 - should be fixed since yesterday thanks to Iohannes 2 - i don't think i have this problem on my computer. (i add a translate on the scene B in order to have the square cut by the edge of the windows, and the blur did not appear on the other side of the window.) see : http://chnry.free.fr/blur.png did i miss the problem, or did it work better on my computer than on your's?
as said, i couldn't see it either. then i played around a bit, and manged to produce this [1]. @guido: is that what you mean?
fgmasdr IOhannes
[1] http://iem.at/~zmoelnig/GEM/blur.png
Le 25/10/2011 12:31, IOhannes m zmoelnig a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-25 12:24, cyrille henry wrote:
about "bugs to be fixed" comment in this patch : 1 - should be fixed since yesterday thanks to Iohannes 2 - i don't think i have this problem on my computer. (i add a translate on the scene B in order to have the square cut by the edge of the windows, and the blur did not appear on the other side of the window.) see : http://chnry.free.fr/blur.png did i miss the problem, or did it work better on my computer than on your's?
as said, i couldn't see it either. then i played around a bit, and manged to produce this [1].
it look ok to me. at least, it look ok regarding to the way it is produced : you can't blur something that is not rendered... if you want this to be perfect, you have to compute the blur in a frambuffer bigger that the rendered window. c
@guido: is that what you mean?
fgmasdr IOhannes
[1] http://iem.at/~zmoelnig/GEM/blur.png -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6mkBQACgkQkX2Xpv6ydvToOwCgxuV4DoNpNqK/Wkwxbccc03aS dQYAn2B9wRRPP8CDvjWZJzQaJmRDLDpW =C9aK -----END PGP SIGNATURE-----
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Thanks for getting back to me so quickly.
@guido: is that what you mean? -> http://iem.at/~zmoelnig/GEM/blur.png
Not really, it looks like [gemframebuffer] has a weird black pixel border all around the edges. http://img717.imageshack.us/img717/8998/osxfastblur.jpg
This has something to do with osx, please see the patch attached. http://www.mediafire.com/?tw3jb9o0ac9fq6i
Best, Guido
hello Guido,
i investigated your patch and have a few comments.
- in "rectangle 1" mode, the repeat message is useless. this was confirmed yesterday by Iohannes, as an openGL limitation. - i don't have the same problem of black border. could you try using texture size of 512 better than 500 and tell us if it make a difference? - i have the same problem about the overlap from one side to the other. but it's not a 1 pixel bar, it's smaller. you can noticed when changing the size of the "square 3.9" that it can disappear. in fact, after investigation, i don't think this is a bug. imagine a 10 pixels size frambuffer. in rectangle mode, coordinate goes from 0 to 1. so 1st pixel coordinate goes from 0 to 0.1, 2nd pixel goes from 0.1 to 0.2 etc. so 1st pixel center is at 0.05 and 2nd pixel center is at 0.15 when rendering in gl_linear, you interpolate between pixels. so reading texture at position 0.05 gives exactly the color of the 1st pixel. but reading at 0.1 gives a mix between 1st and 2nd pixel. now, if you have to read at position 0.01, then, you also have to interpolate. between 1st pixel at position 0.05, and previous pixel. this previous pixel can be the same as the 1st one in "repeat 0" mode, or the same as the last pixel of the texture (position 0.95) in "repeat 1" mode.
So, if you have to interpolate the framebuffer texture when rendering, you may have small artefact on the border.
the key not to have this problem should be : - use "rectangle 0" mode. this works for me, but it look like your experiencing an other problem - in "rectangle 1" mode, do not interpolate the framebuffer image. This can be done in different way : - using "quality 0" mode - using the pixel size that fit the rendering size : if you render in a 500 x 500 window, then use a 500 x 500 framebuffer size to render on a "square 4". if you wish to render the image on a square 3.9, then the pixel size of this square should be 500 x 3.9 / 4 = 487.5 since you can't have half pixel, just use 487.5 x 2 = 975. you will not interpolate between pixels any-more...
hope that help Cyrille
Le 25/10/2011 15:46, Guido Tamino a écrit :
Thanks for getting back to me so quickly.
@guido: is that what you mean? -> http://iem.at/~zmoelnig/GEM/blur.png
Not really, it looks like [gemframebuffer] has a weird black pixel border all around the edges. http://img717.imageshack.us/img717/8998/osxfastblur.jpg
This has something to do with osx, please see the patch attached. http://www.mediafire.com/?tw3jb9o0ac9fq6i
Best, Guido
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
i forget an other solution not to have the problem with repeated texture. since you use shader, you can insert somthing like : texture_position.x = max(1./(2.xframebuffersize)); texture_position.x = min(1. - 1./(2.xframebuffersize)); ...
c
Le 26/10/2011 10:31, cyrille henry a écrit :
hello Guido,
i investigated your patch and have a few comments.
- in "rectangle 1" mode, the repeat message is useless. this was confirmed yesterday by Iohannes, as an openGL limitation.
- i don't have the same problem of black border. could you try using texture size of 512 better than 500 and tell us if it make a difference?
- i have the same problem about the overlap from one side to the other. but it's not a 1 pixel bar, it's smaller. you can noticed when changing the size of the "square 3.9" that it can disappear.
in fact, after investigation, i don't think this is a bug. imagine a 10 pixels size frambuffer. in rectangle mode, coordinate goes from 0 to 1. so 1st pixel coordinate goes from 0 to 0.1, 2nd pixel goes from 0.1 to 0.2 etc. so 1st pixel center is at 0.05 and 2nd pixel center is at 0.15 when rendering in gl_linear, you interpolate between pixels. so reading texture at position 0.05 gives exactly the color of the 1st pixel. but reading at 0.1 gives a mix between 1st and 2nd pixel. now, if you have to read at position 0.01, then, you also have to interpolate. between 1st pixel at position 0.05, and previous pixel. this previous pixel can be the same as the 1st one in "repeat 0" mode, or the same as the last pixel of the texture (position 0.95) in "repeat 1" mode.
So, if you have to interpolate the framebuffer texture when rendering, you may have small artefact on the border.
the key not to have this problem should be :
- use "rectangle 0" mode. this works for me, but it look like your experiencing an other problem
- in "rectangle 1" mode, do not interpolate the framebuffer image. This can be done in different way :
- using "quality 0" mode
- using the pixel size that fit the rendering size : if you render in a 500 x 500 window, then use a 500 x 500 framebuffer size to render on a "square 4". if you wish to render the image on a square 3.9, then the pixel size of this square should be 500 x 3.9 / 4 = 487.5
since you can't have half pixel, just use 487.5 x 2 = 975. you will not interpolate between pixels any-more...
hope that help Cyrille
Le 25/10/2011 15:46, Guido Tamino a écrit :
Thanks for getting back to me so quickly.
@guido: is that what you mean? -> http://iem.at/~zmoelnig/GEM/blur.png
Not really, it looks like [gemframebuffer] has a weird black pixel border all around the edges. http://img717.imageshack.us/img717/8998/osxfastblur.jpg
This has something to do with osx, please see the patch attached. http://www.mediafire.com/?tw3jb9o0ac9fq6i
Best, Guido
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Hi Cyrille,
imagine a 10 pixels size frambuffer. in rectangle mode, coordinate goes from 0 to 1. so 1st pixel coordinate goes from 0 to 0.1, 2nd pixel goes from 0.1 to 0.2 etc. so 1st pixel center is at 0.05 and 2nd pixel center is at 0.15 when rendering in gl_linear, you interpolate between pixels. so reading texture at position 0.05 gives exactly the color of the 1st pixel. but reading at 0.1 gives a mix between 1st and 2nd pixel. now, if you have to read at position 0.01, then, you also have to interpolate. between 1st pixel at position 0.05, and previous pixel. this previous pixel can be the same as the 1st one in "repeat 0" mode, or the same as the last pixel of the texture (position 0.95) in "repeat 1" mode.
this makes perfect sense, wonderful.
I think we are getting close to the osx issue. As you said before, the 0 and -0.5 position in a normalized texture (no rect) with no repeat should have the same color of the 1 position (the first pixel), but it doesn't. This is clearly visible if i change the texture coordinate, see the image. I guess this is causing the problem in the same way the pixel size not fitting the rendering size was causing the repeat artifact.
http://img256.imageshack.us/img256/9208/texturei.png
Thanks for your solutions but none of them is completely solving the problem. The framebuffer size can't be fixed as it is changing wildly while adjusting the blur amount, gl_nearest (quality 0) will bring weird artifacts and the glsl thing is pretty clever but feels like a workaround to me.
Best, Guido
Le 26/10/2011 12:08, Guido Tamino a écrit :
Hi Cyrille,
imagine a 10 pixels size frambuffer. in rectangle mode, coordinate goes from 0 to 1. so 1st pixel coordinate goes from 0 to 0.1, 2nd pixel goes from 0.1 to 0.2 etc. so 1st pixel center is at 0.05 and 2nd pixel center is at 0.15 when rendering in gl_linear, you interpolate between pixels. so reading texture at position 0.05 gives exactly the color of the 1st pixel. but reading at 0.1 gives a mix between 1st and 2nd pixel. now, if you have to read at position 0.01, then, you also have to interpolate. between 1st pixel at position 0.05, and previous pixel. this previous pixel can be the same as the 1st one in "repeat 0" mode, or the same as the last pixel of the texture (position 0.95) in "repeat 1" mode.
this makes perfect sense, wonderful.
I think we are getting close to the osx issue. As you said before, the 0 and -0.5 position in a normalized texture (no rect) with no repeat should have the same color of the 1 position (the first pixel), but it doesn't.
with no rectangle mode, things can be a bit weird since the GPu can put a 500x500 image size in a 512x512 memory size. coordinate are in pixel. so, coordinate 500 + 1 is 501, and it did not loop since memory size is 512. This is just a supposition. that why i ask you to make test with buffer size 512.
This is clearly visible if i change the texture coordinate, see the image. I guess this is causing the problem in the same way the pixel size not fitting the rendering size was causing the repeat artifact.
http://img256.imageshack.us/img256/9208/texturei.png
Thanks for your solutions but none of them is completely solving the problem.
the 3d one (on a separate mail), should solve you problem.
The framebuffer size can't be fixed as it is changing wildly while adjusting the blur amount,
yep, that one must also be solve. frambuffer size can't be change in realtime.
cyrille
gl_nearest (quality 0) will bring weird artifacts and the glsl thing is pretty clever but feels like a workaround to me.
Best, Guido
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Hi Cyrille,
setting the size to 512 is not working, I did try it but I forget to mention that in my previous e-mail.
How is this patch displaying on your computer? http://www.mediafire.com/?jw4w2qeajfcfo8w
Is it showing those darker areas around (which are not supposed to be there)? http://img256.imageshack.us/img256/9208/texturei.png
Best, Guido
with both rectangle 0 and 1, this patch does not show the darker areas on my computer. (i never remember what de default value is on linux and osX, but i know that i probably don't have the same default value than you).
could you please add a loadbang on "rectangle 0" (or 1) to this patch, and add a new bug on the bug tracker?
http://sourceforge.net/tracker/?atid=507079&group_id=64325&func=brow...
don't forget to include your example patch and the image.
thanks c
Le 26/10/2011 12:29, Guido Tamino a écrit :
Hi Cyrille,
setting the size to 512 is not working, I did try it but I forget to mention that in my previous e-mail.
How is this patch displaying on your computer? http://www.mediafire.com/?jw4w2qeajfcfo8w
Is it showing those darker areas around (which are not supposed to be there)? http://img256.imageshack.us/img256/9208/texturei.png
Best, Guido
hello Guido,
i'd like to solve the main problem of this algorithm. i'm trying to find a solution not to change the FB size. but i dont really understand everything yet. before i go deeper in the code, do you know if there is somewhere an explanation of the algorithm?
Thanks Cyrille
Le 26/10/2011 12:29, Guido Tamino a écrit :
Hi Cyrille,
setting the size to 512 is not working, I did try it but I forget to mention that in my previous e-mail.
How is this patch displaying on your computer? http://www.mediafire.com/?jw4w2qeajfcfo8w
Is it showing those darker areas around (which are not supposed to be there)? http://img256.imageshack.us/img256/9208/texturei.png
Best, Guido
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-25 12:24, cyrille henry wrote:
3 - as i did mention earlier, the problem is not the console, but the fact that the framebuffer are destroy and created.
i think guido rephrased the problem in the patch to "this means console flooding AND a loss in performance" (2 effects that are not depending on each other, but come from the same source); however, the heading "3 Console flooding" is still misleading.
fgmasdr IOhannes
Le 25/10/2011 12:34, IOhannes m zmoelnig a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-25 12:24, cyrille henry wrote:
3 - as i did mention earlier, the problem is not the console, but the fact that the framebuffer are destroy and created.
i think guido rephrased the problem in the patch to "this means console flooding AND a loss in performance" (2 effects that are not depending on each other, but come from the same source); however, the heading "3 Console flooding" is still misleading.
yes, i did not intended to say that guido did not read or understand my mail, i just wanted to say that i'm still armless regarding this problem. sorry for the confusion. c
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6mkJ8ACgkQkX2Xpv6ydvTUHgCgqU4w+2RkILdHva5TtQiQwPLE qOUAoIR/5NN+ZRTKTbocwU3Y8Y5jkqXw =NG1w -----END PGP SIGNATURE-----
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-25 11:37, Guido Tamino wrote:
Hi Cyrille,
thanks for committing the [pix_texture] bug. Here is attached the fast blur patch I'm working on. The patch is commented and pretty self-explainatory, I wrote down a list of bugs to be figured out (like the quality and repeat thing). I'm getting some nice results on osx,
i didn't see any problems with "repeat". the "quality" issue is fixed in git.
don't know about other platforms. I guess there is a lot of redundant stuff that could be optimized, tips and feedback are welcome.
make blurPass an abstraction (this makes it easier to switch to a Gem version where the "quality" issue is fixed)
fgamsdr IOhannes
investigating point 2, i noticed that "repeat 1" mode is not possible with "rectangle 1" texture mode. is that opengl limitation?
switching to rectangle 1 then to 0, will result in "repeat 0" mode, even if you switch it to 1 before. can anyone reproduce this? look like a bug for me.
c
Le 25/10/2011 11:37, Guido Tamino a écrit :
Hi Cyrille,
thanks for committing the [pix_texture] bug. Here is attached the fast blur patch I'm working on. The patch is commented and pretty self-explainatory, I wrote down a list of bugs to be figured out (like the quality and repeat thing). I'm getting some nice results on osx, don't know about other platforms. I guess there is a lot of redundant stuff that could be optimized, tips and feedback are welcome.
http://www.mediafire.com/?7e8pgg5dc5j1jqr
Best, Guido
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On Tue, Oct 25, 2011 at 12:43:47PM +0200, cyrille henry wrote:
investigating point 2, i noticed that "repeat 1" mode is not possible with "rectangle 1" texture mode. is that opengl limitation?
yes
switching to rectangle 1 then to 0, will result in "repeat 0" mode, even if you switch it to 1 before. can anyone reproduce this? look like a bug for me.
could be. i'll check
mgasdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/25/2011 02:06 PM, IOhannes m zmoelnig wrote:
On Tue, Oct 25, 2011 at 12:43:47PM +0200, cyrille henry wrote:
switching to rectangle 1 then to 0, will result in "repeat 0" mode, even if you switch it to 1 before. can anyone reproduce this? look like a bug for me.
could be. i'll check
should be fixed in git.
hello,
i'm not very familliar with git for now, i've just make a git fetch and a git rebase origin/master
after compilling, pd just crash when loading Gem.
c
Le 25/10/2011 15:35, IOhannes m zmölnig a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/25/2011 02:06 PM, IOhannes m zmoelnig wrote:
On Tue, Oct 25, 2011 at 12:43:47PM +0200, cyrille henry wrote:
switching to rectangle 1 then to 0, will result in "repeat 0" mode, even if you switch it to 1 before. can anyone reproduce this? look like a bug for me.
could be. i'll check
should be fixed in git. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6muzMACgkQkX2Xpv6ydvSVYACeJZ0P0Z+fXe5v03mNvQR/lzHx U24AnivNehMF2sor4ZtUAAPbQ9/1DXCY =rphJ -----END PGP SIGNATURE-----
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/25/2011 04:33 PM, cyrille henry wrote:
hello,
i'm not very familliar with git for now, i've just make a git fetch and a git rebase origin/master
usually a "git pull" should be sufficient
after compilling, pd just crash when loading Gem.
could you do a "make clean"? (it shouldn't be needed though)
could you do a backtrace?
fgamsdr IOhannes
hello, make clean did not change anthing. here is a gdb backtrace.
cyrille
chnry@chnry:~/pd/Gem$ gdb pd GNU gdb (GDB) 7.1-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/local/bin/pd...done. (gdb) run Starting program: /usr/local/bin/pd [Thread debugging using libthread_db enabled] [New Thread 0x7fffefd64700 (LWP 24842)] open: /etc/pd/gem.conf: No such file or directory open: /home/chnry/.pd/gem.conf: No such file or directory open: ./gem.conf: No such file or directory
Program received signal SIGSEGV, Segmentation fault. 0x00007ffff71d1f45 in __strcat_chk () from /lib/libc.so.6 (gdb) backtrace #0 0x00007ffff71d1f45 in __strcat_chk () from /lib/libc.so.6 #1 0x00007fffef2e6817 in strcat (this=<value optimized out>) at /usr/include/bits/string3.h:146 #2 GemSIMD (this=<value optimized out>) at SIMD.cpp:20 #3 0x00007fffef2b95f8 in GemMan::initGem () at Manager.cpp:247 #4 0x00000000004801ea in sys_do_load_lib (canvas=<value optimized out>, objectname=0x738ac0 "Gem") at s_loader.c:200 #5 0x000000000047fe41 in sys_load_lib (canvas=0x0, classname=0x738ac0 "Gem") at s_loader.c:239 #6 0x0000000000476783 in glob_initfromgui (dummy=<value optimized out>, s=<value optimized out>, argc=<value optimized out>, argv=0x7527d0) at s_main.c:241 #7 0x0000000000466901 in pd_typedmess (x=0x706118, s=<value optimized out>, argc=<value optimized out>, argv=0x7463657469686372) at m_class.c:681 #8 0x000000000046cada in binbuf_eval (x=<value optimized out>, target=0x706118, argc=<value optimized out>, argv=<value optimized out>) at m_binbuf.c:722 #9 0x000000000047b8b9 in socketreceiver_read (x=0x745820, fd=9) at s_inter.c:546 #10 0x000000000047b258 in sys_domicrosleep (microsec=<value optimized out>, pollem=<value optimized out>) at s_inter.c:184 #11 0x0000000000475885 in m_pollingscheduler () at m_sched.c:508 #12 m_mainloop () at m_sched.c:558 #13 0x000000000047a3b5 in sys_main (argc=<value optimized out>, argv=<value optimized out>) at s_main.c:313 #14 0x00007ffff70f3c4d in __libc_start_main () from /lib/libc.so.6 #15 0x0000000000412899 in _start ()
Le 25/10/2011 16:45, IOhannes m zmölnig a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/25/2011 04:33 PM, cyrille henry wrote:
hello,
i'm not very familliar with git for now, i've just make a git fetch and a git rebase origin/master
usually a "git pull" should be sufficient
after compilling, pd just crash when loading Gem.
could you do a "make clean"? (it shouldn't be needed though)
could you do a backtrace?
fgamsdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6my6QACgkQkX2Xpv6ydvTvEwCfTVxbIZuqVx4ic4NK8opB31Gf rGkAoLMUFm8nYmsqnXG92mmLTvQa6aLl =9yry -----END PGP SIGNATURE-----
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/25/2011 05:59 PM, cyrille henry wrote:
here is a gdb backtrace.
thanks.
Program received signal SIGSEGV, Segmentation fault. 0x00007ffff71d1f45 in __strcat_chk () from /lib/libc.so.6 (gdb) backtrace #0 0x00007ffff71d1f45 in __strcat_chk () from /lib/libc.so.6 #1 0x00007fffef2e6817 in strcat (this=<value optimized out>) at /usr/include/bits/string3.h:146 #2 GemSIMD (this=<value optimized out>) at SIMD.cpp:20 #3 0x00007fffef2b95f8 in GemMan::initGem () at Manager.cpp:247
aha. it seems the reason for this is the recent patch from hans that i added...should have done more checks.
fgmasdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/25/2011 06:15 PM, IOhannes m zmölnig wrote:
aha. it seems the reason for this is the recent patch from hans that i added...should have done more checks.
and hopefully fixed now.
fgmasdr IOhannes
_______________________________________________ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
sorry, i forget to reply to list.
so, latest git did not compile. i add 2 ";" in order to compile.
but this did not really solve my problem.
the backtrace did not change a lot.
cyrille
chnry@chnry:~/pd/Gem$ gdb pd GNU gdb (GDB) 7.1-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/local/bin/pd...done. (gdb) run Starting program: /usr/local/bin/pd [Thread debugging using libthread_db enabled] [New Thread 0x7fffefd64700 (LWP 5849)] open: /etc/pd/gem.conf: No such file or directory open: /home/chnry/.pd/gem.conf: No such file or directory open: ./gem.conf: No such file or directory
Program received signal SIGSEGV, Segmentation fault. 0x00007fffeeec7a53 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) () from /usr/lib/libstdc++.so.6 (gdb) backtrace #0 0x00007fffeeec7a53 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) () from /usr/lib/libstdc++.so.6 #1 0x00007fffef2e796e in GemSIMD (this=<value optimized out>) at SIMD.cpp:15 #2 0x00007fffef2ba5a8 in GemMan::initGem () at Manager.cpp:247 #3 0x00000000004801ea in sys_do_load_lib (canvas=<value optimized out>, objectname=0x738ac0 "Gem") at s_loader.c:200 #4 0x000000000047fe41 in sys_load_lib (canvas=0x0, classname=0x738ac0 "Gem") at s_loader.c:239 #5 0x0000000000476783 in glob_initfromgui (dummy=<value optimized out>, s=<value optimized out>, argc=<value optimized out>, argv=0x74c9f0) at s_main.c:241 #6 0x0000000000466901 in pd_typedmess (x=0x706118, s=<value optimized out>, argc=<value optimized out>, argv=0xb) at m_class.c:681 #7 0x000000000046cada in binbuf_eval (x=<value optimized out>, target=0x706118, argc=<value optimized out>, argv=<value optimized out>) at m_binbuf.c:722 #8 0x000000000047b8b9 in socketreceiver_read (x=0x745820, fd=9) at s_inter.c:546 #9 0x000000000047b258 in sys_domicrosleep (microsec=<value optimized out>, pollem=<value optimized out>) at s_inter.c:184 #10 0x0000000000475885 in m_pollingscheduler () at m_sched.c:508 #11 m_mainloop () at m_sched.c:558 #12 0x000000000047a3b5 in sys_main (argc=<value optimized out>, argv=<value optimized out>) at s_main.c:313 #13 0x00007ffff70f3c4d in __libc_start_main () from /lib/libc.so.6 #14 0x0000000000412899 in _start ()
Le 25/10/2011 18:26, IOhannes m zmölnig a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/25/2011 06:15 PM, IOhannes m zmölnig wrote:
aha. it seems the reason for this is the recent patch from hans that i added...should have done more checks.
and hopefully fixed now.
fgmasdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6m4zoACgkQkX2Xpv6ydvSEvgCeOyrFbHm16qAQU8cgk+39d78l 32IAoPRVHcm852VFL3vx+THHN+sV9JBz =nrnT -----END PGP SIGNATURE-----
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-25 19:00, cyrille henry wrote:
sorry, i forget to reply to list.
so, latest git did not compile. i add 2 ";" in order to compile.
doh! i had only MMX enabled when compiling, so i didn't catch it... should be fixed now.
but this did not really solve my problem.
hmm...
in this case i need more info about your system (architecture, configure flags, compiler flags,...)
msdf IOhannes
hello,
here is the end of a ./configure. is that enough?
thx Cyrille
Result: Target : Gem.pd_linux Objects :
Configuration: Compiler : g++ CXXFLAGS : -g -O2 -freg-struct-return -O3 -falign-loops -falign-functions -falign-jumps -funroll-loops -ffast-math -mmmx : -I/usr/include/lqt -fopenmp -I/usr/include/ImageMagick -I/usr/include/FTGL -I/usr/include/freetype2 -I/usr/include/avifile-0.7 -I/usr/include/lqt INCLUDES : DEFINES :
LIBS : -lXxf86vm -ldl -lz -lm : -lv4l2 -lv4l1 -ldv -lm -L/usr/lib -lquicktime -lpthread -lm -lz -ldl -lquicktime -lpthread -lm -lz -ldl -laviplay -lftgl -lMagick++ -lMagickCore LDFLAGS : :
Install path : /usr/local
pure-data: version : 0.42 extension : pd_linux
used optional libraries:
font-rendering : FTGL
image-support use ImageMagick : yes use TIFF : yes use JPEG : yes moviefile-support use PLUGINS : yes use mpeg : no use mpeg-3 : yes use QuickTime : yes use aviplay : yes use gmerlin : no capture-support use PLUGINS : yes use v4l : yes (libv4l) use v4l2 : yes (libv4l) use ieee1394 : no
Le 27/10/2011 09:30, IOhannes m zmoelnig a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-25 19:00, cyrille henry wrote:
sorry, i forget to reply to list.
so, latest git did not compile. i add 2 ";" in order to compile.
doh! i had only MMX enabled when compiling, so i didn't catch it... should be fixed now.
but this did not really solve my problem.
hmm...
in this case i need more info about your system (architecture, configure flags, compiler flags,...)
msdf IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6pCJgACgkQkX2Xpv6ydvTb7QCglLveaV68ec8gQ5LdtoncWxXq HlgAoOeFWJfNpLWpDhtFfrXjdzjHwRue =lNdf -----END PGP SIGNATURE-----
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hum, this did not tell that i use ubuntu 64 bit. c
Le 27/10/2011 11:54, cyrille henry a écrit :
hello,
here is the end of a ./configure. is that enough?
thx Cyrille
Result: Target : Gem.pd_linux Objects :
Configuration: Compiler : g++ CXXFLAGS : -g -O2 -freg-struct-return -O3 -falign-loops -falign-functions -falign-jumps -funroll-loops -ffast-math -mmmx : -I/usr/include/lqt -fopenmp -I/usr/include/ImageMagick -I/usr/include/FTGL -I/usr/include/freetype2 -I/usr/include/avifile-0.7 -I/usr/include/lqt INCLUDES : DEFINES :
LIBS : -lXxf86vm -ldl -lz -lm : -lv4l2 -lv4l1 -ldv -lm -L/usr/lib -lquicktime -lpthread -lm -lz -ldl -lquicktime -lpthread -lm -lz -ldl -laviplay -lftgl -lMagick++ -lMagickCore LDFLAGS : :
Install path : /usr/local
pure-data: version : 0.42 extension : pd_linux
used optional libraries:
font-rendering : FTGL
image-support use ImageMagick : yes use TIFF : yes use JPEG : yes moviefile-support use PLUGINS : yes use mpeg : no use mpeg-3 : yes use QuickTime : yes use aviplay : yes use gmerlin : no capture-support use PLUGINS : yes use v4l : yes (libv4l) use v4l2 : yes (libv4l) use ieee1394 : no
Le 27/10/2011 09:30, IOhannes m zmoelnig a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-25 19:00, cyrille henry wrote:
sorry, i forget to reply to list.
so, latest git did not compile. i add 2 ";" in order to compile.
doh! i had only MMX enabled when compiling, so i didn't catch it... should be fixed now.
but this did not really solve my problem.
hmm...
in this case i need more info about your system (architecture, configure flags, compiler flags,...)
msdf IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6pCJgACgkQkX2Xpv6ydvTb7QCglLveaV68ec8gQ5LdtoncWxXq HlgAoOeFWJfNpLWpDhtFfrXjdzjHwRue =lNdf -----END PGP SIGNATURE-----
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-27 20:44, cyrille henry wrote:
hum, this did not tell that i use ubuntu 64 bit.
indeed, it did not tell that.
i tried to compile/run Gem on a 64bit debian installation, and indeed it crashes!
please report a bug.
fgvamnsdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-31 11:32, IOhannes m zmoelnig wrote:
On 2011-10-27 20:44, cyrille henry wrote:
hum, this did not tell that i use ubuntu 64 bit.
indeed, it did not tell that.
i tried to compile/run Gem on a 64bit debian installation, and indeed it crashes!
i think the problem is the CPU capabilities detection code (which tries to determine whether your CPU is capable of running e.g. SSE2 code)
given that any x86_64 CPU on the market supports SSE2 (and SSE and MMX), i disabled that check on this architecture for now.
at least, this fixed the problem here.
fgamsdr IOhannes
hello,
it look like working here also. thanks
sorry for the delay, i don't have electricity all day here. c
Le 31/10/2011 12:40, IOhannes m zmoelnig a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-31 11:32, IOhannes m zmoelnig wrote:
On 2011-10-27 20:44, cyrille henry wrote:
hum, this did not tell that i use ubuntu 64 bit.
indeed, it did not tell that.
i tried to compile/run Gem on a 64bit debian installation, and indeed it crashes!
i think the problem is the CPU capabilities detection code (which tries to determine whether your CPU is capable of running e.g. SSE2 code)
given that any x86_64 CPU on the market supports SSE2 (and SSE and MMX), i disabled that check on this architecture for now.
at least, this fixed the problem here.
fgamsdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6ulzgACgkQkX2Xpv6ydvThoQCeNQ2nYCidjNKNWUnTpX+CKOHW +ZoAoIZm3YzyPC3JBliOMiulT3L/YKF0 =DMUL -----END PGP SIGNATURE-----
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-
cyrille henry -
Guido Tamino -
IOhannes m zmoelnig -
IOhannes m zmölnig