Bug 838723 - Dreadfull flash fullscreen performance when using GRUB_TERMINAL=gfxterm
Dreadfull flash fullscreen performance when using GRUB_TERMINAL=gfxterm
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel (Show other bugs)
17
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-09 19:23 EDT by Sandro Mani
Modified: 2012-10-25 06:24 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-25 06:08:58 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
t500.lspci.txt (31.29 KB, text/plain)
2012-08-01 16:00 EDT, Kamil Páral
no flags Details
t500.dmesg.console.txt (87.55 KB, text/plain)
2012-08-01 16:00 EDT, Kamil Páral
no flags Details
t500.mtrr.console.txt (483 bytes, text/plain)
2012-08-01 16:00 EDT, Kamil Páral
no flags Details
t500.dmesg.gfxterm.txt (88.70 KB, text/plain)
2012-08-01 16:00 EDT, Kamil Páral
no flags Details
t500.mtrr.gfxterm.txt (483 bytes, text/plain)
2012-08-01 16:00 EDT, Kamil Páral
no flags Details
cat /proc/mtrr (483 bytes, text/plain)
2012-08-02 17:28 EDT, Sandro Mani
no flags Details
lspci (2.45 KB, text/plain)
2012-08-02 17:28 EDT, Sandro Mani
no flags Details
dmesg, console (92.23 KB, text/plain)
2012-08-02 17:29 EDT, Sandro Mani
no flags Details
dmesg, gfxterm (92.14 KB, text/plain)
2012-08-02 17:29 EDT, Sandro Mani
no flags Details
t500.kernel35.dmesg.console.txt (88.75 KB, text/plain)
2012-08-03 09:26 EDT, Kamil Páral
no flags Details
t500.kernel35.dmesg.gfxterm.txt (89.30 KB, text/plain)
2012-08-03 09:26 EDT, Kamil Páral
no flags Details
t500.kernel35.mtrr.console.txt (483 bytes, text/plain)
2012-08-03 09:26 EDT, Kamil Páral
no flags Details
t500.kernel35.mtrr.gfxterm.txt (483 bytes, text/plain)
2012-08-03 09:26 EDT, Kamil Páral
no flags Details

  None (edit)
