Issue
I'm porting/testing my code on a Raspberry Pi running Pidora, all updated.
The test is a very simple OpenGL program, which works fine on two other computers. I narrowed down a problem to a glPopMatrix call, which causes a segfault. A trivial reproduction of the problem (the entire draw function) is:
glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
glViewport(0,0,200,200);
float d1=0.0f, d2=0.1f;
glPushMatrix(); //gratuitous push/pop pair to demonstrate
glBegin(GL_TRIANGLES);
glColor4f(1.0f,0.0f,0.0f,0.5f); glVertex3f( 0.00f, 1.0f,d1);
glColor4f(0.0f,1.0f,0.0f,0.5f); glVertex3f( 0.87f,-0.5f,d1);
glColor4f(0.0f,0.0f,1.0f,0.5f); glVertex3f(-0.87f,-0.5f,d1);
glColor4f(1,0,0,1);
glVertex3f(0,0,d2);
glVertex3f(1,0,d2);
glVertex3f(0,1,d2);
glColor4f(1,0,1,1);
glVertex3f( 0, 0,-d2);
glVertex3f(-1, 0,-d2);
glVertex3f( 0,-1,-d2);
glEnd();
glPopMatrix(); //segfault here!
The only reference I could find was this 2011 bug report, which describes effectively the same problem. So far, it seems they only have a workaround:
export GALLIUM_DRIVER=softpipe
export DRAW_USE_LLVM=no
I found only the first line was necessary. However, as suggested by the above, it looks like it might be forcing the OS to use a software fallback. It shows. The program (which as above draws three triangles) runs at about 10Hz.
It's common knowledge that the OpenGL matrix stack is deprecated, but simple usage cases like the above are useful for testing. I would expect glPopMatrix to at least not crash if it's present. Is there a way I can get hardware acceleration but still use this?
Solution
The raspberry pi has hardware support for OpenGL ES 1.x/2.x via vendor-specific libraries - but none for desktop GL. Immediate mode (glBegin/glEnd) was never in GLES. You have to use vertex arrays. However, the matrix stack is available in GLES1.x. You have to use egl to get a hw-accelerated context. On the upside, GL on the RPi does not require X11, so you can have an GL overlay just directly on the console, which is very cool. The official RPi firmware comes with the hello_triangle demo, which shows you how to get a valid context, the source can be found in /opt/vc/src/hello_pi/hello_triangle. There are also Ben O. Steen's RPi ports of the examples of the OpenGL ES programming guide/
You are currently using the mesa software renderer, which will be extremely slow on that platform. The crash seems to be a mesa bug, but as mesa doesn't have any hw accleration support for the GPU of the rpi, this should not really matter. The cod you have pasted is valid desktop GL1.x/2.x and should not crash on a conforming implementation.
Answered By - derhass Answer Checked By - Mary Flores (WPSolving Volunteer)