Thread from Pi4 discussion

[dividuum]

X isn't essential. Kodi for example runs as a fullscreen app.

Any hint where to look at? I guess this is the GBM part? Is there any minimal example that shows how to set up a GL surface similar to how it worked with the legacy drivers?

When opening a surface like that, I guess that's still on its own dispmanx layer? Is it possible to create a transparent GL surface and render on top of video content? I'm not a user of Kodi, but I guess its UI is above the video as well, so that should be possible, correct?

[PeterO]

As promised...
https://github.com/PeterOGB/openGLES
PeterO

[dom]

hmm I am having some issues, just trying to get gles2.0 projects that work on Pi3's to run.

Are there dispmanx calls in there being passed to EGL?
If so that's not how you do it with mesa libs.
The native window given to EGL needs to be an X window handle.,

[dom]

Any hint where to look at? I guess this is the GBM part? Is there any minimal example that shows how to set up a GL surface similar to how it worked with the legacy drivers?

When opening a surface like that, I guess that's still on its own dispmanx layer? Is it possible to create a transparent GL surface and render on top of video content? I'm not a user of Kodi, but I guess its UI is above the video as well, so that should be possible, correct?

I'm not an expert here. But I believe drmModeAtomicCommit is the key part for creating planes (similar to dispmanx overlays).
This code: https://github.com/xbmc/xbmc/blob/maste ... ic.cpp#L80
is used both for creating the GUI (RGBA layer) and video (YUV) layers.

But a simpler source might be kmscube.
Note: You need to run with /dev/dri/card1 as device. e.g.

Code: Select all

kmscube -D /dev/dri/card1 

[PeterO]

But a simpler source might be kmscube.
Note: You need to run with /dev/dri/card1 as device. e.g.

Code: Select all

kmscube -D /dev/dri/card1 

I've bookmarked that for definite future investigation
PeterO

[dividuum]

But a simpler source might be kmscube.

Thanks a lot. That was exactly what I was looking for. That should be very helpful in porting my code over to the Pi4.

[Brian Beuken]

hmm I am having some issues, just trying to get gles2.0 projects that work on Pi3's to run.

Are there dispmanx calls in there being passed to EGL?
If so that's not how you do it with mesa libs.
The native window given to EGL needs to be an X window handle.,

Im just trying to run my old GLES2.0 demos which indeed use dispmanx, so does that mean there is no backward compatability for OpenGLES2.0 projects? They will all need a more traditional X window system?

[PeterO]

hmm I am having some issues, just trying to get gles2.0 projects that work on Pi3's to run.

Are there dispmanx calls in there being passed to EGL?
If so that's not how you do it with mesa libs.
The native window given to EGL needs to be an X window handle.,

Im just trying to run my old GLES2.0 demos which indeed use dispmanx, so does that mean there is no backward compatability for OpenGLES2.0 projects? They will all need a more traditional X window system?

Yes, I'm just doing the same with my old demos.
PeterO

[Brian Beuken]

Yes, I'm just doing the same with my old demos.
PeterO

Should just be a case of treating it like a traditional linux build? I just have to make sure I'm including the correct mesa libs, not the raspberry libs which only work up to model 3.

[PeterO]

Yes, I'm just doing the same with my old demos.
PeterO

Should just be a case of treating it like a traditional linux build?

There are code changes needed.

I just have to make sure I'm including the correct mesa libs, not the raspberry libs which only work up to model 3.

And to get the xwindow id of the window you are using to pass to egl.
I have example code but I've just found a bug in it and I cant update github until I get home.
PeterO

[Brian Beuken]

And to get the xwindow id of the window you are using to pass to egl.
I have example code but I've just found a bug in it and I cant update github until I get home.
PeterO

This is where I am having issues, I can't get an XWindow

Code: Select all

	x_display = XOpenDisplay(NULL);
	if (x_display == NULL)
	{
		printf("Sorry to say we can't create an Xwindow and this will fail");
	//	return ; // we need to trap this;
	}

this always fails


Here's my full code which I use on all non raspberry systems to work with X11... but can't get an X11 window to instansiate so it fails at the 1st hurdle.. I have not activated the fake GL drivers, so it should be running as a clean system.
I installed Mesa and xorg-dev for X11 ,
I set the lib folder to /usr/lib/arm-linux-gnueabihf to make sure it used the new libs...

But...I can't seem to get that X display to open up.. do I still need to do a BCM_init or something?
so...kinda stuck

