hi i have an installation with a number of PIII machines, where some picture manipulation (2D) is done, working nicely on Win-XP and Flash 8 (in 256 Mb).
now i'm trying to change from Flash to GEM. the patch i made works perfect on a P4.
the PIII's don't have SSE2; therefore i rebuild Pd-ext 42.5 for Linux - (Ubuntu Lucid). however running the patch on the PIII still looks like impossible. Pd/GEM just calls it quits, no message.
a basic picture consists of 16 pieces of 800 x 533 pixels, together forming one of 3200 x 2133.
to create a full picture resized to 800 x 533 on a normal display, i have 16 identical abstractions, for each piece one, with a gemhead, a pix_texture, a resize, etc.
with 8 abstractions/pieces Pd/GEM stays alive, 9 is one too many. memory problem?
using the Ubuntu system monitor: bare system (with the monitor) ~290 Mb usage. (of 496MB) starting Pdx console ~300-310 Mb. loading/running the patch ~335-355 MB.
??
on the opening of the patch GEM anounces 8 bits will be used, where the onboard video-card has 24bits.
any help is appreciated.
rolf
Are you sure that Gem also was compiled without SSE2 support? If you built the whole package with the Pd-extended build system, it wouldn't change the Gem build system's setup. That would have to be done in addition to changing the settings in packages/linux_make/Makefile. I think you'd need to edit the Gem ./configure flags in packages/Makefile.
.hc
On Jan 14, 2012, at 1:59 PM, rolf meesters wrote:
hi i have an installation with a number of PIII machines, where some picture manipulation (2D) is done, working nicely on Win-XP and Flash 8 (in 256 Mb).
now i'm trying to change from Flash to GEM. the patch i made works perfect on a P4.
the PIII's don't have SSE2; therefore i rebuild Pd-ext 42.5 for Linux - (Ubuntu Lucid). however running the patch on the PIII still looks like impossible. Pd/GEM just calls it quits, no message.
a basic picture consists of 16 pieces of 800 x 533 pixels, together forming one of 3200 x 2133.
to create a full picture resized to 800 x 533 on a normal display, i have 16 identical abstractions, for each piece one, with a gemhead, a pix_texture, a resize, etc.
with 8 abstractions/pieces Pd/GEM stays alive, 9 is one too many. memory problem?
using the Ubuntu system monitor: bare system (with the monitor) ~290 Mb usage. (of 496MB) starting Pdx console ~300-310 Mb. loading/running the patch ~335-355 MB.
??
on the opening of the patch GEM anounces 8 bits will be used, where the onboard video-card has 24bits.
any help is appreciated.
rolf _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
kill your television
opening the Pd gui it says: GEM compiled for SIMD architecture: MMX GEM using MMX optimization
no mentioning of SSE2, what is seen in the regular version
rolf
On Sun, Jan 15, 2012 at 3:49 AM, Hans-Christoph Steiner hans@at.or.atwrote:
Are you sure that Gem also was compiled without SSE2 support? If you built the whole package with the Pd-extended build system, it wouldn't change the Gem build system's setup. That would have to be done in addition to changing the settings in packages/linux_make/Makefile. I think you'd need to edit the Gem ./configure flags in packages/Makefile.
.hc
On Jan 14, 2012, at 1:59 PM, rolf meesters wrote:
hi i have an installation with a number of PIII machines, where some
picture manipulation (2D) is done,
working nicely on Win-XP and Flash 8 (in 256 Mb).
now i'm trying to change from Flash to GEM. the patch i made works perfect on a P4.
the PIII's don't have SSE2; therefore i rebuild Pd-ext 42.5 for Linux -
(Ubuntu Lucid).
however running the patch on the PIII still looks like impossible. Pd/GEM just calls it quits, no message.
a basic picture consists of 16 pieces of 800 x 533 pixels, together
forming one of 3200 x 2133.
to create a full picture resized to 800 x 533 on a normal display, i have 16 identical abstractions, for each piece one, with a gemhead, a pix_texture, a resize, etc.
with 8 abstractions/pieces Pd/GEM stays alive, 9 is one too many. memory problem?
using the Ubuntu system monitor: bare system (with the monitor) ~290 Mb usage. (of 496MB) starting Pdx console ~300-310 Mb. loading/running the patch ~335-355 MB.
??
on the opening of the patch GEM anounces 8 bits will be used, where the onboard video-card has 24bits.
any help is appreciated.
rolf _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
kill your television
Le 14/01/2012 19:59, rolf meesters a écrit :
hi i have an installation with a number of PIII machines, where some picture manipulation (2D) is done, working nicely on Win-XP and Flash 8 (in 256 Mb).
now i'm trying to change from Flash to GEM. the patch i made works perfect on a P4.
the PIII's don't have SSE2; therefore i rebuild Pd-ext 42.5 for Linux - (Ubuntu Lucid). however running the patch on the PIII still looks like impossible. Pd/GEM just calls it quits, no message.
a basic picture consists of 16 pieces of 800 x 533 pixels, together forming one of 3200 x 2133.
to create a full picture resized to 800 x 533 on a normal display, i have 16 identical abstractions, for each piece one, with a gemhead, a pix_texture, a resize, etc.
with 8 abstractions/pieces Pd/GEM stays alive, 9 is one too many. memory problem?
yes, certainly GPU memory limitation. in case of share memory between CPU and GPU, can you increase the size the the memory allocated to the GPU (in the computer BIOS)?
Cyrille
using the Ubuntu system monitor: bare system (with the monitor) ~290 Mb usage. (of 496MB) starting Pdx console ~300-310 Mb. loading/running the patch ~335-355 MB.
??
on the opening of the patch GEM anounces 8 bits will be used, where the onboard video-card has 24bits.
any help is appreciated.
rolf
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, Jan 15, 2012 at 12:57 PM, Cyrille Henry ch@chnry.net wrote:
Le 14/01/2012 19:59, rolf meesters a écrit :
hi
i have an installation with a number of PIII machines, where some picture manipulation (2D) is done, working nicely on Win-XP and Flash 8 (in 256 Mb).
now i'm trying to change from Flash to GEM. the patch i made works perfect on a P4.
the PIII's don't have SSE2; therefore i rebuild Pd-ext 42.5 for Linux - (Ubuntu Lucid). however running the patch on the PIII still looks like impossible. Pd/GEM just calls it quits, no message.
a basic picture consists of 16 pieces of 800 x 533 pixels, together forming one of 3200 x 2133.
to create a full picture resized to 800 x 533 on a normal display, i have 16 identical abstractions, for each piece one, with a gemhead, a pix_texture, a resize, etc.
with 8 abstractions/pieces Pd/GEM stays alive, 9 is one too many. memory problem?
yes, certainly GPU memory limitation. in case of share memory between CPU and GPU, can you increase the size the the memory allocated to the GPU (in the computer BIOS)?
Cyrille
it's at the max of 64 Mb.
using the Ubuntu system monitor: bare system (with the monitor) ~290 Mb usage. (of 496MB) starting Pdx console ~300-310 Mb. loading/running the patch ~335-355 MB.
??
on the opening of the patch GEM anounces 8 bits will be used, where the onboard video-card has 24bits.
any help is appreciated.
rolf
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Le 15/01/2012 18:13, rolf meesters a écrit :
it's at the max of 64 Mb.
do you have 16 pix_image? if you load 16 time the same image, you need 16 time more memory than necessary.
then, you could use a single gemhead / pix_image / pix_texture to load the image and share the texture Id. then using gemhead/pix_texture(to load the texture Id)/pix_coordinate on your abstraction.
also, you can only resize the image in order to fit in the available GPU memory.
anyway, pd/GEM should not exit without warning. pd bug report should be made.
Cyrille
On Sun, Jan 15, 2012 at 10:47 PM, Cyrille Henry ch@chnry.net wrote:
Le 15/01/2012 18:13, rolf meesters a écrit :
it's at the max of 64 Mb.
do you have 16 pix_image? if you load 16 time the same image, you need 16 time more memory than necessary.
then, you could use a single gemhead / pix_image / pix_texture to load the image and share the texture Id. then using gemhead/pix_texture(to load the texture Id)/pix_coordinate on your abstraction.
also, you can only resize the image in order to fit in the available GPU memory.
anyway, pd/GEM should not exit without warning. pd bug report should be made.
Cyrille
i have 16 pieces, which are parts of 1 big picture; like with a puzzle they have to be displayed at their specific coordinates. there's no pix_image involved. (the abstraction is attached)
rolf btw thanks for reacting
Le 16/01/2012 13:23, rolf meesters a écrit :
On Sun, Jan 15, 2012 at 10:47 PM, Cyrille Henry <ch@chnry.net mailto:ch@chnry.net> wrote:
Le 15/01/2012 18:13, rolf meesters a écrit : it's at the max of 64 Mb. do you have 16 pix_image? if you load 16 time the same image, you need 16 time more memory than necessary. then, you could use a single gemhead / pix_image / pix_texture to load the image and share the texture Id. then using gemhead/pix_texture(to load the texture Id)/pix_coordinate on your abstraction. also, you can only resize the image in order to fit in the available GPU memory. anyway, pd/GEM should not exit without warning. pd bug report should be made. Cyrillei have 16 pieces, which are parts of 1 big picture; like with a puzzle they have to be displayed at their specific coordinates. there's no pix_image involved. (the abstraction is attached)
ah, ok. you're using a pix_buffer. good, the image is not loaded many time.
so the only solution i can imagine is to resize the image in order to use less memory. c
rolf btw thanks for reacting
On Mon, Jan 16, 2012 at 1:29 PM, Cyrille Henry ch@chnry.net wrote:
Le 16/01/2012 13:23, rolf meesters a écrit :
On Sun, Jan 15, 2012 at 10:47 PM, Cyrille Henry <ch@chnry.net mailto: ch@chnry.net> wrote:
Le 15/01/2012 18:13, rolf meesters a écrit :
it's at the max of 64 Mb.do you have 16 pix_image? if you load 16 time the same image, you need 16 time more memory than necessary.
then, you could use a single gemhead / pix_image / pix_texture to load the image and share the texture Id. then using gemhead/pix_texture(to load the texture Id)/pix_coordinate on your abstraction.
also, you can only resize the image in order to fit in the available GPU memory.
anyway, pd/GEM should not exit without warning. pd bug report should be made.
Cyrille
i have 16 pieces, which are parts of 1 big picture; like with a puzzle they have to be displayed at their specific coordinates. there's no pix_image involved. (the abstraction is attached)
ah, ok. you're using a pix_buffer. good, the image is not loaded many time.
so the only solution i can imagine is to resize the image in order to use less memory.
c
a bit of progress:
for the intel815 (which i have on the PIII) it is possible to set a value for VideoRam in xorg.conf. i made it 16384 kb: now Pd/GEM does not quit. the patch goes through the motions, there's a GEM-window, but only a white rectangle where a picture should be.
GEM tells me that direct rendering is enabled, but still only 8 clor bits.
and now every time at a change in the rendering: GL: invalid operation
r
rolf btw thanks for reacting
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-01-16 15:51, rolf meesters wrote:
and now every time at a change in the rendering: GL: invalid operation
is that with the intel gfx card? could it be a dupe of [1]? or what does "every time at a change in the rendering" mean exactly?
try to find the object that actually causes the error. you can use a [GEMglReportError] that will output a warning if an error was raised since the last time any instance of [GEMglReportError] was called (the error state is also reset inside [gemwin] during each render-cycle..which is what causes the message to appear)
fgmar IOhannes
[1] https://sourceforge.net/tracker/?func=detail&aid=3472490&group_id=55...
-
Cyrille Henry -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
rolf meesters