Raspberry Pi 4 OpenGLES

[techyian]

Hi,

I'm looking for some info regarding OpenGLES support on the Pi 4. I've read in the announcement that GLES 3.0 is now supported, but I'm interested in the state of GLES 1.1 on Videocore 6? I'm involved in getting Wolfenstein Enemy Territory working on the Pi and have had success on the Pi 3b+ using GLES 1.1 by linking to the "libbrcmGLESv2" library. However the same setup on the Pi 4 will freeze the game on-start and simply show the black cursor from the game. For info, SDL is used in the backend. I have posted on the Pi forums but solid knowledge regarding GLES support is lacking currently.

Thanks.

[popcornmix]

Previous Pi's used a non-standard mechanism of getting EGL onto a display (dispmanx).
When using kms/fkms (pi4 only supports fkms) you can't use that and need do this the standard linux way.

This is a useful thread where these methods are discussed:
https://www.raspberrypi.org/forums/viewtopic.php?f=68&t=243611

[techyian]

Thanks for the info. I suspect some changes may be needed to SDL to take into account these changes. Until now, the way it's been advised to configure SDL for GLES is to run the following:

--host=armv7l-raspberry-linux-gnueabihf --disable-pulseaudio --disable-esd --disable-video-mir --disable-video-wayland --disable-video-x11 --disable-video-opengl

That would force SDL to use its "RPI" video driver which I assume does all the EGL->dispmanx handling. Now that EGL should communicate with X11 instead of dispmanx, what I thought would be a sensible thing to do would be to pass --disable-video-rpi but the issue there is that SDL no longer looks for the OpenGLES 1.1 headers in /opt/vc/include and libgles1-mesa-dev can't be installed under Debian Buster. Hopefully I'm on the right lines here, I'll raise a thread on the SDL forums also.

Ian

[techyian]

Just to add, I managed to get around that hurdle by adding /opt/vc/include to the C_INCLUDE_PATH environment variable, allowing me to disable RPI in SDL and also keep GLES1. Unfortunately, I just receive "failed to add service - already in use?" when loading Enemy Territory - this is something I've come across in the past when using the kms/fkms driver with GLES.

[popcornmix]

Adding /opt/vc/include doesn't sound like the right solution. That is likely finding the firmware gl includes, rather than the desired mesa ones (in /usr/include). Do you have mesa installed (libgles2-mesa-dev)?

[techyian]

The issue there is that I need GLES 1.1 and that would mean needing libgles1-mesa-dev for the correct headers but I can't install that under Buster. I think the currently installed Mesa headers for GLES 2.0 will throw a lot of errors for me due to the fixed function pipeline in the vanilla renderer for Enemy Territory.

[popcornmix]

Are you using SDL or SDL2?

If what you are saying is that SDL requires libgles1-mesa-dev to build and libgles1-mesa-dev has been dropped by debian then that isn't a Pi issue and should be brought up with SDL.

(the fact libsdl2-dev is in buster suggests this is possible).

[techyian]

Nope using SDL2. Perhaps I've misunderstood, but I was under the impression that GLES 2.0 dropped all the fixed function stuff and isn't backwards compatible with GLES 1.1? I'm not sure if their opengl_es2 video driver is compatible with GLES 1.1. I'll raise a ticket with them and post back here when I find out more. Thanks for your help @popcornmix.

[popcornmix]

So does Wolfenstein Enemy Territory use GLES 1.1 itself?
Or does it just rely on SDL using GLES 1.1 itself (e.g. for blitting)?

[techyian]

The vanilla renderer supports GLES 1.1 using the fixed function pipeline. Nothing is currently in place for GLES 2.0.

[techyian]

For reference it's Enemy Territory: Legacy that I'm helping with.

[popcornmix]

It looks like debian dropped GLES1 support from mesa as no packages (out of 50000+ in repo) used it.
GLES1 is 16 years old. GLES2 is 12 years old.

I think mesa can be built with GLES1 support but that would require a custom build.

Updating rendering to GLES2 might be the best solution.
The GLES1 issue is not Pi specific - it will affect any platform that wants to move to Debian Buster.

[techyian]

I was fearing that might be the case. I will assume that this problem is going to affect the other ID Tech 3 games which support GLES 1.1 too (iortcw. ioq3/OpenArena). Will try them this evening and let you know.

[techyian]

Just tried iortcw and the game builds and does load, however nothing is displayed on-screen (can hear background music) which I assume is due to the way EGL & X11 must now be setup on the Pi 4. I now need to see which libs & headers iortcw is using when compiling and let the SDL devs know some work is required on their end.

[techyian]

Huge turnaround - I've got Enemy Territory working. I've linked to the GLESv1_CM library in /usr/lib/ and used the GLES 1.1 firmware headers. It's started up using an X11 window. Going to do some more tests and check I've not done anything perculiar. Getting 60 FPS on average!

[techyian]

Yep can confirm it's running GLES 1.1 in an X11 window, I get the following returned by the game:

GL_VENDOR: Broadcom
GL_RENDERER: V3D 4.2
GL_VERSION: OpenGL ES-CM 1.1 Mesa 19.1.0-devel

SDL was configured without any additional flags, so simply ./configure, and as mentioned previously, when compiling the game I linked to the firmware GLES 1.1 headers in /opt/vc/include/ and the GLESv1_CM library.

[popcornmix]

That's good to hear. That suggests mesa does include the GLESv1 support, but not the GLES/gl.h header files.
Technically using the headers from /opt/vc/include is not quite correct, but the difference is likely to be minimal and if it compiles okay you are probably fine.

[techyian]

Thanks @popcornmix I'll close this issue now.