Code: Select all

#include  <X11/Xlib.h>
#include  <X11/Xatom.h>
#include  <X11/Xutil.h>

#define EGL_FALSE			0
#define EGL_TRUE			1


static Display* x_display = NULL;

void Graphics::init_ogl(Target_State *state, int width, int height, int FBResX, int FBResY)

{
#define ES_WINDOW_RGB           0
	state->width = width;
	state->height = height;
	eglBindAPI(EGL_OPENGL_ES_API);
	EGLint numConfigs;
	EGLint majorVersion;
	EGLint minorVersion;
	
	EGLDisplay display;
	EGLContext context;
	EGLSurface surface;
	EGLConfig config;
	EGLint contextAttribs[] = { EGL_CONTEXT_CLIENT_VERSION, 2, EGL_NONE, EGL_NONE };

	
	  /* create a native window */
	
	Window root;
	XSetWindowAttributes swa;
	XSetWindowAttributes  xattr;
	Atom wm_state;
	XWMHints hints;
	XEvent xev;
	EGLConfig ecfg;
	EGLint num_config;
	Window win;
	Screen *screen;

	    /*
	     * X11 native display initialization
	     */


	
	x_display = XOpenDisplay(NULL);
	if (x_display == NULL)
	{
		printf("Sorry to say we can't create an Xwindow and this will fail");
		exit (0); // we need to trap this;
	}
	root = DefaultRootWindow(x_display);
	screen = ScreenOfDisplay(x_display, 0);

	
	state->width = width;
	state->height = height;

	swa.event_mask  =  ExposureMask | PointerMotionMask | KeyPressMask | KeyReleaseMask;
	swa.background_pixmap = None;
	swa.background_pixel  = 0;
	swa.border_pixel      = 0;
	swa.override_redirect = true;
	
	win = XCreateWindow(
	    x_display,
		root,
		0,
		0,
		width,
		height,
		0,
		CopyFromParent,
		InputOutput,
		CopyFromParent,
		CWEventMask,
		&swa);
	
	XSelectInput(x_display, win, KeyPressMask | KeyReleaseMask);
	
	xattr.override_redirect = TRUE;
	XChangeWindowAttributes(x_display, win, CWOverrideRedirect, &xattr);
	
	hints.input = TRUE;
	hints.flags = InputHint;
	XSetWMHints(x_display, win, &hints);
	
	
	char* title = (char*)"x11 window Maze3dHunt";
	    // make the window visible on the screen
	XMapWindow(x_display, win);
	XStoreName(x_display, win, title);

	    // get identifiers for the provided atom name strings
	wm_state = XInternAtom(x_display, "_NET_WM_STATE", FALSE);
	
	memset(&xev, 0, sizeof(xev));
	xev.type                 = ClientMessage;
	xev.xclient.window       = win;
	xev.xclient.message_type = wm_state;
	xev.xclient.format       = 32;
	xev.xclient.data.l[0]    = 1;
	xev.xclient.data.l[1]    = FALSE;
	XSendEvent(
	  x_display,
		DefaultRootWindow(x_display),
		FALSE,
		SubstructureNotifyMask,
		&xev);
	

	state->nativewindow = (EGLNativeWindowType) win;
	
	// Get Display	
	display = eglGetDisplay(EGL_DEFAULT_DISPLAY);
	if (display == EGL_NO_DISPLAY)
	{
		return; // EGL_FALSE;
	}
	
		
	// Initialize EGL
	if (!eglInitialize(display, &majorVersion,&minorVersion))
	{
	
		printf("Sorry to say we have an EGLinit error and this will fail");
		EGLint err = eglGetError();
		return;// EGL_FALSE;
	}

	// Get configs
	if (!eglGetConfigs(display, NULL, 0, &numConfigs))
	{
		printf("Sorry to say we have EGL config errors and this will fail");
		EGLint err = eglGetError();
		return;// EGL_FALSE;
	}

	// Choose config
	if (!eglChooseConfig(display, attribute_list, &config, 1, &numConfigs))
	{
		printf("Sorry to say we have config choice issues, and this will fail");
		EGLint err = eglGetError();
		return;// EGL_FALSE;
	}


	
	
	// Create a surface
	
	
	surface = eglCreateWindowSurface(display, config, state->nativewindow, NULL);
	if (surface == EGL_NO_SURFACE)
	{
		EGLint err = eglGetError();
		return;// EGL_FALSE;
	}

	// Create a GL context
	context = eglCreateContext(display, config, EGL_NO_CONTEXT, contextAttribs);
	if (context == EGL_NO_CONTEXT)
	{
		EGLint err = eglGetError();
		return;// EGL_FALSE;
	}

	// Make the context current
	if (!eglMakeCurrent(display, surface, surface, context))
	{
		EGLint err = eglGetError();
		return;// EGL_FALSE;
	}

	state->display = display;
	state->surface = surface;
	state->context = context;
	
// just for fun lets see what we can do with this GPU		
	printf("This SBC supports version %i.%i of EGL\n", majorVersion, minorVersion);
	printf("This GPU supplied by  :%s\n", glGetString(GL_VENDOR));
	printf("This GPU supports     :%s\n", glGetString(GL_VERSION));
	printf("This GPU Renders with :%s\n", glGetString(GL_RENDERER));
	printf("This GPU supports     :%s\n", glGetString(GL_SHADING_LANGUAGE_VERSION));
	printf("This GPU supports these extensions	:%s\n", glGetString(GL_EXTENSIONS));

	
	
	EGLBoolean GLtest = eglGetConfigAttrib(	display,
		config,
		EGL_MAX_SWAP_INTERVAL, 
		&minorVersion);
	
	EGLBoolean test = eglSwapInterval(display, 1);    // 1 to lock speed to 60fps (assuming we are able to maintain it), 0 for immediate swap (may cause tearing) which will indicate actual frame rate
	// on xu4 this seems to have no effect

	// Some OpenGLES2.0 states that we might need

	glEnable(GL_DEPTH_TEST);
	glDepthFunc(GL_LEQUAL);
	glDepthMask(TRUE);
	glDepthRangef(0.0f, 1.0f);
	glClearDepthf(1.0f);

//these are the options you can have for the depth, play with them?
//#define GL_NEVER                          0x0200
//#define GL_LESS                           0x0201
//#define GL_EQUAL                          0x0202
//#define GL_LEQUAL                         0x0203
//#define GL_GREATER                        0x0204
//#define GL_NOTEQUAL                       0x0205
//#define GL_GEQUAL                         0x0206
//
	glViewport(0, 0, state->width, state->height);
	glClearColor(0.0f, 0.0f, 0.0f, 1.0f);
	glCullFace(GL_BACK);
	if (glGetError() == GL_NO_ERROR)	return ;
	else
		printf("Oh bugger, Some part of the EGL/OGL graphic init failed\n");	
}

