dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5227
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

New experimental GL driver configuration

Wed Sep 14, 2016 8:13 pm

Currently the experimental GL driver is a kms/v3d driver.
The kms part is related to driving the display and the v3d part is related to driving the 3D hardware.

While this is the correct behaviour for a standard linux platform, and is the eventual goal for the 3D driver, it is currently an obstacle for many users.

The standard camera and video decode apps that drive the display from the gpu cannot be used when vc4-kms-v3d is enabled.
Apps that use dispmanx for overlays or performance reasons (e.g. emulators) cannot be used.
The official DSI display is not currently supported.
HDMI displays are configured differently and may not behave the same way.

So Eric has added a new mode to the driver. If you enable the usual vc4-kms-v3d driver (e.g. from raspi-config) and then edit the vc4-kms-v3d overlay to:

Code: Select all

dtoverlay=vc4-fkms-v3d
you will end up with Eric's arm side v3d driver, supporting desktop GL from X, but using the original firmware for the kms part.
This means that tvservice, dispmanx, omxplayer(*), raspivid etc should work as before, but you can also run desktop GL apps from X.

The one thing you cannot do with this driver is use firmware side 3D. This includes OpenVG which uses the 3D hardware from the firmware side.

To test this you will need the latest rpi-update firmware.

(*) By default omxplayer uses OpenVG for subtitles and status messages which is not compatible with this driver. Launch with "--no-osd" and it can be used for video playback.

User avatar
kusti8
Posts: 3441
Joined: Sat Dec 21, 2013 5:29 pm
Location: USA

Re: New experimental GL driver configuration

Wed Sep 14, 2016 8:22 pm

This is great news! Well done!
There are 10 types of people: those who understand binary and those who don't.

cjan
Posts: 694
Joined: Sun May 06, 2012 12:00 am

Re: New experimental GL driver configuration

Thu Sep 15, 2016 3:04 am

kusti8 wrote:This is great news! Well done!
and, what about chromium-51 beta?

User avatar
kusti8
Posts: 3441
Joined: Sat Dec 21, 2013 5:29 pm
Location: USA

Re: New experimental GL driver configuration

Thu Sep 15, 2016 10:14 am

cjan wrote:
kusti8 wrote:This is great news! Well done!
and, what about chromium-51 beta?
:?:
There are 10 types of people: those who understand binary and those who don't.

cjan
Posts: 694
Joined: Sun May 06, 2012 12:00 am

Re: New experimental GL driver configuration

Thu Sep 15, 2016 10:20 am

kusti8 wrote:
cjan wrote:
kusti8 wrote:This is great news! Well done!
and, what about chromium-51 beta?
:?:
youtube did not work anymore.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5227
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: New experimental GL driver configuration

Thu Sep 15, 2016 10:26 am

cjan wrote:youtube did not work anymore.
You'll have to give a lot more information if you want anything fixed.
Explain exactly what you have done and exactly how things failed.

cjan
Posts: 694
Joined: Sun May 06, 2012 12:00 am

Re: New experimental GL driver configuration

Thu Sep 15, 2016 10:26 pm

dom wrote:
cjan wrote:youtube did not work anymore.
You'll have to give a lot more information if you want anything fixed.
Explain exactly what you have done and exactly how things failed.
do nothing
1. rpi-update
2. raspi-config -> emable GL -> config.txt -> dtoverlay=vc4-fkms-v3d
3. chromium-51 BETA can not play youtube, got FC error.

ps. even update to chromium-51.7000.

pucgenie
Posts: 2
Joined: Mon Sep 26, 2016 6:40 am
Location: Wien, Österreich (Vienna, Austria)

Re: New experimental GL driver configuration

Mon Sep 26, 2016 7:55 pm

