Gem crashes after relaunching with error: i965: Failed to submit batchbuffer: Invalid argument
Dear list,
did anyone meet this OpenGL bug on ununtu 18.04? When recreating gemwin (destroy, create) Pd crashes with this error: i965: Failed to submit batchbuffer: Invalid argument
Best, Popesz
I've been guilty of this before, but you must say which Pd and foremost which Gem version. If you use the one grom the debian repository, try compiling from the github repository. It solved a bug where Pd froze on closing a gemwin.
On 01.10.2018 16:46, Csaba Láng wrote:
Dear list,
did anyone meet this OpenGL bug on ununtu 18.04? When recreating gemwin (destroy, create) Pd crashes with this error: i965: Failed to submit batchbuffer: Invalid argument
Best, Popesz
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 10/1/18 5:19 PM, Max wrote:
I've been guilty of this before, but you must say which Pd and foremost which Gem version.
+1
apart from that: i've seen this every now and then, and have never been able to find the actual root of the problem.
in practice, i find this only annoying while developing a patch (during performance/show/... you hopefully won't need to re-create the Gem window)
fgmasdr IOhannes
Indeed, annoying it is during developing the patch, however had a feeling that maybe Gem makes my metro work slower exactly 3 times, one second lasts 3 seconds in real time. But will never get the answer. Do you think a better fxcard than the integrated one can solve the problem? it is in no correlating with the source of the bug. Popesz
On Mon, Oct 1, 2018 at 6:01 PM IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 10/1/18 5:19 PM, Max wrote:
I've been guilty of this before, but you must say which Pd and foremost which Gem version.
+1
apart from that: i've seen this every now and then, and have never been able to find the actual root of the problem.
in practice, i find this only annoying while developing a patch (during performance/show/... you hopefully won't need to re-create the Gem window)
fgmasdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 10/1/18 6:30 PM, Csaba Láng wrote:
Indeed, annoying it is during developing the patch, however had a feeling that maybe Gem makes my metro work slower exactly 3 times, one second lasts 3 seconds in real time.
i'm a bit confused now: in your last thread you stated that the metro was exactly 3 times faster (that is a [metro 1000] running a 333ms; now a [metro 1000] is running at 3000ms). while a slower/faster metro is entirely possible and te two problems might be unrelated, i wonder why exactly the same factor "3" occurs in both issues. could it be that the problem is somewhere else (e.g. a simple patch error?)
at which framerate is your Gem-patch running? at which framerate is your monitor running?
it is in no correlating with the source of the bug.
afaict, this is unrelated to the crasher bug you are describing.
But will never get the answer.
i'm not sur what you mean by this.
fgmsard IOhannes
yes you are right, once it was 3 times slower, once it was 3 times faster. Gem is on default framerate, I guess you mentioned it is 20fps. Monitor is on 60Hz. There is a ratio of 1:3 indeed but I hope it has nothing to do with metro.
On Mon, Oct 1, 2018 at 8:43 PM IOhannes m zmölnig zmoelnig@iem.at wrote:
On 10/1/18 6:30 PM, Csaba Láng wrote:
Indeed, annoying it is during developing the patch, however had a feeling that maybe Gem makes my metro work slower exactly 3 times, one second
lasts
3 seconds in real time.
i'm a bit confused now: in your last thread you stated that the metro was exactly 3 times faster (that is a [metro 1000] running a 333ms; now a [metro 1000] is running at 3000ms). while a slower/faster metro is entirely possible and te two problems might be unrelated, i wonder why exactly the same factor "3" occurs in both issues. could it be that the problem is somewhere else (e.g. a simple patch error?)
at which framerate is your Gem-patch running? at which framerate is your monitor running?
it is in no correlating with the source of the bug.
afaict, this is unrelated to the crasher bug you are describing.
But will never get the answer.
i'm not sur what you mean by this.
fgmsard IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
to correct my previous statement, when I wrote metro is slower 3 times I was wrong, it is not 3000ms but 3333ms but it is due to my last project where I used 200fps for the Pylon high speed cameras. now everything seems to make sense: when I used those USB3 cameras with the correct 200fps, this metro phenomenon did not occur, until I changed the cameras to webcams keeping accidentally the 200fps. when turned it off Gem went back to 20fps. Thanks for solving this mysterious case :)
On Mon, Oct 1, 2018 at 8:50 PM Csaba Láng langcsaba@gmail.com wrote:
yes you are right, once it was 3 times slower, once it was 3 times faster. Gem is on default framerate, I guess you mentioned it is 20fps. Monitor is on 60Hz. There is a ratio of 1:3 indeed but I hope it has nothing to do with metro.
On Mon, Oct 1, 2018 at 8:43 PM IOhannes m zmölnig zmoelnig@iem.at wrote:
On 10/1/18 6:30 PM, Csaba Láng wrote:
Indeed, annoying it is during developing the patch, however had a
feeling
that maybe Gem makes my metro work slower exactly 3 times, one second
lasts
3 seconds in real time.
i'm a bit confused now: in your last thread you stated that the metro was exactly 3 times faster (that is a [metro 1000] running a 333ms; now a [metro 1000] is running at 3000ms). while a slower/faster metro is entirely possible and te two problems might be unrelated, i wonder why exactly the same factor "3" occurs in both issues. could it be that the problem is somewhere else (e.g. a simple patch error?)
at which framerate is your Gem-patch running? at which framerate is your monitor running?
it is in no correlating with the source of the bug.
afaict, this is unrelated to the crasher bug you are describing.
But will never get the answer.
i'm not sur what you mean by this.
fgmsard IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi,
I have the same issue. I tried 3 machines with ubuntu 18.04.1 with a self-compiled Pd 0.49.0 and Gem 0.93. cloned from git. One machine has an Nvidia Geforce GTX 660 Ti and it has no problems. The other 2 machines have an Intel integrated graphics controller and they crashed after recreating gemwin only when the text3d is used. With text2d there's no problem, same with other gem objects. pd -verbose -lib Gem: i965: Failed to submit batchbuffer: No such file or directory
Best, A.
On Mon, 1 Oct 2018 at 22:38, Csaba Láng langcsaba@gmail.com wrote:
to correct my previous statement, when I wrote metro is slower 3 times I was wrong, it is not 3000ms but 3333ms but it is due to my last project where I used 200fps for the Pylon high speed cameras. now everything seems to make sense: when I used those USB3 cameras with the correct 200fps, this metro phenomenon did not occur, until I changed the cameras to webcams keeping accidentally the 200fps. when turned it off Gem went back to 20fps. Thanks for solving this mysterious case :)
On Mon, Oct 1, 2018 at 8:50 PM Csaba Láng langcsaba@gmail.com wrote:
yes you are right, once it was 3 times slower, once it was 3 times faster. Gem is on default framerate, I guess you mentioned it is 20fps. Monitor is on 60Hz. There is a ratio of 1:3 indeed but I hope it has nothing to do with metro.
On Mon, Oct 1, 2018 at 8:43 PM IOhannes m zmölnig zmoelnig@iem.at wrote:
On 10/1/18 6:30 PM, Csaba Láng wrote:
Indeed, annoying it is during developing the patch, however had a
feeling
that maybe Gem makes my metro work slower exactly 3 times, one second
lasts
3 seconds in real time.
i'm a bit confused now: in your last thread you stated that the metro was exactly 3 times faster (that is a [metro 1000] running a 333ms; now a [metro 1000] is running at 3000ms). while a slower/faster metro is entirely possible and te two problems might be unrelated, i wonder why exactly the same factor "3" occurs in both issues. could it be that the problem is somewhere else (e.g. a simple patch error?)
at which framerate is your Gem-patch running? at which framerate is your monitor running?
it is in no correlating with the source of the bug.
afaict, this is unrelated to the crasher bug you are describing.
But will never get the answer.
i'm not sur what you mean by this.
fgmsard IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
me too: https://github.com/umlaeute/Gem/issues/191
On 30.11.18 05:42, andre rc wrote:
Hi,
I have the same issue. I tried 3 machines with ubuntu 18.04.1 with a self-compiled Pd 0.49.0 and Gem 0.93. cloned from git. One machine has an Nvidia Geforce GTX 660 Ti and it has no problems. The other 2 machines have an Intel integrated graphics controller and they crashed after recreating gemwin only when the text3d is used. With text2d there's no problem, same with other gem objects. pd -verbose -lib Gem: i965: Failed to submit batchbuffer: No such file or directory
Best, A.
On Mon, 1 Oct 2018 at 22:38, Csaba Láng <langcsaba@gmail.com mailto:langcsaba@gmail.com> wrote:
to correct my previous statement, when I wrote metro is slower 3 times I was wrong, it is not 3000ms but 3333ms but it is due to my last project where I used 200fps for the Pylon high speed cameras. now everything seems to make sense: when I used those USB3 cameras with the correct 200fps, this metro phenomenon did not occur, until I changed the cameras to webcams keeping accidentally the 200fps. when turned it off Gem went back to 20fps. Thanks for solving this mysterious case :) On Mon, Oct 1, 2018 at 8:50 PM Csaba Láng <langcsaba@gmail.com <mailto:langcsaba@gmail.com>> wrote: yes you are right, once it was 3 times slower, once it was 3 times faster. Gem is on default framerate, I guess you mentioned it is 20fps. Monitor is on 60Hz. There is a ratio of 1:3 indeed but I hope it has nothing to do with metro. On Mon, Oct 1, 2018 at 8:43 PM IOhannes m zmölnig <zmoelnig@iem.at <mailto:zmoelnig@iem.at>> wrote: On 10/1/18 6:30 PM, Csaba Láng wrote: > Indeed, annoying it is during developing the patch, however had a feeling > that maybe Gem makes my metro work slower exactly 3 times, one second lasts > 3 seconds in real time. i'm a bit confused now: in your last thread you stated that the metro was exactly 3 times faster (that is a [metro 1000] running a 333ms; now a [metro 1000] is running at 3000ms). while a slower/faster metro is entirely possible and te two problems might be unrelated, i wonder why exactly the same factor "3" occurs in both issues. could it be that the problem is somewhere else (e.g. a simple patch error?) at which framerate is your Gem-patch running? at which framerate is your monitor running? > it is in no correlating with the source of the bug. afaict, this is unrelated to the crasher bug you are describing. > But will never get the answer. i'm not sur what you mean by this. fgmsard IOhannes _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
hallo,
the problem with intel grafic cards could be fixed with the enviroment variable:
LIBGL_ALWAYS_SOFTWARE=1 pd patch.pd
best, alexander
On 30.11.18 05:42, andre rc wrote:
Hi,
I have the same issue. I tried 3 machines with ubuntu 18.04.1 with a self-compiled Pd 0.49.0 and Gem 0.93. cloned from git. One machine has an Nvidia Geforce GTX 660 Ti and it has no problems. The other 2 machines have an Intel integrated graphics controller and they crashed after recreating gemwin only when the text3d is used. With text2d there's no problem, same with other gem objects. pd -verbose -lib Gem: i965: Failed to submit batchbuffer: No such file or directory
Best, A.
Hi Alex,
Thank you for the info!. Where should I put this environment variable? I searched in the ./configuration --help, but nothing... (sorry but I'm very new on this)
Best, A.
On Fri, 30 Nov 2018 at 11:43, alex tuca atuc@gmx.de wrote:
hallo,
the problem with intel grafic cards could be fixed with the enviroment variable:
LIBGL_ALWAYS_SOFTWARE=1 pd patch.pd
best, alexander
On 30.11.18 05:42, andre rc wrote:
Hi,
I have the same issue. I tried 3 machines with ubuntu 18.04.1 with a
self-compiled Pd 0.49.0 and Gem 0.93. cloned from git.
One machine has an Nvidia Geforce GTX 660 Ti and it has no problems. The
other 2 machines have an Intel integrated graphics controller and they crashed after recreating gemwin only when the text3d is used. With text2d there's no problem, same with other gem objects.
pd -verbose -lib Gem: i965: Failed to submit batchbuffer: No such file or directory
Best, A.
On 11/30/18 1:36 PM, andre rc wrote:
Hi Alex,
Thank you for the info!. Where should I put this environment variable?
this is an envvar that is only honored at runtime (also Gem doesn't know anything about it. it really only has an effect on the underlying openGL implementation (or not, depending on which openGL implementation you are using).
but alex already gave you quite specific instructions:
LIBGL_ALWAYS_SOFTWARE=1 pd patch.pd
this is the actual command-line you should run to open "patch.pd" with the fix.
gfmrd IOhannes
This is great! Thanks for the explanation, Alex & IOhannes. I tried this on 3 machines with Intel integrated. All of them were able to recreate gemwin. But now, if I close the patch after recreating gemwin, pd crashes. LIBGL_ALWAYS_SOFTWARE=1 pd -verbose -lib Gem: Pd signal 6 This doesn't happen if I destroy gemwin before closing. Best, A.
On Fri, 30 Nov 2018 at 20:07, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 11/30/18 1:36 PM, andre rc wrote:
Hi Alex,
Thank you for the info!. Where should I put this environment variable?
this is an envvar that is only honored at runtime (also Gem doesn't know anything about it. it really only has an effect on the underlying openGL implementation (or not, depending on which openGL implementation you are using).
but alex already gave you quite specific instructions:
LIBGL_ALWAYS_SOFTWARE=1 pd patch.pd
this is the actual command-line you should run to open "patch.pd" with the fix.
gfmrd IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I'd expect 3d performance to tank when forcing software rendering.
On 30.11.18 11:43, alex tuca wrote:
hallo,
the problem with intel grafic cards could be fixed with the enviroment variable:
LIBGL_ALWAYS_SOFTWARE=1 pd patch.pd
best, alexander
On 30.11.18 05:42, andre rc wrote:
Hi,
I have the same issue. I tried 3 machines with ubuntu 18.04.1 with a self-compiled Pd 0.49.0 and Gem 0.93. cloned from git. One machine has an Nvidia Geforce GTX 660 Ti and it has no problems. The other 2 machines have an Intel integrated graphics controller and they crashed after recreating gemwin only when the text3d is used. With text2d there's no problem, same with other gem objects. pd -verbose -lib Gem: i965: Failed to submit batchbuffer: No such file or directory
Best, A.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
alex tuca -
andre rc -
Csaba Láng -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Max