Bug 16835 - [945 tiling] Low performance due to no A17 workaround
[945 tiling] Low performance due to no A17 workaround
Status: RESOLVED FIXED
Product: xorg
Classification: Unclassified
Component: Driver/intel
git
x86 (IA32) Linux (All)
: high major
Assigned To: Eric Anholt
Xorg Project Team
:
: 19199 19738 19873 (view as bug list)
Depends on:
Blocks: 20276
  Show dependency treegraph
 
Reported: 2008-07-24 06:27 UTC by Johannes Engel
Modified: 2009-04-20 09:35 UTC (History)
13 users (show)

See Also:


Attachments
Xorg logfile (32.39 KB, text/plain)
2008-07-24 06:27 UTC, Johannes Engel
no flags Details
1GB setup / 2GB setup diff (4.21 KB, text/plain)
2008-12-23 09:12 UTC, Max Komarovsky
no flags Details
Xorg.0.log with Option "ModeDebug" "true" (90.60 KB, text/x-log)
2009-03-23 01:23 UTC, Frank Sievertsen
no flags Details
i915-gem-disable.patch (781 bytes, patch)
2009-03-31 15:30 UTC, Vasily Khoruzhick
no flags Details | Splinter Review
i915-gem-disable.patch (781 bytes, patch)
2009-03-31 15:34 UTC, Vasily Khoruzhick
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Johannes Engel 2008-07-24 06:27:15 UTC
Created attachment 17855 [details]
Xorg logfile

Since Eric's commit e9916b9d496fd0b4df717892dda33f81a2e2990a I keep getting these messages in my Xorg.0.log, 3D performance is also very poor (glxgears is no benchmark but stays around 300 fps), although I do not know if that is related.

(EE) intel(0): Failed to set tiling on front buffer: No such file or directory
(EE) intel(0): Failed to set tiling on back buffer: No such file or directory
(EE) intel(0): Failed to set tiling on depth buffer: No such file or directory

My hardware is a i945GM, software is kernel 2.6.26, complete modular X.org (incl. Mesa and drm kernel modules) from git (branch drm-gem where possible, otherwise master).
Comment 1 Eric Anholt 2008-07-25 15:50:51 UTC
That error message should probably only include the error string if ret != 0.  I'm guessing that ret == 0 for you and you've got the same 945 setup we've got, where the cpu's interleaving makes swappable tiled objects (basically) impossible.  To allow tiling on those systems we'll have to either play some tricks with the memory allocation and pin them, or get a lot more integrated into the paging system.
Comment 2 Eric Anholt 2008-12-19 14:08:56 UTC
The error message was cleaned up, but fixing the performance regression is out of scope for this release cycle.
Comment 3 Eric Anholt 2008-12-20 01:29:45 UTC
*** Bug 19199 has been marked as a duplicate of this bug. ***
Comment 4 Max Komarovsky 2008-12-23 09:12:19 UTC
Created attachment 21440 [details]
1GB setup / 2GB setup diff
Comment 5 klinger.ofir 2009-02-22 13:29:27 UTC
Eric Anholt:
When do you think this bug will be fixed?

It is very annoying to work when all the graphic interface is working slow.
Comment 6 Eric Anholt 2009-03-10 18:07:45 UTC
*** Bug 19738 has been marked as a duplicate of this bug. ***
Comment 7 Eric Anholt 2009-03-16 10:42:01 UTC
Could you set Option "ModeDebug" "true" in xorg.conf and attach a new log (hopefully with 2D driver master)?  I need some details on your memory configuration to make sure we're not incorrectly disabling tiling.

