Advertisement Jump to content
Sign in to follow this  
Geometrian

OpenGL SEGFAULT with OpenGL ES glDrawArrays

This topic is 1842 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

I'm trying to draw simple things with OpenGL ES on a Raspberry Pi.

I created a context through the X system and the glx_create_context_es2_profile extension. This resulted in what I hope is an OpenGL ES 2.0 context (the testing functions gave weird values), but it seems to work for some things (e.g., it gave salient feedback on a shader, which it successfully compiled).

The code is:
GLint loc_vert = program->get_location_attribute("vertex");
printf("Loc vert=%d, vertex size=%d\n",loc_vert,sizeof(Vertex));
glEnableVertexAttribArray(loc_vert); glVertexAttribPointer(loc_vert, 4,GL_FLOAT, GL_FALSE, sizeof(Vertex),vertices);

printf("Begin glDrawArrays=%p with %d,%d,%d\n",glDrawArrays, mode,0,num_vertices);
glDrawArrays(mode, 0,num_vertices);
printf("End glDrawArrays=%p\n",glDrawArrays);

glDisableVertexAttribArray(loc_vert);
The "vertices" array is a static array of four vertices

The output is:

Loc vert=0, vertex size=68
Begin glDrawArrays=<some ptr> with 1,0,2
segfault

I checked against the documentation and my previous code, and this should be valid (it also runs fine on two other systems).

I took the liberty of disassembling glDrawArrays:

Dump of assembler code for function glDrawArrays:
0xb6e63500 <+0>: ldr r3, [pc, #42985368] ; 0xb6e63528 <glDrawArrays+40>
0xb6e63504 <+4>: push {r4, lr}
0xb6e63508 <+8>: mov r4, r0
0xb6e6350c <+12>: ldr r3, [pc, r3]
0xb6e63510 <+16>: bl 0xb6e6f110
0xb6e63514 <+20>: ldr r3, [r0, r3]
0xb6e63518 <+24>: mov r0, r4
0xb6e6351c <+28>: ldr r3, [r3, #3122144] ; 0x4d8
0xb6e63520 <+32>: blx r3
0xb6e63524 <+36>: pop {r4, pc}
0xb6e63528 <+40>: andeq r8, r1, r12, asr sp
End of assembler dump.

It segfaults on "0xb6e63510 <+16>", which is a jump.

Ideas?
-G Edited by Geometrian

Share this post


Link to post
Share on other sites
Advertisement
After looking around at a related issue, I found this StackOverflow question. Therefore, I changed the code to:
GLint loc_vert = program->get_location_attribute("vertex");

GLuint vao;
glGenVertexArrays(1,&vao);
glBindVertexArray(vao);

GLuint vbo;
glGenBuffers(1,&vbo);
glBindBuffer(GL_ARRAY_BUFFER,vbo);
glBufferData(GL_ARRAY_BUFFER, num_vertices*sizeof(Vertex),vertices, GL_STATIC_DRAW);

glEnableVertexAttribArray(loc_vert);
glVertexAttribPointer(loc_vert, 4,GL_FLOAT, GL_FALSE, sizeof(Vertex),NULL);

glDrawArrays(mode, 0,num_vertices);

glDisableVertexAttribArray(loc_vert);

glDeleteBuffers(1,&vbo);
glDeleteVertexArrays(1,&vao);
This does not fix the problem.

Share this post


Link to post
Share on other sites

I wasn't able to set up a debug context on the Pi since GLEW 1.10 isn't supported by default and setting it up would be a pain. However, I can check glGetError, which returns 0 right before glDrawArrays(...), as it should.

Share this post


Link to post
Share on other sites
&nbsp;

Hi,

I'm trying to draw simple things with OpenGL ES on a Raspberry Pi.

I created a context through the X system and the glx_create_context_es2_profile extension. This resulted in what I hope is an OpenGL ES 2.0 context (the testing functions gave weird values), but it seems to work for some things (e.g., it gave salient feedback on a shader, which it successfully compiled).


The Raspberry Pi doesn't, currently, support it's hardware OpenGL ES through GLX. You've probably got a Mesa context.

You have to get the GL context using the Broadcom and EGL APIs. Look at the example in /opt/vc/src/hello_pi/hello_triangle2.

Share this post


Link to post
Share on other sites
That is extremely unfortunate, but it seems to be correct. See also:

The traditional way (on Linux) is to use the X window system to provide a surface on which the OpenGL/OpenGL ES surface can be rendered. At this moment, the implementation of X for the Raspberry Pi is unable to do this, and so you can’t use X to provide your surface. I am very sure that this support will be added in time, but until then, people wanting to play with this will have to connect up the OpenGL ES side of things to the display by another method.


I'll see about setting up a context with those APIs. Thanks,

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!