What are the downsides of vc4-fkms-v3d ?
Before I've seen this forum I've reverted my RPi2 back to not using the vc4-kms-v3d GL driver because of omxplayer (did not work using vc4-kms-v3d as stated in the first post). Sadly, now another software/game (stepmania) which was slow without any GL driver is non-working after switching to vc4-fkms-v3d .
It is obvious that that game does not work without tweaking its own code (just compiled it using Debian stretch armhf gcc-6.1.1 with lots of mathematically unsafe optimization options), but ... it was already running at about 20 frames per second using vc4-kms-v3d (about 2 FPS without any of the two GL driver modes).
Using vc4-fkms-v3d it seems to block somewhere at querying the opengl driver information. Switching out of X by pressing ctrl+F1 and then pressing ctrl+C is immediately followed by appearance of the expected last part of graphics information shown in console / log output - I'll try to debug where exactly the game pauses before rendering (I think there is some 3D code involved...) if it would be useful information for you GL driver coders.
Followed these steps:
cjan wrote:do nothing
1. rpi-update
2. raspi-config -> enable GL [3.] -> config.txt -> dtoverlay=vc4-fkms-v3d
4. reboot
5. xinit /path/to/stepmania (configured to 1280x720 32bit @ auto framerate)

Without restarting I tried to start minecraft-pi (without X server) - now neither keyboard nor SSH works - it just froze completely.

EDIT: neverball works perfectly.

Please delete my post if it is not providing any relevant information. Thank you very much for developing drivers and for ignoring never-touch-a-running-system for performance' sake!
Attachments
rpi_sm_log.gz
(5.51 KiB) Downloaded 177 times
Last edited by pucgenie on Wed Oct 05, 2016 8:22 pm, edited 1 time in total.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5227
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: New experimental GL driver configuration

Wed Sep 28, 2016 10:50 am

pucgenie wrote:What are the downsides of vc4-fkms-v3d ?
If you enable either vc4-kms-v3d or vc4-fkms-v3d then no code that uses the Pi's firmware side GL driver (/opt/vc/lib/libGLESv2.so) will work.
However a lot of standard debian packages that use desktop GL will now run.

So, basically anything that used 3D before switching won't run, but lots of new packages will run.
All of the 3D software that currently runs using the firmware side 3D driver required Pi specific changes to make them work.
Those changes need to be removed to make the packages work with the arm side drivers (vc4-kms-v3d or vc4-fkms-v3d).

So far, I'm not aware of any packages that work with vc4-kms-v3d but not vc4-fkms-v3d (but it's always possible).
Can you confirm your vc4-fkms-v3d install is functional by running a package that I've tested?

E.g. "sudo apt-get install neverball" should install a 3d game that should work with vc4-fkms-v3d.

abhisek
Posts: 12
Joined: Mon Sep 26, 2016 5:40 pm

Re: New experimental GL driver configuration

Mon Oct 10, 2016 4:08 am

dom wrote:Currently the experimental GL driver is a kms/v3d driver.
The kms part is related to driving the display and the v3d part is related to driving the 3D hardware.

While this is the correct behaviour for a standard linux platform, and is the eventual goal for the 3D driver, it is currently an obstacle for many users.

The standard camera and video decode apps that drive the display from the gpu cannot be used when vc4-kms-v3d is enabled.
Apps that use dispmanx for overlays or performance reasons (e.g. emulators) cannot be used.
The official DSI display is not currently supported.
HDMI displays are configured differently and may not behave the same way.

So Eric has added a new mode to the driver. If you enable the usual vc4-kms-v3d driver (e.g. from raspi-config) and then edit the vc4-kms-v3d overlay to:

Code: Select all

dtoverlay=vc4-fkms-v3d
you will end up with Eric's arm side v3d driver, supporting desktop GL from X, but using the original firmware for the kms part.
This means that tvservice, dispmanx, omxplayer(*), raspivid etc should work as before, but you can also run desktop GL apps from X.

The one thing you cannot do with this driver is use firmware side 3D. This includes OpenVG which uses the 3D hardware from the firmware side.

To test this you will need the latest rpi-update firmware.

(*) By default omxplayer uses OpenVG for subtitles and status messages which is not compatible with this driver. Launch with "--no-osd" and it can be used for video playback.
Thanks for this info, I don't know whether you are the right person to ask this question or not, but let me try my luck.
With your setting things works fine at my end, but I do face issue while using opencv or I would say a specific method of opencv which is "imshow", screen flickers in between. Any suggestions. All these thing works fine if I disable the GPU. One more update raspivid is working fine with you settings. I am currently using "http://www.uco.es/investiga/grupos/ava/node/40" to use raspicam in my opencv code. Thanks a lot for your time and patience :)

User avatar
hanzelpeter
Posts: 70
Joined: Mon Jul 09, 2012 11:56 am

Re: New experimental GL driver configuration

Tue Mar 28, 2017 11:43 am

Hello.