[PeterO]

And to get the xwindow id of the window you are using to pass to egl.
I have example code but I've just found a bug in it and I cant update github until I get home.
PeterO

This is where I am having issues, I can't get an XWindow

You are running X aren't you ? (Best to check this now )
PeterO

[Brian Beuken]

ok yes I did find an issue, I am building code with VisualGDB and it didn't start X, I had actually disabled it, oops once fixed things progressed a little more but,

Now I am stumped on this

libEGL warning: DRI2: failed to authenticate

which is happening here

Code: Select all

	// Initialize EGL
	if (!eglInitialize(display, &majorVersion,&minorVersion))
	{
	
		printf("Sorry to say we have an EGLinit error and this will fail");
		EGLint err = eglGetError();
		exit(err);         // we need to trap this;
	}

Strangley it does not actually return any error, just the failed to autenticate which is spat out somewhere, it returns true and continues.

But... the good news is the code now runs....

The bad news is, what ran at 60fps on a Pi3 runs at 5fps on a Pi4 ....ermmm does that mean the Mesa libs are emulating everything?

[Emanuele]

libEGL warning: DRI2: failed to authenticate

It looks like it could be an authorization issue. You mention that you are using VisualGDB. I am not familiar with it, but if it starts the executable remotely, this might be the problem.

Have you tried running the generated executable locally? By that I mean logging into your Raspberry Pi using a keyboard attached to it, and starting it from within that session?

[PeterO]

Is there anything in /var/log/Xorg.0.log aboiut DRI2 ?
It should say

Code: Select all

$ grep DRI2 Xorg.0.log 
[    18.264] (II) modeset(0): [DRI2] Setup complete
[    18.265] (II) modeset(0): [DRI2]   DRI driver: vc4
[    18.265] (II) modeset(0): [DRI2]   VDPAU driver: vc4
[    18.486] (II) GLX: Initialized DRI2 GL provider for screen 0
[    18.490] (II) Initializing extension DRI2