Description Sandro Mani 2012-07-09 19:23:13 EDT
Description of problem:
When using the default setting GRUB_TERMINAL=gfxterm, full-screen flash
performance is bad (on a 1440x900 screen it is barely ok, on a
1920x1200 screen it's terrible, with lots of tearing, and controls completely unresponsive).
But if I put GRUB_TERMINAL=console, the performance is normal again. I am seeing this on F17 (with a Intel N10 IGP) and rawhide (with a Intel 4500MHD IGP).

Version-Release number of selected component (if applicable):
grub2-2.0-0.37.beta6.fc17.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Use default setting
2. Watch some flash content in fullscreen at high-ish resolution
3. Use GRUB_TERMINAL=console, notice improvement

Additional info:
I wonder whether this is related to the general sluggish performance of the grub2 menus on certain hardware.

What made me try to change GRUB_TERMINAL to console was a opensuse forum post which described similar situation: http://forums.opensuse.org/english/get-technical-help-here/multimedia/467622-full-screen-flash-extremely-slow-intel-i-fixed-sheer-luck.html
Comment 1 Kamil Páral 2012-07-31 04:40:06 EDT
Confirmed with Thinkpad T500 and Intel 4500MHD, Fedora 17. If I hadn't seen this with my own eyes, I wouldn't have believed this can be related. But changing GRUB_TERMINAL to "console" made fullscreen flash run smoothly again.

Steps to fix fullscreen flash:
1. Set GRUB_TERMINAL="console" in /etc/default/grub.
2. Generate new grub by "grub2-mkconfig -o /boot/grub2/grub.cfg"
3. Reboot
Comment 2 Mads Kiilerich 2012-07-31 07:02:35 EDT
Yes, the bad performance of gfxterm (which is much worse when using a theme) was the reason the graphical theme for f17 was dropped again.

The performance of gfxterm was however considered ok for a normal menu, especially considering that it also enables unicode for localization and usually utilize the high resolution of the display.

Some of the redraw performance issues has been fixed upstream, but I don't remember if it is included in 2.0. You can try to grab it from koji and give it a try.

It seemed like upstream for some reason couldn't reproduce the completely dreadful redrawing seen on some machines.
Comment 3 Sandro Mani 2012-07-31 07:35:47 EDT
I guess something which would be really interesting to know is how it's possible for gfxterm to cause such performance issues outside grub. In particular, is this specific to intel graphics?
Comment 4 Mads Kiilerich 2012-07-31 07:52:46 EDT
(In reply to comment #3)
> I guess something which would be really interesting to know is how it's
> possible for gfxterm to cause such performance issues outside grub.

No way. The BIOS contains its own very limited hardware drivers that is used with 'console'. Grub is an OS that contains its own hardware drivers that is used with 'gfxterm'. Grub launches the real OS and disappears and the kernel/X contains its own hardware drivers.
Comment 5 Sandro Mani 2012-07-31 07:58:27 EDT
So this must be a modesetting related bug, possibly in the intel driver?
Comment 6 Mads Kiilerich 2012-07-31 08:15:31 EDT
Reading again I realize that you are referring to the proprietary Adobe Flash running under X, not just the flash-like boot loader graphics. What I said in comment 2 do thus not make sense in this context.

I suggest finding another and open source metric - for example some X benchmark (glxgears or something better).

Yes, the difference must be in the different states the boot loader can leave the hardware and how the kernel/X handles these. I would expect KMS to be able to handle every state equally well. I will reassign in that direction.

Try to record dmesg and Xorg.0.log for different boot loader configurations and upload them as text/plain with a note of the related performance.

I guess "set gfxpayload=keep" is what makes the difference. You can try the values auto and text as well.
Comment 7 Sandro Mani 2012-07-31 08:25:10 EDT
Right, will perform some tests as soon as I've handed in my master thesis tomorrow, hurray :)
Comment 8 Kamil Páral 2012-07-31 09:08:07 EDT
I have tested Thinkpad R61 with Nvidia Quadro NVS 140M (nouveau driver). I used http://www.youtube.com/watch?v=NZcsNE6wCHI (720p quality, 2:00 minute mark). I displayed playback fps by "Show video info" context menu item (make sure it doesn't run in HTML5 mode [1]). Latest Flash from Adobe website.

I have 25 fps in large window mode and 16 fps in fullscreen mode, regardless of GRUB_TERMINAL setting (gfxmode or console).

That means Nvidia (nouveau) doesn't seem to be affected.

[1] http://www.youtube.com/html5
Comment 9 Adam Jackson 2012-07-31 11:38:15 EDT
dmesg output and the contents of /proc/mtrr from the two boot configurations would be enlightening.
Comment 10 Kamil Páral 2012-08-01 16:00:16 EDT
Created attachment 601815 [details]
t500.lspci.txt
Comment 11 Kamil Páral 2012-08-01 16:00:21 EDT
Created attachment 601816 [details]
t500.dmesg.console.txt
Comment 12 Kamil Páral 2012-08-01 16:00:25 EDT
Created attachment 601817 [details]
t500.mtrr.console.txt
Comment 13 Kamil Páral 2012-08-01 16:00:28 EDT
Created attachment 601818 [details]
t500.dmesg.gfxterm.txt
Comment 14 Kamil Páral 2012-08-01 16:00:32 EDT
Created attachment 601819 [details]
t500.mtrr.gfxterm.txt
Comment 15 Kamil Páral 2012-08-01 16:05:41 EDT
Logs attached for Thinkpad T500 with Intel 4500MHD. When trying out video in comment 8, I receive about 23-25 fps in fullscreen mode with 'gfxterm' and 25-27 fps in fullscreen mode with 'console'. But the perceived difference is much larger than the numbers suggest - 'console' mode is much smoother. Also there is an abysmal difference when using the video controls (seek bar etc) in fullscreen mode. With 'gfxterm' it changes to a slideshow, 'console' is much better.
Comment 16 Mads Kiilerich 2012-08-01 18:51:19 EDT
Some observations:

Exactly the same mtrr.

In dmesg in both cases:

[drm] Initialized drm 1.1.0 20060810
i915 0000:00:02.0: power state changed by ACPI to D0
i915 0000:00:02.0: power state changed by ACPI to D0
i915 0000:00:02.0: setting latency timer to 64
usb 1-5.4: New USB device found, idVendor=046d, idProduct=c52b
usb 1-5.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-5.4: Product: USB Receiver
usb 1-5.4: Manufacturer: Logitech
mtrr: no more MTRRs available
[drm] MTRR allocation failed.  Graphics performance may suffer.
i915 0000:00:02.0: irq 45 for MSI/MSI-X
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem

The only real differences in dmesg:

--- t500.dmesg.console.txt
+++ t500.dmesg.gfxterm.txt
@@ -330,7 +330,7 @@
 Hierarchical RCU implementation.
 NR_IRQS:8448 nr_irqs:712 16
 Extended CMOS year: 2000
-Console: colour VGA+ 80x25
+Console: colour dummy device 80x25
 console [tty0] enabled
 allocated 33554432 bytes of page_cgroup
 please try 'cgroup_disable=memory' option if you don't want memory cgroups
@@ -864,6 +864,12 @@
 pciehp 0000:00:1c.4:pcie04: service driver pciehp loaded
 pciehp: PCI Express Hot Plug Controller Driver version: 0.4
 acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
+vesafb: mode is 1680x1050x32, linelength=6720, pages=0
+vesafb: scrolling: redraw
+vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
+vesafb: framebuffer at 0xd0000000, mapped to 0xffffc90005800000, using 6912k, total 6912k
+Console: switching to colour frame buffer device 210x65
+fb0: VESA VGA frame buffer device
 intel_idle: does not run on family 6 model 23
 ACPI: AC Adapter [AC] (on-line)
 input: Lid Switch as /devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input0
@@ -1102,6 +1108,20 @@
 psmouse serio1: synaptics: Touchpad model: 1, fw: 7.0, id: 0x1c0b1, caps: 0xd04791/0xb00000/0x20000
 psmouse serio1: synaptics: serio: Synaptics pass-through port at isa0060/serio1/input0
 input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input5
+[drm] capturing error event; look for more information in /debug/dri/0/i915_error_state
+render error detected, EIR: 0x00000010
+  IPEIR: 0x00000000
+  IPEHR: 0x00000000
+  INSTDONE: 0xfffffffe
+  INSTPS: 0x00000000
+  INSTDONE1: 0xffffffff
+  ACTHD: 0x00000000
+page table error
+  PGTBL_ER: 0x00000001
+[drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking
+checking generic (d0000000 6c0000) vs hw (d0000000 10000000)
+fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
+Console: switching to colour dummy device 80x25
 fbcon: inteldrmfb (fb0) is primary device
 Console: switching to colour frame buffer device 210x65
 fb0: inteldrmfb frame buffer device

 drm: registered panic notifier
 input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input6
 ACPI: Video Device [VID] (multi-head: yes  rom: no  post: no)
 [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

(Slightly suspicious observation: vboxdrv are loaded.)
Comment 17 Ray Strode [halfline] 2012-08-02 17:04:45 EDT
<ajax> this ring any bells for anybody? https://bugzilla.redhat.com/show_bug.cgi?id=838723#c16
<ajax> the page table error seems mighty suspicious.
<airlied> ajax: the easrly handoff stuff should fix it
<airlied> which should be in 3.5 at least
Comment 18 Mads Kiilerich 2012-08-02 17:10:41 EDT
Someone, please test with 3.5 ... in some way ...

(assuming that it doesn't refer to some change in the boot protocol that requires some boot loader changes as well)
Comment 19 Sandro Mani 2012-08-02 17:28:18 EDT
Created attachment 602020 [details]
cat /proc/mtrr
Comment 20 Sandro Mani 2012-08-02 17:28:45 EDT
Created attachment 602021 [details]
lspci
Comment 21 Sandro Mani 2012-08-02 17:29:23 EDT
Created attachment 602022 [details]
dmesg, console
Comment 22 Sandro Mani 2012-08-02 17:29:53 EDT
Created attachment 602023 [details]
dmesg, gfxterm
Comment 23 Sandro Mani 2012-08-02 17:33:08 EDT
I am running rawhide with 3.5.0-2.fc17.x86_64, and can still notice the issue. Also in my case, /proc/mtrr are identical

The relevant differences between the dmesg are, as far as I can tell

--- t400.dmesg.console.txt
+++ t400.dmesg.gfxterm.txt

-Console: colour VGA+ 80x25
+Console: colour dummy device 80x25

+vesafb: mode is 1440x900x32, linelength=5760, pages=0
+vesafb: scrolling: redraw
+vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
+vesafb: framebuffer at 0xd0000000, mapped to 0xffffc90005800000, using 5120k, total 5120k
+Console: switching to colour frame buffer device 180x56
+fb0: VESA VGA frame buffer device

 [drm] Initialized drm 1.1.0 20060810
 i915 0000:00:02.0: power state changed by ACPI to D0
 i915 0000:00:02.0: power state changed by ACPI to D0
+checking generic (d0000000 500000) vs hw (d0000000 10000000)
+fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
+Console: switching to colour dummy device 80x25
Comment 24 Kamil Páral 2012-08-03 09:26:38 EDT
Created attachment 602132 [details]
t500.kernel35.dmesg.console.txt
Comment 25 Kamil Páral 2012-08-03 09:26:42 EDT
Created attachment 602133 [details]
t500.kernel35.dmesg.gfxterm.txt
Comment 26 Kamil Páral 2012-08-03 09:26:45 EDT
Created attachment 602134 [details]
t500.kernel35.mtrr.console.txt
Comment 27 Kamil Páral 2012-08-03 09:26:48 EDT
Created attachment 602135 [details]
t500.kernel35.mtrr.gfxterm.txt
Comment 28 Kamil Páral 2012-08-03 09:32:59 EDT
I have upgraded to kernel-3.5.0-2.fc17. That kernel basically solved the problem for me. There is a noticeable performance increase in fullscreen flash performance with "gfxterm". I'm not fully sure GRUB_TERMINAL="console" and GRUB_TERMINAL="gfxterm" now perform exactly the same, "console" might still be a bit better. But that's just a personal feeling, and even if it is true, the difference is now really small.

When talking about this bug, kernel-3.5.0-2.fc17 fixed the problem for me.
Comment 29 Sandro Mani 2012-08-03 09:39:39 EDT
At what screen resolution are you testing? For me, when the 1440x900 laptop panel, performance was never really terrible, but on a external 1920x1200 display, performance is still dreadful, even with 3.5.0-2.
Comment 30 Mads Kiilerich 2012-08-03 09:41:12 EDT
(In reply to comment #27)

--- t500.kernel35.dmesg.console.txt
+++ t500.kernel35.dmesg.gfxterm.txt

-Console: colour VGA+ 80x25
+Console: colour dummy device 80x25

+vesafb: mode is 1680x1050x32, linelength=6720, pages=0
+vesafb: scrolling: redraw
+vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
+vesafb: framebuffer at 0xd0000000, mapped to 0xffffc90005800000, using 6912k, total 6912k
+Console: switching to colour frame buffer device 210x65
+fb0: VESA VGA frame buffer device

+checking generic (d0000000 6c0000) vs hw (d0000000 10000000)
+fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
+Console: switching to colour dummy device 80x25
Comment 31 Kamil Páral 2012-08-03 09:59:12 EDT
(In reply to comment #29)
> At what screen resolution are you testing? For me, when the 1440x900 laptop
> panel, performance was never really terrible, but on a external 1920x1200
> display, performance is still dreadful, even with 3.5.0-2.

1680x1050. I don't have a larger display to test with.
Comment 32 Miroslav Mamrak 2012-08-13 08:16:29 EDT

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 33 Sandro Mani 2012-10-25 06:08:58 EDT
I just realized that I'm not experiencing this issue any more, closing.

Note You need to log in before you can comment on or make changes to this bug.