OpenGL on Buster on both Pi 3 and Pi 4

[PeterO]

Thanks Peter, and James et al, I know I was a pain, but I got there in the end.

We got you there in the end, that's what matters
Have Fun .
PeterO

[Gavinmc42]

Post pics,
Someone needs to benchmark OpenGLES3 on the Pi4's

[ayaromenok]

Device: V3D 4.2 (0xffffffff)

Good to know, that you find a solution.

What I am worry - it's a displayed device number

Code: Select all

0xffffffff

- it's shouldn't be like this.

Erick Anhold (from Broadcom) working on V3D drivergallium for a while for Videocore V, but it's no info about VI. And it is no compute shaders(GLES 3.1 or GL 4.2+Ext/4.3) in V3D 4.2 driver, as well it's no OpenCL or Vulkan driver too (I can see in the driver sources some debug defines, which can be a stubs for CS/CL).

So looks like current driver(V3D 4.2) just a temporary stub and not use all features of VideoCore VI.

upd: Compute Shaders compilation branch was integrated to master in 20190412 - so can be found in Mesa commit (6b1c6598) - for OpenGL ES 3.1 only (and not a OpenCL) - so sooner or later it will be in driver(and, which is more important, VC VI hardware can support OpenCL\Vulkan).

[Brian Beuken]

Thanks Peter, and James et al, I know I was a pain, but I got there in the end.

We got you there in the end, that's what matters
Have Fun .
PeterO

yes you did...thanks.

[Brian Beuken]

upd: Compute Shaders compilation branch was integrated to master in 20190412 - so can be found in Mesa commit (6b1c6598) - for OpenGL ES 3.1 only (and not a OpenCL) - so sooner or later it will be in driver(and, which is more important, VC VI hardware can support OpenCL\Vulkan).

Pretty sure its a work in progess... Getting ES2.0/3.0 up and running 1st then 3.1/3.2
Compute shaders are nice things to have but given the lack of cores on a Pi, its hard to see what you can really make them do that will really give a benefit to anyone. But I'm still excited to try.

Good to note there is work being done though and they will probably be available soon. I guess in a year we'll all be posting how do I get Vulkan to work requests

[Gavinmc42]

Good to note there is work being done though and they will probably be available soon. I guess in a year we'll all be posting how do I get Vulkan to work requests

Sakaki has got pics of 1st spin of Gentoo64 on a Pi4
I found OpenGL worked really well on Gentoo64 on Pi3B+.
Been playing with OpenGL games on Pi4, gameplay is ok but OpenGL needs tweaking.

Vulkan looks like it would be easier to do on ARMv8.
Get working on ARMv8 first.

Broadcom does a lot of settop box stuff.
Vulkan is usable for settop box UI's.
Broadcom Vulkan driver for VC6?

This Pi4 is looking very interesting but more info needed.

[Brian Beuken]

Post pics,
Someone needs to benchmark OpenGLES3 on the Pi4's

Sure...


This is a test GLES2.0 project running animated (shader interpolated) MD2 models in a simple maze, with shadows and lighting (currently disabled), it also runs Bullet Physics and in this debug image is showing the bounding areas for collision tests.

On a 3B/B+ I run this full screen at 1080p with a render buffer usually half size, but sometimes 3/4, and it renders at 50-60fps. The graphic code is unoptimised which gives my students a chance to find ways to improve performance. An optimised version of this can run at up to 80fp if needed.

On Pi4 using X11 windows I have 1080p resolution as well as a 1080p render buffer so its pushing a lot more pixels and currently it struggles a bit at 20fps.. If it were rendered with OpenGLES3.0 features such as instancing it should run 20-30% faster but I've not done much work on that yet.
Not bad for what is designed to be an stressful intense poly shifter but I was hoping for better. I need to see if I can get X11 to reduce the size of its renderbuffer. just changing the viewport isn;t doing it, so I need to research more, and also investigate DRM which is new to me.
Im a game console coder normally so the EGL/DispmanX/X11 setup process is a black art to me but I am getting my head around some of it.

[PeterO]

Good to note there is work being done though and they will probably be available soon. I guess in a year we'll all be posting how do I get Vulkan to work requests

Sakaki has got pics of 1st spin of Gentoo64 on a Pi4
I found OpenGL worked really well on Gentoo64 on Pi3B+.
Been playing with OpenGL games on Pi4, gameplay is ok but OpenGL needs tweaking.