Without DRI there is no hardware acceleration!
PeterO

[Brian Beuken]

libEGL warning: DRI2: failed to authenticate

It looks like it could be an authorization issue. You mention that you are using VisualGDB. I am not familiar with it, but if it starts the executable remotely, this might be the problem.

Have you tried running the generated executable locally? By that I mean logging into your Raspberry Pi using a keyboard attached to it, and starting it from within that session?

it does execute remotely VisualGDB is PC based visual Studio plug in which works fine on all other Pi's.
(I did try to use the old EGL_static, with Xwindow, but it failed however it didn't give me the failed to authenticate issue)
I'll try and run it locally from the pi whenI get back to it later tonight.

[Brian Beuken]

Is there anything in /var/log/Xorg.0.log aboiut DRI2 ?
It should say

Code: Select all

$ grep DRI2 Xorg.0.log 
[    18.264] (II) modeset(0): [DRI2] Setup complete
[    18.265] (II) modeset(0): [DRI2]   DRI driver: vc4
[    18.265] (II) modeset(0): [DRI2]   VDPAU driver: vc4
[    18.486] (II) GLX: Initialized DRI2 GL provider for screen 0
[    18.490] (II) Initializing extension DRI2

Without DRI there is no hardware acceleration!
PeterO

indeed, I will look at the logs later.

[dom]

The bad news is, what ran at 60fps on a Pi3 runs at 5fps on a Pi4 ....ermmm does that mean the Mesa libs are emulating everything?

You will get software 3d rendering if you have the legacy firmware driver enabled.
You should have fkms driver enabled (dtoverlay=v3d-fkms-vc4 in config.txt)
It is enabled by default on Pi4, and can be enabled with raspi-config on Pi2/3.

[pik33]

Something is wrong with the hardware openGL in RPi4 at least with glxgears

When dtoverlay=v3d-fkms-vc4 is enabled, I have this:

[ 9.839] (II) modeset(0): [DRI2] Setup complete
[ 9.840] (II) modeset(0): [DRI2] DRI driver: vc4
[ 9.840] (II) modeset(0): [DRI2] VDPAU driver: vc4
[ 10.093] (II) GLX: Initialized DRI2 GL provider for screen 0
[ 10.097] (II) Initializing extension DRI2

and then glxgears runs at 60 fps in the default small window and 40 fps in the maximized window (@1920x1200)

When this dtoverlay is disabled, I got this in log:

[ 9.065] (II) AIGLX: Screen 0 is not DRI2 capable
[ 9.467] (II) Initializing extension DRI2

and glxgears run at ~450 fps in the default window and 45 fps in the maximized window.

[PeterO]

There is something wrong with the synchronization with frame blanking which might be causing this as well. Frame buffer swaps are not happening at the right time.
https://www.raspberrypi.org/forums/view ... 5#p1489053

PeterO

[rpiMike]

With the FKMS GL Driver enabled, glxgears synchronises to the vertical refresh rate. With the legacy driver glxgears does not.

[pik33]

With the FKMS GL Driver enabled, glxgears synchronises to the vertical refresh rate. With the legacy driver glxgears does not.

And this is only difference. 40 fps hardware accelerated instead of 45 fps non accelerated due to vblank synchronization. No traces of acceleration.

[PeterO]

Yes, but it should be able to render a full sized glxgears at 60 fps and not drop down below that. I wonder if it sometimes misses a frame sync and effectively syncs to every other frame ?

PeterO

[6by9]

Yes, but it should be able to render a full sized glxgears at 60 fps and not drop down below that. I wonder if it sometimes misses a frame sync and effectively syncs to every other frame ?

There was a tweak to the code surrounding exactly when the update is submitted to the hardware.
https://github.com/raspberrypi/firmware/issues/1154
https://github.com/raspberrypi/firmware ... 4968e44af5

[PeterO]

Yes, but it should be able to render a full sized glxgears at 60 fps and not drop down below that. I wonder if it sometimes misses a frame sync and effectively syncs to every other frame ?

There was a tweak to the code surrounding exactly when the update is submitted to the hardware.
https://github.com/raspberrypi/firmware/issues/1154
https://github.com/raspberrypi/firmware ... 4968e44af5

Is this fix available ? That page mentions "bump to 4.19.56 #1" but that doesn't seem to be available yet,
PeterO