Bug 5787

Summary:	Review Request: gl4es - OpenGL to GL ES translation library
Product:	Package Reviews	Reporter:	Nicolas Chauvet <kwizart>
Component:	Review Request	Assignee:	RPM Fusion Package Review <rpmfusion-package-review>
Status:	RESOLVED WONTFIX
Severity:	enhancement	CC:	rpmfusion-package-review
Priority:	P1
Version:	Current
Hardware:	x86_64
OS:	GNU/Linux
namespace:	rpi
Bug Depends on:
Bug Blocks:	2

Description Nicolas Chauvet 2020-10-07 14:50:22 CEST

SRPM: http://dl.kwizart.net/review/gl4es-1.1.2-4.20201007git3259c93.fc31.src.rpm
SPEC: http://dl.kwizart.net/review/gl4es.spec
Summary: OpenGL to GL ES translation library

This package is a version for the rpi namespace

I expect this package to be useful along with a proprietary driver that lacks libGL implementation (only has gles or egl like rpi).
I plan to (automatically) build a rpi agnostic version in a copr repository. (and not on rpmfusion-free or nonfree because it's unknown which gles implementation to target).


It's still a question whether this is useful given rpi can use either upstream driver (with upstream kernel) or downstream driver (using kernel-rpi). But if using the raspberrypi-vc userspace, a particular having a libGL would be usefull given it's an assumption by the fedora userspace.


I don't plan to exclude the libGL to avoid dependency computation error given that for the rpi namespace

Koji scratch build for f33:
http://koji.rpmfusion.org/koji/taskinfo?taskID=440257

Comment 1 Nicolas Chauvet 2020-10-07 14:56:43 CEST

I don't plan to exclude the libGL to avoid dependency computation error given that for the rpi namespace it's already expected to have the rpi gles and egl as an override, so with that library it's possible to fully replace the system libglvnd.

(until raspi userspace supports libglvnd which isn't planned so far).
See also https://github.com/raspberrypi/userland/issues/556

Comment 2 Nicolas Chauvet 2021-01-20 15:26:39 CET

I've dropped aarch64 for now as I don't expect much use case.
Given the CPU ressources there, I expect most case can use the llvmpipe software emulation for libGL. I'm not even sure that 


In the RPI case, there isn't even a vendor libGLESv2,libEGL as it's expected to rely on vc4 userspace driver from mesa instead.

Comment 3 Nicolas Chauvet 2021-01-20 15:27:22 CET

I'm not even sure that an vendor implementation lacking libGL even exists...

Comment 4 Nicolas Chauvet 2021-01-21 16:22:40 CET

I've dropped the idea to use this as a system path. It would be picked by the desktop environment over any llvmpipe implementation leading to crash because it would not be fully conformant.


Instead I expect this libGL can be used for simple libGL programs with LD_LIBRARY_PATH or more probably, old x86 gl games using box86 on rpi (with downstream graphic drivers)...

Comment 5 Nicolas Chauvet 2023-01-05 11:48:51 CET

not relevant anymore even for rpi.