[jdonald]

@techyian I wonder if it would be more correct to use header files from /usr/include/khronos-api/GLES/?

sudo apt install -y khronos-api

Then your code would be portable across pre-Buster systems as well as platforms other than Pi that also happen to retain a working Mesa libGLESv1_CM.so despite the efforts to kill it off.

[agherzan]

I have an issue with selecting the mesa driver on RPi4. I ccompiled mesa with v3d driver enabled, loaded the fkms overlay and ccompiled kmscube. Running the latter fails with:

root@raspberrypi4:~# kmscube 
drmModeGetResources failed: Invalid argument
failed to initialize legacy DRM

Switching to card1 fails with:

root@raspberrypi4:~# kmscube -D /dev/dri/card1
MESA-LOADER: failed to open vc4 (search paths /usr/lib/dri)
failed to load driver: vc4
MESA-LOADER: failed to open kms_swrast (search paths /usr/lib/dri)
failed to load driver: kms_swrast
MESA-LOADER: failed to open swrast (search paths /usr/lib/dri)
failed to load swrast driver
Segmentation fault

I have only enabled v3d for my tests.

[popcornmix]

I believe you need to build with v3d and vc4 for Pi4

The 3D side is in kernel module "v3d", with the DRM side in "vc4" (common with earlier Pis). On earlier Pis the 3D side was also in "vc4".

https://www.raspberrypi.org/forums/viewtopic.php?t=243611#p1486157

[agherzan]

@popcornmix That makes sense now. I enabled vc4 too (made sure is enabled in kernel as well along with v3d) but it still fails as it falls back to sw renderer:

root@raspberrypi4:~# kmscube -D /dev/dri/card1
Using display 0xf628b0 with EGL version 1.4
===================================
EGL information:
  version: "1.4"
  vendor: "Mesa Project"
  client extensions: "EGL_EXT_client_extensions EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses EGL_KHR_debug EGL_MESA_platform_gbm E"
  display extensions: "EGL_EXT_buffer_age EGL_EXT_image_dma_buf_import EGL_KHR_cl_event2 EGL_KHR_config_attribs EGL_KHR_create_context EGL_KHR_create_context_no_error EGL_KHR_fence_sync EGL_KHR_get_all_proc_addres"
===================================
OpenGL ES 2.x information:
  version: "OpenGL ES 3.1 Mesa 19.1.1"
  shading language version: "OpenGL ES GLSL ES 3.10"
  vendor: "VMware, Inc."
  renderer: "softpipe"
  extensions: "GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_texture_filter_anisotropic GL_EXT_texture_compression_s3tc GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc GL_EXT_texture_format_B"
===================================
Using modifier ffffffffffffff
failed to set mode: Invalid argument

[agherzan]

This while Rapsbian does the correct selection:

pi@raspberrypi:~ $ sudo kmscube -D /dev/dri/card1 
Using display 0x9dbd28 with EGL version 1.4
===================================
EGL information:
  version: "1.4"
  vendor: "Mesa Project"
  client extensions: "EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses EGL_EXT_client_extensions EGL_KHR_debug EGL_EXT_platform_wayland EGL_EXT_platform_x11 EGL_MESA_platform_gbm EGL_MESA_platform_surfaceless"
  display extensions: "EGL_EXT_buffer_age EGL_EXT_image_dma_buf_import EGL_EXT_image_dma_buf_import_modifiers EGL_KHR_cl_event2 EGL_KHR_config_attribs EGL_KHR_create_context EGL_KHR_create_context_no_error EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_no_config_context EGL_KHR_reusable_sync EGL_KHR_surfaceless_context EGL_EXT_pixel_format_float EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_drm_image EGL_MESA_image_dma_buf_export EGL_WL_bind_wayland_display "
===================================
OpenGL ES 2.x information:
  version: "OpenGL ES 3.0 Mesa 19.1.0-devel"
  shading language version: "OpenGL ES GLSL ES 3.00"
  vendor: "Broadcom"
  renderer: "V3D 4.2"
  extensions: "GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_texture_format_BGRA8888 GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_float GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_half_float GL_EXT_texture_sRGB_decode GL_OES_EGL_image GL_OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_type_2_10_10_10_REV GL_OES_get_program_binary GL_APPLE_texture_max_level GL_EXT_discard_framebuffer GL_EXT_read_format_bgra GL_EXT_frag_depth GL_NV_fbo_color_attachments GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_vertex_array_object GL_EXT_occlusion_query_boolean GL_EXT_texture_rg GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil GL_NV_read_stencil GL_EXT_draw_buffers GL_EXT_map_buffer_range GL_KHR_debug GL_KHR_texture_compression_astc_ldr GL_OES_depth_texture_cube_map GL_OES_required_internalformat GL_OES_surfaceless_context GL_EXT_color_buffer_float GL_EXT_sRGB_write_control GL_EXT_separate_shader_objects GL_EXT_shader_integer_mix GL_EXT_base_instance GL_EXT_compressed_ETC1_RGB8_sub_texture GL_EXT_draw_elements_base_vertex GL_EXT_texture_border_clamp GL_KHR_context_flush_control GL_OES_draw_elements_base_vertex GL_OES_texture_border_clamp GL_OES_texture_stencil8 GL_EXT_float_blend GL_KHR_no_error GL_KHR_texture_compression_astc_sliced_3d GL_OES_EGL_image_external_essl3 GL_MESA_shader_integer_functions GL_KHR_parallel_shader_compile GL_EXT_texture_query_lod "
===================================

[agherzan]

To whoever is hitting this: the missing piece was kmsro in mesa.