Bug 838723

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

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.

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?

(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.

So this must be a modesetting related bug, possibly in the intel driver?

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.

Right, will perform some tests as soon as I've handed in my master thesis tomorrow, hurray :)

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

dmesg output and the contents of /proc/mtrr from the two boot configurations would be enlightening.

Created attachment 601815 [details]
t500.lspci.txt

Created attachment 601816 [details]
t500.dmesg.console.txt

Created attachment 601817 [details]
t500.mtrr.console.txt

Created attachment 601818 [details]
t500.dmesg.gfxterm.txt

Created attachment 601819 [details]
t500.mtrr.gfxterm.txt

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.

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.)

<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

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)

Created attachment 602020 [details]
cat /proc/mtrr

Created attachment 602021 [details]
lspci

Created attachment 602022 [details]
dmesg, console

Created attachment 602023 [details]
dmesg, gfxterm

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

Created attachment 602132 [details]
t500.kernel35.dmesg.console.txt

Created attachment 602133 [details]
t500.kernel35.dmesg.gfxterm.txt

Created attachment 602134 [details]
t500.kernel35.mtrr.console.txt

Created attachment 602135 [details]
t500.kernel35.mtrr.gfxterm.txt

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.

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.

(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

(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.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

I just realized that I'm not experiencing this issue any more, closing.