Testing the new i915 driver (rev. 3820047)

Sun Oct 18 00:05:31 UTC 2015

Testing Scenario #1:
1. boot the new kernel
   - do not load i915kms at boot
   - do not connect any external monitors
2. start Xorg from tty as normal user
3. test tty switching
4. connect and test multiple monitors (via HDMI2 and HDMI3 outputs)
5. test FullHD video output, look for problems in video playback
    - ESPECIALLY look for VSync issues

I am using FreeBSD 10.2-RELEASE userland, applications installed from 
the official FreeBSD quarterly repository. I have configured syslogd to 
output all kernel messages to /var/log/messages

My laptop is a Thinkpad T430, dual-core i5 (4 threads), Ivy Bridge with 
Intel HD4000 GPU.

# cat /boot/loader.conf
kern.vt.fb.default_mode="1600x900"
kern.vt.fb.modes.LVDS-1="1600x900"
kern.ipc.shmseg=1024
kern.ipc.shmmni=1024
hint.p4tcc.0.disabled=1
hint.acpi_throttle.0.disabled=1
sem_load=YES
drm.debug=3

Kernel booted just fine, no problems.

Then I loaded the kernel module (as root):
# kldload i915kms

Module loaded without problems. Then I attempted to start Xorg (non-root 
user):
$ startx

Xorg started without problems, single output on laptop LVDS1.

TTY switching works without any problems.

After this I connected 2 monitors to HDMI outputs HDMI2 and HDMI3 (they 
were unplugged at boot). Then I configured two monitors:
xrandr --output HDMI2 --right-of LVDS1 --auto
xrandr --output HDMI3 --right-of HDMI2 --auto

I got all three monitors working at optimal resolution without problems. 
Very good thus far.

But then I ran into a weird problem: NO X11 application would use 
hardware acceleration. This would lead to display tearing and horrible 
performance. Each application would output the following stderr:
libGL error: failed to open drm device: Permission denied
libGL error: failed to load driver: i965

Investigating the issue I found out that kernel devfs OR devd (not sure 
which?) would set the /dev/dri/* permissions incorrectly. The gid of 
/dev/dri/* was 44, and this gid 44 was nonexistant in /etc/groups. Where 
does this gid 44 come from? Is it a group specific to the 11-CURRENT 
kernel?

I managed to work around this problem with the following command (as 
root):
# chgrp wheel /dev/dri/*

After this hardware acceleration worked fine (programs were able to 
access /dev/dri/*, as my non-root user is member of the wheel -group). 
HOWEVER, this fix is quick and dirty. I am correct to assume that this 
won't be an issue when the driver is MFC'd?

Anyways, thus far I have tried using www/chromium and watched Youtube 
videos. Video playback works fine without tearing (because I use 
SNA+TearFree), chrome CPU usage around 30-60% with 1080p full HD video. 
Within acceptable limits.

SUMMARY:
- boot ok
- kldload i915kms ok
- startx ok
   - NOTE: using SNA acceleration with TearFree option
- tty switching works ok
- all outputs detected and configured
   - HDMI2 and HDMI3
- needed to manually do 'chgrp wheel /dev/dri/*' to get hardware 
acceleration working properly
- after the perm fix, chrome can play 1080p videos without any issues, 
no video tearing

Test Scenario #1 was completed in about 30 minutes.

IMPORTANT: I used the same Xorg configuration for all these tests. The 
relevant Xorg configuration files are attached in this email, please 
browse thru them if they help.

NOTE1. dmesg was logged into /var/log/messages. the drm.debug=3 and 
witness produced huge amount of output into /var/log/messages. The 
actual dmesg at boot was not logged in this file, and I was NOT able to 
save it, since the messages from debug+witness overrun dmesg buffer. I 
should have done dmesg > dmesg.txt as the very first thing after boot. I 
am sorry for failing to do this. However, I managed to get at least the 
/var/log/messages output after I started X. I dare not attach the 2M+ 
file here, so you can download it from: 
http://koti.kapsi.fi/~isoa/kernel.i915/scenario1/messages.log.xz

NOTE2. Do note that I use the SNA acceleration with the TearFree -option 
(in 10-intel.conf), because the default UXA acceleration did not offer 
VSync. Thus for me being a perfectionist, the only option is to use 
SNA+TearFree to get a perfect video performance.

NOTE3. The only real problem I had was that I was NOT able to get my 
wifi working! With the 10.2-RELEASE kernel, iwn0 attached fine, and I 
was able to join my local wifi. However, with the new kernel.i915, there 
is no iwn0 interface (via ifconfig), as if the new kernel.i915 could not 
detect my wireless chip at all. Kernel in 10.2-RELEASE detected the 
following:
iwn0: <Intel Centrino Advanced-N 6205> mem 0xf1c00000-0xf1c01fff at 
device 0.0 on pci3

NOTE4: Chrome CPU usage of 1080p Youtube videos under Debian 8 (SNA 
acceleration + TearFree) fall within this same 30-60% margin. Except, 
with the newer KMS drivers in Debian, VSync is YET again bugged. With 
Debian 8 I had to use Compton (with very specific settings) -compositor 
to force VSync on the composition overlay. I tested this by adding Xorg 
configuration for intel driver and pkilling Xorg, which should have 
restarted Xorg with new config (if pkilling Xorg did not start X with 
new intel config, then I blame systemd and/or the display manager that 
is preconfigured with Debian 8 LXDE desktop). So yeah, my testing kinda 
proves even the Linux drivers can have regressions. I have to say that 
we are really lucky that this driver in kernel.i915 imported from Linux 
3.8 does not have regression in regards to VSync with SNA+TearFree. I 
think we FreeBSD users gotta stay sharp and keep torture testing these 
drivers with all possible scenarios. This is the only way to make sure 
that things are hopefully noticed and fixed even in upsteam.

I will prepare another scenario. In Test Scenario #2 I shall attempt the 
following:
1. boot kernel.i915 with i915kms_load="YES"
2. startx as normal user
3. repeat steps 3 to 5 from Test Scenario #1

Jean-Sébastien Pédron kirjoitti 17.10.2015 16:26:
> Hi!
> 
> Lately, I fixed several issues with the GEM, people already reported
> this improved things for them.
> 
> I believe I fixed two problems with the output connectors too and I 
> hope
> that it will be fine now for people who reported eg. non-working HDMI.
> However, I can't test this myself.
> 
> I'm still chasing a problem with Mesa (Stellarium hangs on startup for 
> me).
> 
> As a reminder, informations are available on the wiki:
> https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20Linux%203.8
> 
> Please continue to test! Thank you for your help :)

-- 
Arto Pekkanen
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 00-fonts.conf
URL: <http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20151018/2fe060f9/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 10-intel.conf
URL: <http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20151018/2fe060f9/attachment-0001.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 20-outputs.conf
URL: <http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20151018/2fe060f9/attachment-0002.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Xorg.0.log
URL: <http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20151018/2fe060f9/attachment-0003.ksh>