Comment 8 klinger.ofir 2009-03-18 09:06:14 UTC
Eric:
Just add:
Option "ModeDebug" "true"
to the end of /etc/X11/xorg.conf ?
Comment 9 Colin Guthrie 2009-03-18 10:40:04 UTC
(In reply to comment #8)
> Eric:
> Just add:
> Option "ModeDebug" "true"
> to the end of /etc/X11/xorg.conf ?


Place this option inside the Device section e.g.:

Section "Device"
    Identifier "device1"
    VendorName "Intel Corp."
    BoardName ""
    Driver "intel"
    Option "ModeDebug" "true"
EndSection
Comment 10 Eric Anholt 2009-03-19 12:35:10 UTC
*** Bug 19873 has been marked as a duplicate of this bug. ***
Comment 11 Frank Sievertsen 2009-03-23 01:23:02 UTC
Created attachment 24152 [details]
Xorg.0.log with Option "ModeDebug" "true"
Comment 12 Gergely Csepany 2009-03-23 04:41:50 UTC
I was wondering if there is an option to disable GEM support on 2.6.28 kernels? This way the intel driver would fall back to the traditional mode and would be usable on dual channel systems until the tiling problem is fixed.
Comment 13 Frank Sievertsen 2009-03-28 04:29:00 UTC
Do you need any additional information to fix the bug?
Comment 14 Vasily Khoruzhick 2009-03-31 15:30:41 UTC
Created attachment 24416 [details] [review]
i915-gem-disable.patch

With this patch applied on 2.6.29 you'll be able to disable gem with module parameter. Just load i915.ko with gem_enable=0.

This patch is only a workaround and is not intended to be clean.
Comment 15 Vasily Khoruzhick 2009-03-31 15:34:49 UTC
Created attachment 24417 [details] [review]
i915-gem-disable.patch

Fixed wrong path in patch.
Comment 16 Colin Guthrie 2009-04-01 02:33:00 UTC
(In reply to comment #15)
> Created an attachment (id=24417) [details]
> i915-gem-disable.patch

Thanks for this patch. While a proper fix would obviously be preferred this should at least let me start using a newer kernel than the .27 one I'm stuck on just now.
Comment 17 Gergely Csepany 2009-04-02 06:20:53 UTC
(In reply to comment #14)
> Created an attachment (id=24416) [details]
> i915-gem-disable.patch
> 
> With this patch applied on 2.6.29 you'll be able to disable gem with module
> parameter. Just load i915.ko with gem_enable=0.
> 
> This patch is only a workaround and is not intended to be clean.
> 

Thank you for providing this patch. May it be applied to 2.6.28 too? (Comparing the .28 and .29 sources, I found the same pieces of code and I intend to use the ubuntu kernel source, which is based on .28 for jaunty.) 
I'll try it when I have some time to compile the kernel(s), presumably early next week, and I'll report the results.
Comment 18 Eric Anholt 2009-04-03 17:20:36 UTC
Half of the required fix:

http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39203.html

This will give you tiling on A17-affected machines at the expense of glReadPixels.  Next up will be fixing Mesa to recover glReadPixels.  Additionally, testing has revealed that DRI2 tiling on 915-class machines may result in 2D corruption when creating DRI2 buffers due to bo reuse.  We're looking into that as well.
Comment 19 Colin Guthrie 2009-04-03 21:15:02 UTC
(changing title back to original: I presume that wasn't intended Eric)
Comment 20 Vasily Khoruzhick 2009-04-12 02:47:52 UTC
(In reply to comment #18)
> Half of the required fix:
> 
> http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39203.html
> 
> This will give you tiling on A17-affected machines at the expense of
> glReadPixels.  Next up will be fixing Mesa to recover glReadPixels. 
> Additionally, testing has revealed that DRI2 tiling on 915-class machines may
> result in 2D corruption when creating DRI2 buffers due to bo reuse.  We're
> looking into that as well.

Any news about mesa patch? It's quite annoying to have no _complete_ workaround for this issue for half of an year.
Comment 21 Colin Guthrie 2009-04-12 03:06:17 UTC
We have a patch in Mandriva that seems to work as an automatic workaround.
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/kernel/current/PATCHES/patches/gpu-drm-i915-no-gem-if-no-tiling.patch?view=log

Obviously a proper fix is better :)
Comment 22 Vasily Khoruzhick 2009-04-12 13:20:03 UTC
(In reply to comment #21)
> We have a patch in Mandriva that seems to work as an automatic workaround.
> http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/kernel/current/PATCHES/patches/gpu-drm-i915-no-gem-if-no-tiling.patch?view=log
> 
> Obviously a proper fix is better :)
> 

Thanks! Why not to include this patch into the mainline kernel? Non-gem 3D is better than no 3D at all. Please submit it to the dri-devel maillist
Comment 23 Eric Anholt 2009-04-14 14:57:39 UTC
commit 280b713b5b0fd84cf2469098aee88acbb5de859c
Author: Eric Anholt <eric@anholt.net>
Date:   Thu Mar 12 16:56:27 2009 -0700

    drm/i915: Allow tiling of objects with bit 17 swizzling by the CPU.

queued to linus
Comment 24 Colin Guthrie 2009-04-15 00:53:49 UTC
Eric, you mentioned in c18 that this patch is only half of the required fix.... any news on the other half?
Comment 25 Gergely Csepany 2009-04-20 09:35:35 UTC
It's already in 2.6.30-rc2, works like a charm, thank you very much for this fix!