Full screen OpenGL ES on Pi 4

[jdonald]

Try setting up

Code: Select all

sudo apt install apt-file && sudo apt-file update

then

Code: Select all

apt-file search xf86drm.h

I'm not logged into a Pi at the moment, but x86_64 Debian Buster is probably the same in this case and apparently the header is part of libdrm-dev

[alanbork]

wow that's handy! thanks!

[6by9]

Try setting up

Code: Select all

sudo apt install apt-file && sudo apt-file update

then

Code: Select all

apt-file search xf86drm.h

I'm not logged into a Pi at the moment, but x86_64 Debian Buster is probably the same in this case and apparently the header is part of libdrm-dev

Ooh, useful tool. You're never too old to learn something new (but sometimes you promptly forget it again!)

[dom]

I'm trying to do the same thing but getting stopped at an earlier point: #include <xf86drm.h>

what should I apt-get to install the proper version of DRM? all the copies I can find on the internet are incredibly generic and seem very unlikely to properly target the pi hardware.

The whole point of moving to DRM is what you do becomes generic rather than Pi specific.
Instructions for debian linux (including ubuntu) are quite likely to work.

[alanbork]

Good to know. The answer BTW is libdrm-dev.

It seems like the DRM implementation on the Pi isn't quite ready for prime time, though? Everything I render at 0,0 is shifted down; 20 pixels from the top of the screen in 720p, about 200 pixels in 480p. Same code (generic examples from RAYLIB) work perfectly in the pi zero. Anybody else seen a similar issue?

[6by9]

It seems like the DRM implementation on the Pi isn't quite ready for prime time, though? Everything I render at 0,0 is shifted down; 20 pixels from the top of the screen in 720p, about 200 pixels in 480p. Same code (generic examples from RAYLIB) work perfectly in the pi zero. Anybody else seen a similar issue?

Have you disabled overscan?

[alanbork]

It seems like the DRM implementation on the Pi isn't quite ready for prime time, though? Everything I render at 0,0 is shifted down; 20 pixels from the top of the screen in 720p, about 200 pixels in 480p. Same code (generic examples from RAYLIB) work perfectly in the pi zero. Anybody else seen a similar issue?

Have you disabled overscan?

using raspi-config I've tried both with and without over-scan. Note that the framebuffer console doesn't have the same issue - it's only once GL is controlling the display.

[6by9]

using raspi-config I've tried both with and without over-scan. Note that the framebuffer console doesn't have the same issue - it's only once GL is controlling the display.

OK, one thing eliminated. So what code are you actually running?
The DRM driver is working pretty well for all use cases so far.

[alanbork]

I'm using RAYLIB ported to the pi 4 (https://github.com/jonlidgard/raylib/tree/rpi4). Any demo causes the problem so it's something about the port that's causing the problem.

One thing I notice: if I clear the entire buffer to a single color then the border along the top is filled with that color. But If I just draw a texture that fits the exact dimensions of the screen, then the border instead flickers (as though the two buffers I'm using have been initialized to black and white, respectively) every time I trigger a buffer flip.

[6by9]

Pi4, so presumably you're using vc4-fkms-v3d.

"vcgencmd dispmanx_list" will list out the planes that the firmware thinks it is displaying, along with the source and destination rectangles. Please report back what that says is being rendered.
There is an underlying issue with VSYNC in FKMS so you may just be seeing tearing where you've started to update the frame you think is off the display but isn't yet.

[alanbork]

Yes:

dtoverlay=vc4-fkms-v3d
max_framebuffers=2
hdmi_force_hotplug=1
hdmi_group=2
hdmi_mode=81

"vcgencmd dispmanx_list" will list out the planes that the firmware thinks it is displaying, along with the source and destination rectangles. Please report back what that says is being rendered.
There is an underlying issue with VSYNC in FKMS so you may just be seeing tearing where you've started to update the frame you think is off the display but isn't yet.

proper VSYNC is critical to my use case, which is measuring input lag in the monitor: https://alantechreview.blogspot.com/202 ... berry.html

Are you saying that VSYNC timing is not reliable in FKMS?

[tombsar]

Are you saying that VSYNC timing is not reliable in FKMS?

Unfortunately that does seem to be the case. I found I was unable to eliminate tearing on the RPi4, and found this post from an Engineer 6by9 saying it's a known issue. viewtopic.php?p=1583405#p1583405

[alanbork]

So I think I'm running into driver "bugs" or at least different behavior than in the pie zero. Here's how to make it work properly: use raspi-config to set your monitor resolution and reboot. What I was doing was using a script to set the resolution at the command line without rebooting. Here's an example:

tvservice -e "cea 2"
sleep .5
fbset 640x480-60 -yres 460
sleep .5
fbset -depth 8 & fbset -depth 16
tvservice -s

note that in raylib in 480p the drawing buffer is offset about 200 pixels down. So it's not just my yres argument that's the issue here. I set yres to 460 so that any cropping of the display wouldn't leave the prompt hidden.

Remaining issue now that that's fixed: I'm getting odd buffer flip behavior. I think it might be vsync related as you mentioned. sometimes frames are rendered out of order or at odd times relative to SwapBuffers(). it only happens when there's moderate out of thread load (specifically, I'm writing ~10k of data to disk, but fflush() is called before swapbuffers. worked fine on the pi zero, which is a single core, slower cpu...).

Are you saying that VSYNC timing is not reliable in FKMS?

Unfortunately that does seem to be the case. I found I was unable to eliminate tearing on the RPi4, and found this post from an Engineer 6by9 saying it's a known issue. viewtopic.php?p=1583405#p1583405

[dom]

vsync issues are unlikely to be fixed on fkms (the api's involved just don't provide enough precision).
Development is focused on the kms driver, so if this is important to you then it's best to test that.
See the 5.4 kernel/kms test thread.

[alanbork]

vsync issues are unlikely to be fixed on fkms (the api's involved just don't provide enough precision).
Development is focused on the kms driver, so if this is important to you then it's best to test that.
See the 5.4 kernel/kms test thread.

Bummer. That means the end of CLI graphics support on the Pi4? Having read that thread and googled it I'm not 100% convinced that's correct but it sure seems like it.

[dom]

Bummer. That means the end of CLI graphics support on the Pi4? Having read that thread and googled it I'm not 100% convinced that's correct but it sure seems like it.

No idea what you mean. There is zero difference to the applications supported whether you are running fkms or kms.
What do you mean by CLI graphics? non-desktop? kodi runs outside of desktop just fine with kms. Similarly demo apps like kms-cube.

[alanbork]

sorry, I myself am confused. But apps that use dispmanx at the least, can't use kms, correct? So it's not a 100% drop in replacement. Is there somewhere where all this is summarized? All I can find are a lot of posts on this board of various vintages and conflicting info.

[dom]

We are trying to move away from proprietary APIs like dispmanx that only work on a Pi, to using standard linux APIs like DRM that should work on a range of linux platforms.

This means moving the display system from the closed source firmware to the open source kernel.
The fkms driver was a halfway-house where you could use the new linux drm APIs, but display calls were just remoted to be handled by the firmware.
The kms driver has always been the longer term goal, where the kernel handles the display hardware directly.

As such, with the kms driver, the firmware cannot use the display, so anything that writes to the display through the firmware won't work.
That is mainly dispmanx and tvservice, and that includes components that use dispmanx like video_render (through mmal or openmax).

fkms and kms should be interchangeable when using the standard linux APIs described in this thread.
Using opengl on a Pi4 hasn't ever been possible through dispmanx.

If you are talking about non-opengl dispmanx users, then yes, that is deprecated and will never be available with kms driver.