Hi,
damn, this new configue option --with-glversion fixed all the problems I had on my Matrox machine! (I didn't yet test the i915 laptop.) Using --with-glversion=1.5 not only lets Gem render again on newest Mesa/DRI, it also gets rid of the crash when closing the Gem window! So, thank you for supporting older and hardware with buggy GL2.0-drivers again.
Ciao
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
damn, this new configue option --with-glversion fixed all the problems I had on my Matrox machine! (I didn't yet test the i915 laptop.)
Actually I'm as stupid as f* because I was still running with DRI *disabled* when I "tested" the new gl-version option. With DRI enabled again, everything is as before: No rendering with latest Mesa, crashes everytime I close the Gemwin. :(
Ciao
Hey Frank,
Now I look closer this really looks like the same DRI problem I'm having on my ppc ubuntu machine:
https://launchpad.net/bugs/89609
So now in this case we have "supported" (powerbook5,2 1.25ghz, radeon 9600) hardware and the thing is still not working, so clearly it must be DRI. I don't even have the choice of using a binary driver because ppc-linux drivers for ATI do not exist. DRI is the only option.
Many folks have filed against DRI but I think gem is the only app that still does not work:
https://launchpad.net/bugs/61607
They say gem is the problem, we're saying DRI is, so lets all get on the bug and try and figure out what is wrong, maybe solving my problem on supported HW will fix the problem for matrox/intel chips.
Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
damn, this new configue option --with-glversion fixed all the problems I had on my Matrox machine! (I didn't yet test the i915 laptop.)
Actually I'm as stupid as f* because I was still running with DRI *disabled* when I "tested" the new gl-version option. With DRI enabled again, everything is as before: No rendering with latest Mesa, crashes everytime I close the Gemwin. :(
Ciao
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
Now I look closer this really looks like the same DRI problem I'm having on my ppc ubuntu machine:
https://launchpad.net/bugs/89609
So now in this case we have "supported" (powerbook5,2 1.25ghz, radeon 9600) hardware and the thing is still not working, so clearly it must be DRI. I don't even have the choice of using a binary driver because ppc-linux drivers for ATI do not exist. DRI is the only option.
Many folks have filed against DRI but I think gem is the only app that still does not work:
https://launchpad.net/bugs/61607
They say gem is the problem, we're saying DRI is, so lets all get on the bug and try and figure out what is wrong, maybe solving my problem on supported HW will fix the problem for matrox/intel chips.
All these crashs happen in the same code sections:
#1 0x0f722538 in glXMakeCurrentReadSGI () from /usr/lib/libGL.so.1 #2 0x0f966874 in GemMan::destroyWindow () from ./Gem.pd_linux
for your ATI and my Intel and Matrox chips. It does not happen in software rendering. Newest versions of Mesa not even render anything in Gem anymore.
It's way above my head what is causing this - DRI, Gem? - but it's a major pain and already made me explore alternatives to Gem (not to Intel, as I still won't run Nvidia for pathetic ideological reasons), probably I'll try something with PythonGL. But for now I just pray that I will never accidentaly close the Gem-Window before saving or while on stage.
Ciao
I have no idea also, so It would be very nice if Gem worked with DRI and not only binary blobs, if there is something missing from DRI that keeps gem from working those folks should hear about it. I still don't get why all other openGL apps work, even complex pixelshading stuff with beryl/compiz etc.. If that stuff works Gem should work.
I'm willing to do any testing needed, and any of the OSX devs can just as easily put ubuntu on their ppc machines and maybe just that will fix Frank's problems and make gem work on all opengl compatible hardware, even if it is not quite as fast as binary blob rendering.
.b.
Frank Barknecht wrote:
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
Now I look closer this really looks like the same DRI problem I'm having on my ppc ubuntu machine:
https://launchpad.net/bugs/89609
So now in this case we have "supported" (powerbook5,2 1.25ghz, radeon 9600) hardware and the thing is still not working, so clearly it must be DRI. I don't even have the choice of using a binary driver because ppc-linux drivers for ATI do not exist. DRI is the only option.
Many folks have filed against DRI but I think gem is the only app that still does not work:
https://launchpad.net/bugs/61607
They say gem is the problem, we're saying DRI is, so lets all get on the bug and try and figure out what is wrong, maybe solving my problem on supported HW will fix the problem for matrox/intel chips.
All these crashs happen in the same code sections:
#1 0x0f722538 in glXMakeCurrentReadSGI () from /usr/lib/libGL.so.1 #2 0x0f966874 in GemMan::destroyWindow () from ./Gem.pd_linux
for your ATI and my Intel and Matrox chips. It does not happen in software rendering. Newest versions of Mesa not even render anything in Gem anymore.
It's way above my head what is causing this - DRI, Gem? - but it's a major pain and already made me explore alternatives to Gem (not to Intel, as I still won't run Nvidia for pathetic ideological reasons), probably I'll try something with PythonGL. But for now I just pray that I will never accidentaly close the Gem-Window before saving or while on stage.
Ciao
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
I have no idea also, so It would be very nice if Gem worked with DRI and not only binary blobs, if there is something missing from DRI that keeps gem from working those folks should hear about it. I still don't get why all other openGL apps work, even complex pixelshading stuff with beryl/compiz etc.. If that stuff works Gem should work.
I'm willing to do any testing needed, and any of the OSX devs can just as easily put ubuntu on their ppc machines and maybe just that will fix Frank's problems and make gem work on all opengl compatible hardware, even if it is not quite as fast as binary blob rendering.
Well, here's what I found out so far:
It's not only my problem: Georg Holzman has it as well, AFAIR, and Miha Tomsic has a bug report about it open on freedesktop.org [1]. As I see it, it affects everyone trying to run Gem on Linux with Mesa/DRI 6.5 up, which means everyone without an NVidia card which means probably more that a handful of people.
Mesa 6.5 did some major cleanup of MakeCurrentContext [2] which might be related to our problem. However I have no idea where exactly Gem and Mesa/DRI clash. I guess (wildly), that Gem is triggering some bug in the Mesa/DRI layer. However as I'm GL-challenged I have no way of pointing the DRI people to where that may be.
What's even worse is that with M/DRI 6.5.2 Gem stopped rendering, as reported by Miha, you and me. While a crash when closing the Gem window can be worked around by just never closing the Gem window, broken rendering is a complete show stopper and doesn't even give a useful coredump.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=9204 [2] https://bugs.freedesktop.org/show_bug.cgi?id=8443
Ciao
Hey all,
I thought I would give the --with-gl-version=1.5 a try on my ATI/feisty/ppc powerbook.
Well #1. Gem compiles and loads without error.
I can even load the "redsquare" patch and I get an image! (A huge improvement.)
glxinfo tells me I have mesa DRI enabled, glxgears is giving me about 1700 fps using about 60% CPU with the default window size. (respectable)
the redsquare demo patch shows PD using about 25% CPU.
Closing the gemwindow (via message or gui) still gives the same old segfault posted in this thread though.
07.feedback crawls (looks like 1fps) and uses 100% CPU.
So at least that is something, and certainly an improvement, but still not quite working well enough to be usable yet.
I just wanted to keep you all posted.
Maybe someone who knows why the mesa/DRI sucks can tell those developers how to make it suck less?
.b.
Frank Barknecht wrote:
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
I have no idea also, so It would be very nice if Gem worked with DRI and not only binary blobs, if there is something missing from DRI that keeps gem from working those folks should hear about it. I still don't get why all other openGL apps work, even complex pixelshading stuff with beryl/compiz etc.. If that stuff works Gem should work.
I'm willing to do any testing needed, and any of the OSX devs can just as easily put ubuntu on their ppc machines and maybe just that will fix Frank's problems and make gem work on all opengl compatible hardware, even if it is not quite as fast as binary blob rendering.
Well, here's what I found out so far:
It's not only my problem: Georg Holzman has it as well, AFAIR, and Miha Tomsic has a bug report about it open on freedesktop.org [1]. As I see it, it affects everyone trying to run Gem on Linux with Mesa/DRI 6.5 up, which means everyone without an NVidia card which means probably more that a handful of people.
Mesa 6.5 did some major cleanup of MakeCurrentContext [2] which might be related to our problem. However I have no idea where exactly Gem and Mesa/DRI clash. I guess (wildly), that Gem is triggering some bug in the Mesa/DRI layer. However as I'm GL-challenged I have no way of pointing the DRI people to where that may be.
What's even worse is that with M/DRI 6.5.2 Gem stopped rendering, as reported by Miha, you and me. While a crash when closing the Gem window can be worked around by just never closing the Gem window, broken rendering is a complete show stopper and doesn't even give a useful coredump.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=9204 [2] https://bugs.freedesktop.org/show_bug.cgi?id=8443
Ciao
-
B. Bogart -
Frank Barknecht