I've tracked down the problem - nothing to do with the analysis code,
but a compilation error when using the ATI driver for rendering. I've
now updated the driver and OpenGL is working fine. The upgrade to
python2.4 also makes a noticeable performance difference.
Thanks,
Cameron
Wayne Boucher wrote:
>Hello,
>
>Near the top of new_gl_handler() the (release) code says:
>
>#ifdef NEED_GLUT_INIT
> int argc = 0;
> char *argv = NULL;
>#endif
>
>and that could become (while we're trying to figure out why the
>compilation doesn't seem to be doing what it should be):
>
> int argc = 0;
> char *argv = NULL;
>
>and in the first_pass if block the (release) code says:
>
> if (first_pass)
> {
> first_pass = CCPN_FALSE;
> printf("GL_VENDOR = %s\n", glGetString(GL_VENDOR));
> printf("GL_RENDERER = %s\n", glGetString(GL_RENDERER));
> printf("GL_VERSION = %s\n", glGetString(GL_VERSION));
>/*
> printf("GL_EXTENSIONS = %s\n", glGetString(GL_EXTENSIONS));
>*/
>#ifdef NEED_GLUT_INIT
> glutInit(&argc, &argv);
>#endif
> }
>
>and that could become:
>
> if (first_pass)
> {
> first_pass = CCPN_FALSE;
> printf("GL_VENDOR = %s\n", glGetString(GL_VENDOR));
> printf("GL_RENDERER = %s\n", glGetString(GL_RENDERER));
> printf("GL_VERSION = %s\n", glGetString(GL_VERSION));
>/*
> printf("GL_EXTENSIONS = %s\n", glGetString(GL_EXTENSIONS));
>*/
> glutInit(&argc, &argv);
> }
>
>Wayne
>
>PS: Tim and I are off to Sweden in about an hour and not coming back until
>late Wednesday, and we might not see our email that much while we're
>there.
>
>On Mon, 17 Oct 2005, Cameron Mackenzie wrote:
>
>
>
>>Putting those extra two lines allowed me to compile and run analysis
>>with glutInit in draw_text_gl_handler. Analysis still ctrashes when
>>trying to open the graphics and I don't see the printf statement displayed.
>>When compiling, I have:
>>
>>
>>cc -c -DUSE_GL_TRUE -DNEED_GLUT_INIT
>>-I/usr/local/ccpnmr/python2.4/include/pyth
>>on2.4 -I/usr/X11R6/include -I/usr/include -I/usr/include -I/usr/include
>>-O gl_h
>>andler.c
>>(-DUSE_GL_TRUE worked on previous releases where FALSE did not).
>>
>>When trying to remove the #ifdef and #endif statements, I'm getting
>>compilation errors. Probably removing the wrong one - could you copy the
>>piece of code in to make sure I'm on the right tracks?
>>
>>Thanks,
>>Cameron
>>
>>
>>Wayne Boucher wrote:
>>
>>
>>
>>>Whoops, you need the extra two lines:
>>>
>>> int argc = 0;
>>> char *argv = NULL;
>>>
>>>But the fact that the printf statement in new_gl_handler() did not print
>>>its message tells me that the compilation did not work. Which is odd.
>>>You could try removing the two #ifdef / #endif lines in new_gl_handler()
>>>(so remove four lines in total) and see if that works (again, compile in
>>>the directory "ccpnmr1.0/c"), although that's not supposed to make any
>>>difference (given that NEED_GLUT_INIT should be defined on the
>>>compilation line). I'd far prefer to see this glutInit code
>>>in new_gl_handler() than in draw_text_gl_handler(). When you do the
>>>compilation can you check that you have (it will probably be first)
>>>something like:
>>>
>>>cc -c -DUSE_GL_FALSE -DNEED_GLUT_INIT -I/sw/include/python2.4
>>>-I/usr/X11R6/include -I/sw/include -I/sw/include -O gl_handler.c
>>>
>>>in the compilation messages (the -I flags will be different for you)
>>>
>>>Wayne
>>>
>>>On Mon, 17 Oct 2005, Cameron Mackenzie wrote:
>>>
>>>
>>>
>>>
>>>
>>>>Tried putting in the printf statement in new_gl_handler but it didn't
>>>>appear when I ran analysis (or when it crashed).
>>>>
>>>>Also tried putting the bit of code in draw_text_gl_handler but I got a
>>>>compilation error:
>>>>
>>>>gl_handler.c:947: error: `argc' undeclared (first use in this function)
>>>>gl_handler.c:947: error: (Each undeclared identifier is reported only once
>>>>gl_handler.c:947: error: for each function it appears in.)
>>>>gl_handler.c:947: error: `argv' undeclared (first use in this function)
>>>>
>>>>
>>>>Cameron
>>>>
>>>>
>>>>Wayne Boucher wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Hello,
>>>>>
>>>>>This sounds like the freeglut problem we were having a discussion about a
>>>>>month or two ago. So for you I'm pretty sure that you should have
>>>>>
>>>>>GLUT_FLAG = -DNEED_GLUT_INIT
>>>>>
>>>>>and GL_FLAG should probably be whatever you used to have. So to check
>>>>>what is going on (we don't have freeglut here so not easy for us to check)
>>>>>the first thing we should try is to make sure it is actually calling the
>>>>>glutInit() routine. So in ccpnmr1.0/c/memops/global/gl_handler.c find the
>>>>>line which calls glutInit and put a
>>>>>
>>>>>printf("about to call glutInit\n"); /* temporary line */
>>>>>
>>>>>above it and then do a "make" (in ccpnmr1.0/c, so that all directories get
>>>>>re-compiled and re-linked correctly). Now if that message appears on the
>>>>>screen when you run the program then the problem is probably that the
>>>>>glutInit isn't happy being called in the new_gl_handler() (although I
>>>>>thought we had checked before it was). (And morally, this is where it
>>>>>belongs.) So the alternative is to put it in draw_text_gl_handler().
>>>>>You would need to add there, after the line
>>>>>
>>>>> static void *font = GLUT_BITMAP_HELVETICA_10;
>>>>>
>>>>>the following code:
>>>>>
>>>>>#ifdef NEED_GLUT_INIT
>>>>> static Bool first_pass = CCPN_TRUE;
>>>>>
>>>>> printf("about to call glutInit\n"); /* temporary line */
>>>>>
>>>>> if (first_pass)
>>>>> {
>>>>> first_pass = CCPN_FALSE;
>>>>> glutInit(&argc, &argv);
>>>>> }
>>>>>#endif
>>>>>
>>>>>and comment out the other glutInit call.
>>>>>
>>>>>If that works then we'll have to go back to that alternative in the next
>>>>>release (although I think it's dreadful).
>>>>>
>>>>>Wayne
>>>>>
>>>>>On Mon, 17 Oct 2005, Cameron Mackenzie wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>On the latest release, I can't get OpenGL working. Analysis crashes out with
>>>>>>a X BadMatch error from a X_GLXMakeCurrent command.
>>>>>>
>>>>>>I'm using ATI fglrx 8.16.20 for rendering and freeglut 2.2.0-82.
>>>>>>
>>>>>>Have tried compiling with all combinations of "GL_FLAG =" and "GLUT_FLAG ="
>>>>>>but they all cause a crash.
>>>>>>
>>>>>>Tk works OK.
>>>>>>
>>>>>>Cameron
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>
>
>
>
|