Vulkan looks like it would be easier to do on ARMv8.
Get working on ARMv8 first.

Broadcom does a lot of settop box stuff.
Vulkan is usable for settop box UI's.
Broadcom Vulkan driver for VC6?

This Pi4 is looking very interesting but more info needed.

Your brain dumps really don't mean anything to anyone other than yourself !
PeterO

[Gavinmc42]

Your brain dumps really don't mean anything to anyone other than yourself !

Yep but google will find it in a year and I will remember and go "hey, we can do that now."
What gets really annoying is google finding I did that 6months ago
Not sure if it is old age or memory leakage or you guys triggering ideas.

[Gavinmc42]

Is anyone not getting 60fps on glxgears?

[jamesh]

Good to note there is work being done though and they will probably be available soon. I guess in a year we'll all be posting how do I get Vulkan to work requests

Sakaki has got pics of 1st spin of Gentoo64 on a Pi4
I found OpenGL worked really well on Gentoo64 on Pi3B+.
Been playing with OpenGL games on Pi4, gameplay is ok but OpenGL needs tweaking.

Vulkan looks like it would be easier to do on ARMv8.
Get working on ARMv8 first.

Broadcom does a lot of settop box stuff.
Vulkan is usable for settop box UI's.
Broadcom Vulkan driver for VC6?

This Pi4 is looking very interesting but more info needed.

Your brain dumps really don't mean anything to anyone other than yourself !
PeterO

It's getting to the point where I might have to start 'curating' some of this stuff. Note, writer has been warned about this. This sort of post helps no-one.

[cbratschi]

I am trying to get aminogfx-gl to run on Pi 4 but the OpenGL ES 2 code hangs while swapping buffers and afterwards a reboot is needed to use OpenGL again. Otherwise it hangs on EGL init.

https://github.com/cbratschi/aminogfx-gl

The same code works fine on Pi 3.

While reading this thread I thought the previous VideoCore and DispmanX APIs will no longer work but no code modifications were required so far.

Currently debug output is active in the project in case someone wants to try it.

[paddyg]

@Brian_Beuken, is the screen shot above from the RPi4? I can't get lines or points to render so I would be keen to see how you are doing it, if the code is available to view somewhere.

Paddy

[aire39]

Is it possible to use the new driver headless or without a monitor hooked up? I cannot get it to work without hooking up a monitor to the pi4.

export DISPLAY=:0 will only work when I have a monitor initially hooked up to the pi4.


Also is openVG not available support in the new driver?

[6by9]

Is it possible to use the new driver headless or without a monitor hooked up? I cannot get it to work without hooking up a monitor to the pi4.

export DISPLAY=:0 will only work when I have a monitor initially hooked up to the pi4.

The display stack parses the EDID of the connected display to know the supported modes, therefore in the absence of an EDID/hotplug you get no display.
Add "hdmi_edid_file=1" and put the EDID of the display you want in /boot/edid.dat (save it with "tvservice -d edid.dat").
I suspect you want "hdmi_ignore_hotplug=1" as well to make it not look for the hotplug line either. Try without first though.

Also is openVG not available support in the new driver?

Not directly
https://www.raspberrypi.org/forums/view ... 3&t=245380

[aire39]

6x9 wrote:

The display stack parses the EDID of the connected display to know the supported modes, therefore in the absence of an EDID/hotplug you get no display.
Add "hdmi_edid_file=1" and put the EDID of the display you want in /boot/edid.dat (save it with "tvservice -d edid.dat").
I suspect you want "hdmi_ignore_hotplug=1" as well to make it not look for the hotplug line either. Try without first though.

Great! Exactly what I was looking for!

6x9 wrote:

aire39 wrote:
Also is openVG not available support in the new driver?

Not directly
https://www.raspberrypi.org/forums/view ... 3&t=245380

That's fine. Thanks for the heads up.

Also is the path from a mmal opaque buffer to a egl image still available?
eglCreateImageKHR(egl_display, EGL_NO_CONTEXT, EGL_IMAGE_BRCM_MULTIMEDIA, video_data, nullptr);

I would be able to create an EglImage from the opaque pointer giving by mmal and treat it as a opengl external texture and I'm not sure if that
is still possible. Any insight into that. Do the BRCM specific enums still work with the new driver?