I enabled v3d-fkms overlay and then started X from command line. It worked, but the the clicking on menu. windows is working weird. There is a shift by overscan pixels I mean. So I need to go to top-left of screen with cursor where nothing is and then when I click it clicks the Xwindow menu.

So I looks like I need to remove overscan. Is it the culprit of a problem?

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5227
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: New experimental GL driver configuration

Tue Mar 28, 2017 12:03 pm

hanzelpeter wrote:So I looks like I need to remove overscan. Is it the culprit of a problem?
Yes, the config.txt overscan settings are not compatible with arm side vc4 driver and should be disabled.

cjan
Posts: 694
Joined: Sun May 06, 2012 12:00 am

Re: New experimental GL driver configuration

Thu Jul 19, 2018 4:17 am

how to setup dtoverlay=vc4-kms-v3d,cma=???
and what does it mean 64 128 256?

User avatar
Gavinmc42
Posts: 2834
Joined: Wed Aug 28, 2013 3:31 am

Re: New experimental GL driver configuration

Thu Jul 19, 2018 7:12 am

64, 128, 256 was used to set GPU memory.
Latest VC4 V3D OpenGL driver does not need it
If you enable OpenGL in raspi-config it will enable the driver and set the GPU mem to 16MB.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

cjan
Posts: 694
Joined: Sun May 06, 2012 12:00 am

Re: New experimental GL driver configuration

Thu Jul 19, 2018 7:43 am

Gavinmc42 wrote:
Thu Jul 19, 2018 7:12 am
64, 128, 256 was used to set GPU memory.
Latest VC4 V3D OpenGL driver does not need it
If you enable OpenGL in raspi-config it will enable the driver and set the GPU mem to 16MB.
setup,
gpu_mem=128
dtoverlay=vc4-kms-v3d,cma-128(no need it?), and got this

* failed to add service - already in use?

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2127
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: New experimental GL driver configuration

Thu Jul 19, 2018 9:38 am

As Gavinmc42 said, use raspi-config to enable the VC4 driver.

SteakSndwich
Posts: 7
Joined: Fri Oct 05, 2018 2:38 pm

Re: New experimental GL driver configuration

Tue Oct 09, 2018 10:07 am

Hello, i am writing here cause i think it fits the best.

I am using dtoverlay=vc4-fkms-v3d to be able to rotate my portrait display (1440x2560 native) into landscape mode

This my topic about the display and the issues i had with it: https://www.raspberrypi.org/forums/view ... 8&t=224229

With the GL driver i can rotate the display using "xrandr -o right". But since the kms/v3d driver is limited to 2048x2048 i have to downscale the resolution (which makes sense anyway since the performance is just not good at full resolution)

But the issue i have is that, even without rotating using xrandr, the mousecursor gets locked to invisible boundaries equal to the selected output resolution.
Eg i put out at 1280x720, the display scales to 2560x1440 which i want, but the mousecursor can only move/is displayed in the top left quarter of the screen. The real position is still all over the display, so i can click everything, i just don't know where my cursor is positioned.

I hope this makes sense.

Is there any workaround known? Am i missing anything kms/v3d driver related in my config.txt?

Edit: Forgot to mention the setup: Raspberry Pi 3 B+ with latest Raspbian

Thank you for any help

Code: Select all

#slight overclock
gpu_freq=500
over_voltage=2

#more gpu mem, 64 is std
gpu_mem=256

#ignore any hdmi mode from display
hdmi_ignore_edid=0xa5000080

#Always put out on hdmi
hdmi_force_hotplug=1

#custom hdmi mode
hdmi_group=2
hdmi_mode=87

#DVI mode, no audio output
hdmi_drive=1

#up the freq limit above std
hdmi_pixel_freq_limit=204792000

#timing of the display
hdmi_timings=1440 1 70 35 45 2560 1 12 2 2 0 0 0 50 0 204792000 3

#Overscan settings
disable_overscan=1

#framebuffer settings
framebuffer_width=1152
framebuffer_height=2048
max_framebuffer_width=1152
max_framebuffer_height=2048

hvs_priority=0x32ff

dtoverlay=vc4-fkms-v3d

eskysh
Posts: 3
Joined: Fri Mar 08, 2013 1:41 am

Resolution of HDMI output sticks to 1280x1024 under GL (Full KMS) mode?

Fri Feb 22, 2019 3:26 am

