Subject: Re: [PD] GEM on PIII memory problem?
To: pd-list@iem.at Message-ID: 4F1442F1.70606@iem.at Content-Type: text/plain; charset="iso-8859-15"
-----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?
the PIII has onboard video
could it be a dupe of [1]?
not as far as i can see. (i use fresh copies) i suspect [1] has something to do with using the pd open or close 'message' with a non-existing file.
or what does "every time at a change in the rendering" mean exactly?
every time the content of the GEM-window should change
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)
it's not clear to me how to use this object, there's no help. connecting the inlet with a loadbang causes Pd/GEM to quit immediately. leaving the object by itself, with a print on the first outlet, gives nothing.
i tried to use more then 16 k for the VideoRam: this also causes Pd/GEM to quit at rendering the first picture.
just now i found in the system message.log after the crash: pdextended[1702]: segfault at 0 ip (null) sp bfcc1acc error 4 in libpulse.so.0.12.2[110000+40000]
doing it again:
pdextended[2045]: segfault at 0 ip (null) sp bfb87f3c error 4 in libasound.so.2.0.0[110000+c3000]
going back to the default VideoRam (= no changes made by me)
pdextended[1431]: segfault at 0 ip (null) sp bfe1aecc error 4 in libICE.so.6.3.0[110000+15000]
should i make a bug report on this? (i'm on Pd-ext 42.5 with GEM 92.3)
rolf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-01-16 18:06, rolf meesters wrote:
Subject: Re: [PD] GEM on PIII memory problem?
is that with the intel gfx card?
the PIII has onboard video
which is?
could it be a dupe of [1]?
not as far as i can see. (i use fresh copies)
you are using a recent git checkout of Gem?
i suspect [1] has something to do with using the pd open or close 'message' with a non-existing file.
oh indeed. that was the wrong bug report i mentioned. i wanted to refer to #3471122 ("GL: invalid enum" in each frame); but if you are using a recent version this should not be the problem....
or what does "every time at a change in the rendering" mean exactly?
every time the content of the GEM-window should change
i assume that you mean, whenever you rotate/translate/scale/... an object in the scene? there are so many ways you can make he GEM-window change. to name a few:
- whenever you "destroy, create" a gemwin
- whenever you change global ligthing
- whenever you move things in the 3d scene
- whenever someone moves in front of the camera that is captured and
applied as a texture
- ....
those changes are very different and might hint at different problems. no doubt it is very clear to you what you mean by "the content should change"; however, it is not so clear to me, that's why i keep asking.
if you can provide a minimal patch that triggers the problem, this might greatly improve my understanding.
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)
it's not clear to me how to use this object, there's no help. connecting the inlet with a loadbang causes Pd/GEM to quit immediately. leaving the object by itself, with a print on the first outlet, gives nothing.
right, sorry for that. [GEMglReportError] should be part of the render-chain.
here's an example:
[gemhead]
|
[GEMglReportError]->[nbx
|
[weirdobject]
|
[GEMglReportError]->[nbx\
where you suspect that [weirdobject] is the cause of the problem. if this is true, every time [weirdobject] does something stupid (in openGL world), the lower [GEMglReportError] will send a non-null error code to it's right outlet. the other (upper) [GEMglReportError] is needed to clear any previous error (in case you have multiple objects doing stupid things)
if things are very weird, you might even use something like
[gemhead] | [t a a a] | | | [GEMglReportError] | [GEMglReportError] | [weirdobject] | [GEMglReportError]
should i make a bug report on this? (i'm on Pd-ext 42.5 with GEM 92.3)
ahem, so which version of gem are you actually using? the current stable release is 0.93.3, and i was under the impression that you were using a "fresh copy" of Gem.
fgmasdr IOhannes
-
IOhannes m zmoelnig -
rolf meesters