[6by9]

Also is the path from a mmal opaque buffer to a egl image still available?
eglCreateImageKHR(egl_display, EGL_NO_CONTEXT, EGL_IMAGE_BRCM_MULTIMEDIA, video_data, nullptr);

I would be able to create an EglImage from the opaque pointer giving by mmal and treat it as a opengl external texture and I'm not sure if that
is still possible. Any insight into that. Do the BRCM specific enums still work with the new driver?

No. The firmware driver and MMAL were using handles from VCSM (VideoCore Shared Memory). The V3D driver has no knowledge of this.

What it does understand are Linux dmabufs. There is an updated version of vcsm that supports exporting dmabufs, and these can then be imported into DRM or GL.
https://github.com/6by9/drm_mmal/tree/x11_export should have all the required hooks to do it. You need to use meson/ninja to build it.

Code: Select all

      meson build/
      ninja -C build/
      sudo ninja -C build/ install

(not that it really needs installing, just run it from build).

[Technocolour]

This is a test GLES2.0 project running animated (shader interpolated) MD2 models in a simple maze, with shadows and lighting (currently disabled), it also runs Bullet Physics and in this debug image is showing the bounding areas for collision tests.

On a 3B/B+ I run this full screen at 1080p with a render buffer usually half size, but sometimes 3/4, and it renders at 50-60fps. The graphic code is unoptimised which gives my students a chance to find ways to improve performance. An optimised version of this can run at up to 80fp if needed.

On Pi4 using X11 windows I have 1080p resolution as well as a 1080p render buffer so its pushing a lot more pixels and currently it struggles a bit at 20fps.. If it were rendered with OpenGLES3.0 features such as instancing it should run 20-30% faster but I've not done much work on that yet.
Not bad for what is designed to be an stressful intense poly shifter but I was hoping for better. I need to see if I can get X11 to reduce the size of its renderbuffer. just changing the viewport isn;t doing it, so I need to research more, and also investigate DRM which is new to me.
Im a game console coder normally so the EGL/DispmanX/X11 setup process is a black art to me but I am getting my head around some of it.

Neat!

It would be interesting to me if you could compare the performance in DRM to X11.

[bunklung]

I am a bit confused. All the reviews state Open Arena gets about 40fps in 720 resolution.

Am I doing something wrong here? Out of the box I think I get 2-5 fps. What is everyone doing to get 40fps?

My glxinfo looks good going by this thread. Do I need to install a different package? Do I need to tweak my video memory?

[Gene1934]

Coming to this party a bit late, I have a pi3 that been running LinuxCNC with a realtimepi self built stretch kernel. Everything runs fine except the video is glacial, like glxgears pulled out to a full 1920x1080 screen is about 1.7 fps.

But buster 10.1 & .2 has new video drivers and can do that same full screen glxgears at better than 50 fps on this same pi3., but without the required preempt-rt kernel to run my LinuxCNC app..

How do I go about building a preemp-rt kernel image preferably with RealtimePi, that doesn't use an older 4.14.y kernel that ignores the new video, and still does glxgears at 1.7 fps on this pi3? BTDT. I have a pi4, but so far haven't managed to make the spi work. Folks have made the ethernet version of the mesa interface cards work, but that preempts my ability to put eth0 on my local network and demands I spend another $250 or so for different interfacing hardware which explains my reticence to march in that direction.

Thanks folks for any guidance.

[duicleme]

So... what a say... I'm just want to used openGL
But VC example rpi4 Not easy
I think. May be It's easy something but It's hard something.
mesa something
V3D something
EGL 3.0 something

Kernel module / driver and library update needed

[jamesh]

So... what a say... I'm just want to used openGL
But VC example rpi4 Not easy
I think. May be It's easy something but It's hard something.
mesa something
V3D something
EGL 3.0 something

Kernel module / driver and library update needed

On the Pi4, using OpenGL should be the same as any other platform as we have moved to the completely standard MESA and DRM libraries and away from the proprietary stack on the Pi3 and earlier.

So what exactly is the problem?

[Gavinmc42]

But VC example rpi4 Not easy

VC4 examples won't work on Pi4 VC6.

Normal OpenGL examples works pretty good on the Pi4.
Try the Mesa3D demo examples.
Many OpenGL tutorials examples should work depending on the libraries.
FreeGLUT is not bad.