Using OpenGL Core Profile for x86 Generic build

    Hi,

    I would like to ask, what is the motivation to use OpenGL ES instead of the Core Profile for main Generic x86 build. Is it possible to build Generic image using GBM + OpenGL Core Profile? Are there any limitations when using that?

    We are currently working on GL/GLES support for video shaders in games for Kodi and there is a benefit of more working shaders and features, when running the full OpenGL stack compared to GLES. I've already tried to build standalone Kodi for GBM/GL and it seems to work fine on my Ryzen laptop (KDE neon), so in theory it should be possible on LE as well, but I haven't fully tested video playback and things like HDR.

    If we ever get the OpenGL libretro cores support, the same will apply for it as well: More features and better compatibility for full OpenGL stack when compared to GLES.

    Edited 3 times, last by KOPRajs (February 8, 2025 at 9:19 AM).

    It was not possible to build OpenGL without X11. I'm not sure if anything changed now.

    Also, current Kodi master does not support HDR passthrough with OpenGL.

    Quote from KOPRajs

    I would like to ask, what is the motivation to use OpenGL ES instead of the Core Profile for main Generic x86 build.

    Our smaller devices only support OpenGL ES. That means, those calls go directly to GPU (hardware accelerated).

    OpenGL Core Profile for x86 would add another branch of development, which doesn't make sense for our needs (though it would make sense for yours).

    LE's installed base is roughly 80% RPi boards, 10% x86_64 hardware, and 10% other ARM boards. The x86_64 devices break down as 70% Intel, 20% AMD, 10% nVidia; most of the nVidia cards are older ones requiring VDPAU and legacy drivers, not newer ones with NVDEC. LE users mostly run Kodi to watch videos, so features like HDR playback trump shader support for games. The legacy image exists to service a handful of nVidia users and those who require a browser to access certain streams. I'm not aware that you can build mesa with OpenGL without X11, which means no HDR, and the long term goal is to bin X11 and only support GBM, and with either a GBM 'browser' or worst-case Wayland, which supports HDR, but doesn't currently support refresh rate switching which is a must-have feature for Kodi movie viewers. So right now all roads point in the direction of ```GBM/OpenGLES, not OpenGL. If it's now possible to run a GBM/OpenGL environment that would be interesting, but we'll look into that direction once there's a complelling reason; e.g. Kodi finally has Retroplayer OpenGL capabilities. It doesn't make sense for us to switch from a known/good formula unless there's demand. If you've already built Generic/OpenGL/GBM images that work? we'd have no issue with the changes being submitted to make development easier; similar to how we have options for Generic/Wayland although we don't currently build it. There's also no issue to add changes in LE that reduce downstream technical debt in Lakka, if that's at-all a related objective.

    That's interesting, although from a release management perspective I would not consider switching Generic to OpenGL for LE13 for two reasons:

    a) It's getting close to the likely release schedule for K22 and this is slightly exotic and thus needs proper testing on a wide range of GPU hardware (and Generic users often have older hardware).

    b) It's a breaking change for Kodi binary add-ons and I'd like a release without breaking changes. In the last two releases we did Python2>3 and arm>aarch64. This time around it's stable, but we'll get enough whinging from dropping nVidia 340.108 support.

    There's no issue to add another build option earlier though.

    Thank you guys!

    smp And thank you for the PR!

    These are mostly great news. We are not there yet to consider switching the main build for LE13, but it is good to know, that it can be done, and we can at least use it for the RetroPlayer test builds. Now lets hope that we can get the video shaders merged before 22 release.