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).
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.
The error message was cleaned up, but fixing the performance regression is out of scope for this release cycle.
*** Bug 19199 has been marked as a duplicate of this bug. ***
Created attachment 21440 [details] 1GB setup / 2GB setup diff
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.
*** Bug 19738 has been marked as a duplicate of this bug. ***
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.
Eric: Just add: Option "ModeDebug" "true" to the end of /etc/X11/xorg.conf ?
(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
*** Bug 19873 has been marked as a duplicate of this bug. ***
Created attachment 24152 [details] Xorg.0.log with Option "ModeDebug" "true"
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.
Do you need any additional information to fix the bug?
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.
Created attachment 24417 [details] [review] i915-gem-disable.patch Fixed wrong path in patch.
(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.
(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.
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.
(changing title back to original: I presume that wasn't intended Eric)
(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.
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 :)
(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
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
Eric, you mentioned in c18 that this patch is only half of the required fix.... any news on the other half?
It's already in 2.6.30-rc2, works like a charm, thank you very much for this fix!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.