Dear RPI gurus:

I use latest "2018-11-13-raspbian-stretch-full.img" on my Raspberry Pi Model B(Rev.2). After I enabled GL (Full KMS) through raspi-config tools, I find that HDMI output sticks to 1280x1024. I did try to change resolution by /boot/config.txt entries like hdmi_ignore_edid=0xa5000080 to force a fixed resolution but with no luck.

Is this (fixed resolution)a common case for new experimental GL driver or something went wrong on my side?

Some information of my platform:

Code: Select all

[email protected]:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
[email protected]:~ $ uname -r
4.14.98+
[email protected]:~ $ fbset -i

mode "1280x1024"
    geometry 1280 1024 1280 1024 32
    timings 0 0 0 0 0 0 0
    accel true
    rgba 8/16,8/8,8/0,0/0
endmode

Frame buffer device information:
    Name        :
    Address     : 0x54f00000
    Size        : 5242880
    Type        : PACKED PIXELS
    Visual      : TRUECOLOR
    XPanStep    : 1
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 5120
    Accelerator : No
my config.txt:

Code: Select all

# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

#hdmi_ignore_edid=0xa5000080

# uncomment to force a specific HDMI mode (this will force VGA)
hdmi_group=2
hdmi_mode=87

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
hdmi_drive=1

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

hdmi_cvt 800 480 60 6 0 0 0

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi
dtoverlay=vc4-kms-v3d,cma-128

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5227
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Resolution of HDMI output sticks to 1280x1024 under GL (Full KMS) mode?

Mon Feb 25, 2019 7:01 pm

eskysh wrote:
Fri Feb 22, 2019 3:26 am
I use latest "2018-11-13-raspbian-stretch-full.img" on my Raspberry Pi Model B(Rev.2). After I enabled GL (Full KMS) through raspi-config tools, I find that HDMI output sticks to 1280x1024. I did try to change resolution by /boot/config.txt entries like hdmi_ignore_edid=0xa5000080 to force a fixed resolution but with no luck.
Note: config.txt is parsed by the firmware and display settings have no effect on the Full KMS driver which handles all display setup in the kernel.
You can use the Fake KMS driver which supports arm side 3d but uses firmware for configuring the display and so handles config.txt settings.

With the Full KMS driver you configure the display using standard linux settings.

eskysh
Posts: 3
Joined: Fri Mar 08, 2013 1:41 am

Re: Resolution of HDMI output sticks to 1280x1024 under GL (Full KMS) mode?

Thu Feb 28, 2019 2:34 am

dom wrote:
Mon Feb 25, 2019 7:01 pm
eskysh wrote:
Fri Feb 22, 2019 3:26 am
I use latest "2018-11-13-raspbian-stretch-full.img" on my Raspberry Pi Model B(Rev.2). After I enabled GL (Full KMS) through raspi-config tools, I find that HDMI output sticks to 1280x1024. I did try to change resolution by /boot/config.txt entries like hdmi_ignore_edid=0xa5000080 to force a fixed resolution but with no luck.
Note: config.txt is parsed by the firmware and display settings have no effect on the Full KMS driver which handles all display setup in the kernel.
You can use the Fake KMS driver which supports arm side 3d but uses firmware for configuring the display and so handles config.txt settings.

With the Full KMS driver you configure the display using standard linux settings.
Thanks for clarification.
Could you please explain more about "standard linux settings"? Are they dts/dtb overlays? Is there any online tutorials for how to set HDMI resolution under Full KMS mode?

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5227
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Resolution of HDMI output sticks to 1280x1024 under GL (Full KMS) mode?

Thu Feb 28, 2019 3:16 pm

eskysh wrote:
Thu Feb 28, 2019 2:34 am
Could you please explain more about "standard linux settings"? Are they dts/dtb overlays? Is there any online tutorials for how to set HDMI resolution under Full KMS mode?
I don't typically run with the full kms driver, so others may be able to provide more accurate info, but I believe xrandr is the tool used for configuring displays in standard linux.

kolsi
Posts: 9
Joined: Wed Jan 23, 2019 10:40 am

Re: New experimental GL driver configuration

Thu Apr 18, 2019 8:37 am

I am not sure whether this is the driver issue or rather Xorg issue, but after enabling KMS fake driver (dtoverlay=vc4-fkms-v3d), the Xorg startup is much slower.

We are able to boot RPi3B+ into our GTK+2 application in 4.5 secs with legacy driver, but after enabling KMS driver, the boot takes threetimes more time. This is Xorg.0.log. I can notice two delays in Xorg.0.log.

One short 800 ms delay directly when glamor driver loads:
[ 8.509] ABI class: X.Org ANSI C Emulation, version 0.4
[ 8.509] (II) glamor: OpenGL accelerated X.org driver based.
[ 9.394] (II) glamor: EGL version 1.4 (DRI2):
[ 9.443] (II) modeset(0): glamor initialized
One long delay at the end of the log:
[ 9.992] (II) This device may have been added with another device file.
[ 15.775] (II) modeset(0): Disabling kernel dirty updates, not required.
This second delay is random, sometimes is shorter, sometimes very long. I noticed that application started via .xinitrc is already running at this time ("ps aux" shows it) but app window is not visible on the screen until this "Disabling kernel updates" log message appears.

EDIT: I also noticed that disabling HDMI output ("tvservice -o") increases these Xorg delay rapidly and it also takes a minutes to device restart ("sudo reboot"). No problem with legacy driver.
[ 5.333] (II) glamor: OpenGL accelerated X.org driver based.
[ 6.217] (II) glamor: EGL version 1.4 (DRI2):
[ 6.267] (II) modeset(0): glamor initialized
[ 13.910] (II) modeset(0): Output HDMI-1 has no monitor section
[ 13.910] (II) modeset(0): EDID for output HDMI-1
[ 13.910] (II) modeset(0): Printing probed modes for output HDMI-1
...
[ 13.916] (==) Depth 24 pixmap format is 32 bpp
[ 14.165] (==) modeset(0): Backing store enabled
[ 14.165] (==) modeset(0): Silken mouse enabled
[ 14.168] (II) modeset(0): RandR 1.2 enabled, ignore the following RandR disabled message.
[ 45.270] (II) modeset(0): [DRI2] Setup complete
[ 45.270] (II) modeset(0): [DRI2] DRI driver: vc4
[ 45.270] (II) modeset(0): [DRI2] VDPAU driver: vc4
[ 45.270] (--) RandR disabled
[ 45.295] (II) SELinux: Disabled on system
[ 45.312] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[ 45.312] (II) AIGLX: enabled GLX_ARB_create_context
[ 45.312] (II) AIGLX: enabled GLX_ARB_create_context_profile
[ 45.312] (II) AIGLX: enabled GLX_EXT_create_context_es{,2}_profile
...
[ 45.556] (II) config/udev: Adding input device FT5406 memory based driver (/dev/input/mouse0)
[ 45.556] (II) No input driver specified, ignoring this device.
[ 45.556] (II) This device may have been added with another device file.
[ 76.630] (II) SYN_DROPPED event from "FT5406 memory based driver" - some input events have been lost.
[ 125.513] (II) modeset(0): Disabling kernel dirty updates, not required.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5227
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: New experimental GL driver configuration

Thu Apr 18, 2019 10:24 am

kolsi wrote:
Thu Apr 18, 2019 8:37 am
I am not sure whether this is the driver issue or rather Xorg issue, but after enabling KMS fake driver (dtoverlay=vc4-fkms-v3d), the Xorg startup is much slower.
Can you confirm this occurs on a fresh raspbian install?
Assuming it does, reporting here may be best.

mijutu
Posts: 2
Joined: Mon Feb 01, 2016 11:39 am

Re: New experimental GL driver configuration

Fri May 03, 2019 7:33 am

When using dtoverlay=vc4-fkms-v3d, how could I change the dispmanx layer of an opengl application (eglfs, no X)?

I'd like to have a transparent eglfs application on top of omxplayer.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5227
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: New experimental GL driver configuration

Fri May 03, 2019 11:00 am

mijutu wrote:
Fri May 03, 2019 7:33 am
When using dtoverlay=vc4-fkms-v3d, how could I change the dispmanx layer of an opengl application (eglfs, no X)?

I'd like to have a transparent eglfs application on top of omxplayer.
Why not move the omxplayer layer. ``--layer n``
I believe gl framebuffer is at layer -127, so ``--layer 200`` would put omxplayer behind GL.
You might also need ``framebuffer_ignore_alpha=0`` in config.txt

Return to “Advanced users”