esUtil for OpenGL ES fullscreen using DRM/KMS

[jannewmarch]

The book "Open GL ES 3.0 Programming Guide" by Dan Ginsburg et al has example programs and implementations using a variety of platforms. For Linux, it only gives an implementation for the X11 platform (esUtil_X11.c). Based on the kmscube code, I have created an alpha version that gives an implementation for the DRM/KMS platform (esUtil_DRM.c). This runs fullscreen with no X11 or Wayland. Yes, it follows on from the thread [Full screen OpenGL ES on Pi 4][https://www.raspberrypi.org/forums/view ... p?t=243707].

It is at [esUtil.c for DRM. Adapted from OpenGL ES Programming Guide to use Linux DRM instead of X11][https://github.com/jannewmarch/opengles-DRM]. It has only been tested on the RPi 4 using the programs in the book. Comments, forks, code fixes welcome!

[PeterO]

It would be good to use something like cglm https://github.com/recp/cglm to replace the inbuilt matrix maths code.
I've moved away from using the esUtils code as it didn't seem very well suited to doing anything more complicated than their examples.

See https://www.raspberrypi.org/forums/view ... 8&t=263606 for my current 3D project.

BTW I have found the book itself (and the earlier GLES 2.0 edition) to be very helpful when learning GLES programming.

PeterO

[Gavinmc42]

Thanks Jan,
It compiled on Gentoo64, but I need to follow your instructions and not just "make".
Got kmscube working the other night so I suspect this will be 64bit and OS agnostic.
I'm relearning a lot of C coding at the same time.

Don't think I had that book in my collection.
A bunch of examples to play with and try to convert to Python.

I'm looking for OpenGLES 3.1 stuff that uses Compute Shaders, got an interest in Tessendorf Ocean fft stuff.
Python access to the Compute Shaders will be useful for other stuff.

It is nice the VC6 is basically mainstream now, any knowledge I acquire and don't forget will be transferable beyond Pi's.

The programs involving changing images work, but change VERY fast

I'm pretty sure that is better than VERY slow
Time for you to do another book?

[Gavinmc42]

I remembered some egl stuff in the mesa demos.

While it is making I did a google and found this.
https://github.com/ds-hwang/gbm_es2_demo
Nice to have a Rust demo as well.

[drgeoffathome]

Yesterday I pushed the exact same idea. Having a look over https://github.com/jannewmarch/opengles-DRM shows that I used the same approach of mashing the relevant parts of kmscube into the OpenGL ES {2,3}.0 Programming Guide samples.

In Jan's repo you get a very clear idea of what he had to change to get it going. The only significant difference my repo has is that the code sits in the "correct" places and the build instructions are "vanilla".

If you are interested, 3.0 is on github at https://github.com/DrGeoff/opengles3-book.git and 2.0 is https://github.com/DrGeoff/opengles-book-samples.git

[joyrider3774]

how hard would it be to add KMS / DRM support to SFML-PI from attract mode repo ? I think that's basically all that's needed to get attract mode running outside X. But i'm a windows delphi developper and no C / C++ developper. I have tried hacking up some code but i seem to get nowhere. From what i see there is a seperate dir for RPI that probably needs a few small modifcations for kms to work (initialize drm / gbm) etc. While i can probably hack that up i don't see how i can get it to interface with the rest of the library and my code was crap. Currently that library still hardlinks to bcrm files and headers so won't work on a pi4 outside x. but from what i could see there aren't that many changes to be done except initializing the drm / krm and doing the swap buffer thing.

see here https://github.com/mickelson/sfml-pi/tr ... Window/RPi
or here for the complete repo https://github.com/mickelson/sfml-pi/

is anyone up for trying to get that library to work with DRM / KMS as i can't do it myselve. Besides having the SFML library be able to run outside X (as thats what sfml-pi version was created for in first place) it would also make a lot of people happy trying to get attract mode (some front end like emulation station) working outside X. Although to be honest i have not looked at the attract code itselve (https://github.com/mickelson/attract), but i think it mainly uses SFML for it's graphics and don't think it sets anything up itself

[Gavinmc42]

But i'm a windows delphi developper and no C / C++ developper

I use Ultibo, a Free Pascal based tool for baremetal Pi's.
Trying to figure this out so one day I can use it on a Pi4.

C dependencies can cause issues.
That kmscube needed a gstreamer lib.
kms-quads looks simpler.

I'm trying C first then Python, maybe Rust and then Free Pascal.
Mesa3D based code is about as open source as it gets.
So I am always compiling the mesa demos to see what works and what does not.
They are a bit dated, the Red book examples are in it but not much OpenGLES 3.0 code
Newer Android GLES 3.1 examples are Java based.

While I have test lots of OpenGL stuff on Pi4's, I have less knowledge of OpenGLES.
OpenGL is going to be stuck at 2.1 for some time but OpenGLES 3.1 has some cool stuff from OpenGL 4.3+.
Those Compute Shaders are calling me, Tim's Shadertoy examples might get the Python treatment.

I have even less knowledge of EGL.
I thinking of learning all those OpenGLES3.0 book examples first.
So much to learn.

Hmm I wonder how close this is to getting 3D working with baremetal Circle.
Hmm RusPiRo has made some progress, that Rust DRM example could be useful.

[drgeoffathome]

I had a quick look at that smfl-pi source code and for a developer that understood both SFML and KMS/DRM, my finger in the breeze estimate is that it might only be a days work. If you understand neither code base but do know C then I reckon it might be a week or two. If you don't know C but are an experienced developer then it might be a month or two full time. That's my 2 cents of guesswork.

how hard would it be to add KMS / DRM support to SFML-PI from attract mode repo ? I think that's basically all that's needed to get attract mode running outside X. But i'm a windows delphi developper and no C / C++ developper. I have tried hacking up some code but i seem to get nowhere. From what i see there is a seperate dir for RPI that probably needs a few small modifcations for kms to work (initialize drm / gbm) etc. While i can probably hack that up i don't see how i can get it to interface with the rest of the library and my code was crap. Currently that library still hardlinks to bcrm files and headers so won't work on a pi4 outside x. but from what i could see there aren't that many changes to be done except initializing the drm / krm and doing the swap buffer thing.

see here https://github.com/mickelson/sfml-pi/tr ... Window/RPi
or here for the complete repo https://github.com/mickelson/sfml-pi/

is anyone up for trying to get that library to work with DRM / KMS as i can't do it myselve. Besides having the SFML library be able to run outside X (as thats what sfml-pi version was created for in first place) it would also make a lot of people happy trying to get attract mode (some front end like emulation station) working outside X. Although to be honest i have not looked at the attract code itselve (https://github.com/mickelson/attract), but i think it mainly uses SFML for it's graphics and don't think it sets anything up itself

[Gavinmc42]

Can vaguely remember coming across SFML before.
Hmm install Code:Blocks then the SFML SDK?
Looks like OpenGL only?
Anyway it should just run on a Pi4, worth some play time on it over the weekend.
Rats, only fragment and vertex shaders.

Is it x86 only?
src is Android, iOS, Windows?
On first look, no Arm or Aarch64 Linux.
Aarch64 buried in the Android code, but Android use a different Graphics method.
I don't hold high hopes for SFML, perhaps that's why I forgot about it?

[PeterO]

Can vaguely remember coming across SFML before.
Hmm install Code:Blocks then the SFML SDK?
Looks like OpenGL only?
Anyway it should just run on a Pi4, worth some play time on it over the weekend.
Rats, only fragment and vertex shaders.

Is it x86 only?
src is Android, iOS, Windows?
On first look, no Arm or Aarch64 Linux.
Aarch64 buried in the Android code, but Android use a different Graphics method.
I don't hold high hopes for SFML, perhaps that's why I forgot about it?

Did you follow the link to the Pi port ? https://github.com/mickelson/sfml-pi/

PeterO

[Gavinmc42]

Did you follow the link to the Pi port ? https://github.com/mickelson/sfml-pi/

Yes I did, then went to the SFML pages to remember why it sounded familiar and why I had ruled it out years ago.
But that was then and now we have Pi4.

I have found if it is C code based Linux code and has make or cmake then more than likely it will just compile for aarch64.
Graphics, if not OpenGL is more trouble, a bit beyond my current skill level.
Which is why I'm leaning OpenGLES , DRM etc.
I want to use the VC6 at it's current capability, that means Compute Shaders.

If I was going to spend time fixing stuff then it would be Irrlicht.
That is already being used in some games I'm interested in and could use fixing/updating for Pi4's.
I probably spend 90% of my time looking for stuff that works without spending 90% of my time getting it working.
Low hanging fruit picking? No need for big ladder of skills I lack.