Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenGL Driver (vc4-kms-v3d) on Rpi3 locks up #2906

Closed
loganmc10 opened this issue Apr 26, 2016 · 11 comments
Closed

OpenGL Driver (vc4-kms-v3d) on Rpi3 locks up #2906

loganmc10 opened this issue Apr 26, 2016 · 11 comments

Comments

@loganmc10
Copy link
Contributor

I have enabled the hardware accelerated OpenGL Driver on the Raspberry Pi 3, and I've compiled RetroArch and mupen64plus-libretro from source.

When I try to launch any game, it locks up at this point:

RetroArch [INFO] :: Version of libretro API: 1
RetroArch [INFO] :: Compiled against API: 1
RetroArch [INFO] :: Set audio input rate to: 44107.31 Hz.
RetroArch [INFO] :: Video @ 1920x1440
RetroArch [INFO] :: Using HW render, OpenGL driver forced.
RetroArch [INFO] :: [EGL]: EGL version: 1.4

This is what GDB says:
#0 0x76cefa40 in do_futex_wait (

isem=isem@entry=0x76a61920 <dispmanx_message_available_event+24>)
at ../nptl/sysdeps/unix/sysv/linux/sem_wait.c:48

#1 0x76cefaf4 in __new_sem_wait (

sem=0x76a61920 <dispmanx_message_available_event+24>)
at ../nptl/sysdeps/unix/sysv/linux/sem_wait.c:69

#2 0x76a4aeb4 in dispmanx_send_command () from /opt/vc/lib/libbcm_host.so
#3 0x76a4c500 in vc_dispmanx_update_submit_sync ()

from /opt/vc/lib/libbcm_host.so
#4 0x0013d3a8 in gfx_ctx_vc_init (video_driver=0x2cf218)

at gfx/drivers_context/vc_egl_ctx.c:287

#5 0x0012fe94 in gfx_ctx_init (data=0x2cf218,

ctx=0x209284 <gfx_ctx_videocore>, ident=0x760e3044 "",
api=GFX_CTX_OPENGL_ES_API, major=0, minor=0, hw_render_ctx=false)
at gfx/video_context_driver.c:177

#6 0x00130004 in gfx_ctx_find_driver (data=0x2cf218, ident=0x760e3044 "",

api=GFX_CTX_OPENGL_ES_API, major=0, minor=0, hw_render_ctx=false)
at gfx/video_context_driver.c:225

#7 0x00130090 in gfx_ctx_init_first (data=0x2cf218, ident=0x760e3044 "",

api=GFX_CTX_OPENGL_ES_API, major=0, minor=0, hw_render_ctx=false)
at gfx/video_context_driver.c:254

#8 0x00137610 in gl_get_context (gl=0x2cf218) at gfx/drivers/gl.c:2490
#9 0x001376a8 in gl_init (video=0x7effd248, input=0x248eac <current_input>,

---Type to continue, or q to quit---
input_data=0x248eb0 <current_input_data>) at gfx/drivers/gl.c:2652
#10 0x0003ffcc in init_video () at gfx/video_driver.c:714
#11 0x00041a44 in video_driver_ctl (state=RARCH_DISPLAY_CTL_INIT, data=0x0)

at gfx/video_driver.c:1480

#12 0x00044548 in init_drivers (flags=127) at driver.c:330
#13 0x00044948 in driver_ctl (state=RARCH_DRIVER_CTL_INIT, data=0x7effd3c0)

at driver.c:456

#14 0x00044964 in driver_ctl (state=RARCH_DRIVER_CTL_INIT_ALL, data=0x0)

at driver.c:462

#15 0x000220a0 in rarch_main_init (argc=5, argv=0x7efff734) at retroarch.c:1307
#16 0x00022588 in rarch_ctl (state=RARCH_CTL_MAIN_INIT, data=0x2bf158)

at retroarch.c:1437

#17 0x000308f0 in content_load (info=0x7efff5a4) at content.c:878
#18 0x00032954 in content_ctl (state=CONTENT_CTL_LOAD, data=0x7efff5a4)

at content.c:1778

#19 0x0001d710 in rarch_main (argc=5, argv=0x7efff734, data=0x0)

at frontend/frontend.c:129

#20 0x0001d934 in main (argc=5, argv=0x7efff734) at frontend/frontend.c:184

@HerbFargus
Copy link

You realise the opengl driver on the raspberry is considered experimental right?

@loganmc10
Copy link
Contributor Author

That is why I am experimenting

@HerbFargus
Copy link

All the same it's doubtful it's a bug with retroarch

@loganmc10
Copy link
Contributor Author

loganmc10 commented Apr 26, 2016

That could be true, I just wanted the RetroArch developers to take a look and see if there is any way to fix it, I'll also bring it up with the people responsible for the driver.

Getting this working could be a huge deal for N64 emulation on the Raspberry Pi.

@joolswills
Copy link
Contributor

Looks as though you have compiled for opengles rather than opengl

This isn't a retroarch issue

@loganmc10
Copy link
Contributor Author

I built it using retroarch-build.sh in libretro-super, can you suggest how I can compile it without enabling gles?

@joolswills
Copy link
Contributor

joolswills commented Apr 26, 2016

I can't.

Also are you running it under X? - the new RPI opengl driver is only for the desktop env - won't work from the framebuffer.

@loganmc10
Copy link
Contributor Author

I'll need to do some more testing, but if this really is a problem because opengles is enabled, then it is a RetroArch problem. RetroArch makes that assumption when it is compiled on a Raspberry Pi

in qb/config.libs.sh:
if [ "$HAVE_VIDEOCORE" = 'yes' ]; then
HAVE_GLES='auto'
EXTRA_GL_LIBS="-lEGL -lGLESv2 -lbcm_host -lvcos -lvchiq_arm"
fi

And in the Makefile of mupen64plus-libretro:
else ifneq (,$(findstring rpi,$(platform)))
GLES = 1
GL_LIB := -L/opt/vc/lib -lGLESv2

@loganmc10
Copy link
Contributor Author

It looks like it may have worked (it compiles and runs better, but exits over SSH because it has no display of course), I'll test it tonight on my TV when I get home. If it does work then the RetroArch build system will probably need to be updated to account for the fact that the Raspberry Pi doesn't always want GLES

@joolswills
Copy link
Contributor

Yes. it is set to build for opengles on RPI. I'm sure they would welcome a PR to make this optional, but since the RPI opengl is experimental, they may not want people to use it yet.

@loganmc10
Copy link
Contributor Author

That's true, I will keep experimenting, thanks for the help, I don't really know much about graphics drivers, it seems that disabling OpenGL ES is a good first step for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants