Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim
On Thu, Jan 28, 2010 at 3:19 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Wed, 27 Jan 2010, Chris Wilson wrote: Yes, it survives a short torture test that leaks lots of bo objects from X. Obviously this patch depends upon the new interface. All right. I'll apply my patch, since i'd rather have any half-way complex logic for handling mappings in the generic mm code. And then I'll apply yours, because now I can look at it without wanting to dig my eyes out. Chris's patch has been reported to cause a regression in hibernate, I haven't set up a reproducer yet, and it might be a stable issue (someone bisected it in stable). https://bugzilla.kernel.org/show_bug.cgi?id=13811 Hopefully I can spend some time tomorrow setting up a machine to test. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim
On Wed, 30 Jun 2010 16:54:07 +1000, Dave Airlie airl...@gmail.com wrote: Chris's patch has been reported to cause a regression in hibernate, Reviewing the patch again, we no longer set the default gfpmask on the inode to contain NORETRY and instead add the NORETRY at the one spot in the code where we are trying to do a large allocation and our shrinker would be prevented from running (due to contention on struct_mutex). I do not know how this causes memory corruption across hibernate and would appreciate any insights. -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] XVideo triggering GPU Hangs on i8xx
Hey Guys, I'm testing out 2.11/2.6.33.5-124(Fedora 13) on our embedded panel pc hardware. It's got an 855GM/ICH4 chipset. On previous versions of the drivers, in Fedora 12 for example, XVideo extension wasn't reported as available. On Fedora 13 with the 2.11/2.6.33.5 kernel, XVideo is reported. However, when attempting to use it, a gpu hang is triggered. Is XVideo extension expected to work on i8XX hardware ? -- Glen Gray sla...@slaine.org ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Basic Intel Grapics Hardware-Level Programming
Hi Everyone. I'm trying to develop a small graphics driver for the intel chipsets, but I can't find the necessary information to do that. Several months ago, I finished a small code that was able to paint pixels onto the upper part of the screen by setting the screen resolution using VESA VBE in real mode, switching to protected mode (direct BIOS calls are disabled now), and writing pixels int the real memory at 0xA-0xA. The problem was that this zone of the memory is only 64KB in length and some 1024*XXX modes use at least 2MB of memory, so it could only use the upper screen rows. This can solved by: a) Getting the VBE protected mode interface (this is not as easy as it might sound since a change in a kernel entry point could not be a good idea), b) Creating a Virtual 8086 Monitor and a process in V8086 mode by changing its copy of EFLAGS bit 17 to 1 at the PCB. c) Returning to real mode and changing bank from here, then setting the processor in Protected mode. d) Using framebuffers instead of memory banks, and setting its size and start point in real mode and e) Writing a device-specific graphic driver and assembling the code for protected mode. The e) option is the best, because it's very versatile and you can use it in a OS with an unknown structure without destroying it (it's independent from the OS). Since then, I've tried hardly to find the ports that the intel graphics driver is using. I found info about VirtualBox grapic card (it's open source too) and made my own driver for it using some basic functions well documented in its code. For example, http://www.virtualbox.org/browser/trunk/src/VBox/Devices/Graphics/BIOS/vbe.h has several defines with the ports used for VESA VBE tasks, the basic command codes and resolution codes, and a pointer to the framebuffer, and http://www.virtualbox.org/browser/trunk/src/VBox/Devices/Graphics/BIOS/vbe.c has the code for setting current video bank, x resolution and y resolution. With that information, it's easy to write a small driver that simply puts pixels, but using all the screen (not only the 64 KB frame at 0xA000), and that is able to change screen resolution. The problem is that this information is only valid for Bochs/Plex86 virtualized cards (at least, that is what says in vgabios.c : This VGA Bios is specific to the plex86/bochs Emulated VGA card. You can't drive any physical vga card with it.), but it is an important step. I would like to do the same but for a real graphics controller. ¿Where can I find the information I need for intel's ones? I've been looking for it on the xf86-video-intel driver, but over 99% its used with X Window System or handles 3D or similar, but no info about ports, the framebuffer (according to intel doc 29065602.pdf, The framebuffer is composed of Front Buffer or display buffer and Back Buffer or rendering buffer) _ ¿Un navegador seguro buscando estás? ¡Protegete ya en www.ayudartepodria.com! www.ayudartepodria.com___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] 800 Mo of log in /var/log/debug
Hello. I have about 800 Mo of Jun 18 04:40:02 slick kernel: [drm:i915_add_request], 2033703 in /var/log/debug. I erased /var/log/debug.1 that was 1 Go of the same things. Is there a way to get rid of this message? I can recompile the module if needed. Thanks. -- F. Delente ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 800 Mo of log in /var/log/debug
Are you booting with drm.debug=something other than 0? Yeah, I must have put drm.debug=0x06 in my lilo.conf once and forgot to take it out after... I'll try later if it solves the issue, it should :^) Thanks! -- F. Delente ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa3d-dev] mesa doesn't work with compiz (i965 + tips of all branches)
On Tue, 2010-06-29 at 15:49 -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Corbin Simpson wrote: Curious. Admittedly I can't look at the content of that commit, but they can't be too useless if compiz selects them. IIRC the point was to limit the runtime of Intel internal tests; can't those tests be amended instead? The number of configs will only grow; r300g has over 200 now thanks to multisampling. The configs are useless. Applications can only ask for bits = X. There are still 24-bit depth / 8-bit stencil configs, and, last time I checked, 8 = 0. There is no way to ask for a 24/0 config that wouldn't instead give a 24/8 config. Posting from a mobile, pardon my terseness. ~ C. On Jun 29, 2010 1:28 PM, Maxim Levitsky maximlevit...@gmail.com mailto:maximlevit...@gmail.com wrote: On Tue, 2010-06-29 at 20:34 +0300, Maxim Levitsky wrote: On Sun, 2010-06-27 at 19:07 +0300, Maxim ... Bisected this to 73e24cd5a7a0760726a681dda5b88805ddcf1555 is first bad commit commit 73e24cd5a7a0760726a681dda5b88805ddcf1555 Author: Ian Romanick ian.d.roman...@intel.com mailto:ian.d.roman...@intel.com Date: Mon Feb 8 10:34:52 2010 -0800 intel: Stop exposing useless 24 depth/0 stencil configs I need two pieces of information: - A diff of the output of glxinfo immediately before and immediately after this commit. - A list of what config attributes compiz is requesting. It should be easy enough to instrument choose_visual in glxcmds.c to dump out attribList. It should be pretty easy to root-cause this problem with that data. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwqeGwACgkQX1gOwKyEAw9MfQCZAUWS6wXUjRWYaX++6YRjl4Pk XMsAn06cgcjJf/dDMCBDTr/tdaFoBsGM =rGTt -END PGP SIGNATURE- --- ./glxinfo_good 2010-07-01 02:01:08.332346000 +0300 +++ ./glxinfo_bad 2010-07-01 02:01:28.115633852 +0300 @@ -84,7 +84,7 @@ GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SUN_multi_draw_arrays, GL_OES_EGL_image -28 GLX Visuals +20 GLX Visuals visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- @@ -92,32 +92,24 @@ 0x22 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0xe3 24 tc 0 24 0 r . . 8 8 8 0 0 0 0 0 0 0 0 0 0 None 0xe5 24 tc 0 24 0 r y . 8 8 8 0 0 0 0 0 0 0 0 0 0 None -0xeb 24 tc 0 24 0 r . . 8 8 8 0 0 24 0 0 0 0 0 0 0 None -0xed 24 tc 0 24 0 r y . 8 8 8 0 0 24 0 0 0 0 0 0 0 None 0xef 24 tc 0 24 0 r . . 8 8 8 0 0 24 8 0 0 0 0 0 0 None 0xf1 24 tc 0 24 0 r y . 8 8 8 0 0 24 8 0 0 0 0 0 0 None 0xf2 24 tc 0 24 0 r y . 8 8 8 0 0 24 8 16 16 16 0 0 0 Slow 0xf3 24 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None 0xf5 24 tc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None -0xfb 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0xfe 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x100 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x101 24 dc 0 24 0 r . . 8 8 8 0 0 0 0 0 0 0 0 0 0 None 0x103 24 dc 0 24 0 r y . 8 8 8 0 0 0 0 0 0 0 0 0 0 None -0x109 24 dc 0 24 0 r . . 8 8 8 0 0 24 0 0 0 0 0 0 0 None -0x10b 24 dc 0 24 0 r y . 8 8 8 0 0 24 0 0 0 0 0 0 0 None 0x10d 24 dc 0 24 0 r . . 8 8 8 0 0 24 8 0 0 0 0 0 0 None 0x10f 24 dc 0 24 0 r y . 8 8 8 0 0 24 8 0 0 0 0 0 0 None 0x110 24 dc 0 24 0 r y . 8 8 8 0 0 24 8 16 16 16 0 0 0 Slow 0x111 24 dc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None 0x113 24 dc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None -0x119 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None -0x11b 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x11d 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x11f 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow -0x62 32 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None -38 GLXFBConfigs: +30 GLXFBConfigs: visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- @@ -128,15 +120,11 @@ 0x7e 0 tc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x83 0 tc 0 24 0 r . . 8 8 8 0 0 0 0 0 0 0 0 0 0 None 0x85 0 tc 0 24 0 r y . 8 8 8 0 0 0 0 0 0 0 0 0 0 None -0x8b 0 tc 0 24 0 r . . 8 8 8 0 0 24 0 0 0 0 0 0 0 None -0x8d 0 tc 0 24 0 r y . 8 8 8 0 0
Re: [Intel-gfx] XVideo triggering GPU Hangs on i8xx
On Wed, 2010-06-30 at 09:11 +0100, Glen Gray wrote: Hey Guys, I'm testing out 2.11/2.6.33.5-124(Fedora 13) on our embedded panel pc hardware. It's got an 855GM/ICH4 chipset. On previous versions of the drivers, in Fedora 12 for example, XVideo extension wasn't reported as available. On Fedora 13 with the 2.11/2.6.33.5 kernel, XVideo is reported. However, when attempting to use it, a gpu hang is triggered. Is XVideo extension expected to work on i8XX hardware ? We've seen similar issues on Ubuntu (albeit with the 2.9 DDX). I'd guess it's a manifestation of the i855 GTT coherency bug¹ (or is another bug masked by that). [1]: http://bugs.freedesktop.org/show_bug.cgi?id=27187 signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim
On Wed, Jun 30, 2010 at 4:07 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
That commit changes the page cache allocation to use
+ mapping_gfp_mask (mapping) |
+ __GFP_COLD |
+ gfpmask);
if I read it right. And the default mapping_gfp_mask() is
GFP_HIGHUSER_MOVABLE, so I think you get all of
(__GFP_WAIT | __GFP_IO | __GFP_FS | __GFP_HARDWALL | __GFP_HIGHMEM)
set by default.
.. and then I left out the one flag I _meant_ to have there, namely
__GFP_MOVABLE.
The old code didn't just play games with ~__GFP_NORETRY and change
that at runtime (which was buggy - no locking, no protection, no
nothing), it also initialized the gfp mask. And that code also got
removed:
In fact, I don't really see why we should use that mapping_gfp_mask()
at all, since all allocations should be going through that
i915_gem_object_get_pages() function anyway. So why not just change
that function to ignore the default gfp mask for the mapping, and just
use the mask that the o915 driver wants?
Btw, why did it want to mark the pages reclaimable?
Anyway, what I'm suggesting somebody who sees this test is just
something like the patch below (whitespace-damage - I'm cutting and
pasting, it's a trivial one-liner). Does this change any behavior?
Vefa?
Linus
---
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9ded3da..ec8ed6b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2239,7 +2239,7 @@ i915_gem_object_get_pages(struct drm_gem_object *obj,
mapping = inode-i_mapping;
for (i = 0; i page_count; i++) {
page = read_cache_page_gfp(mapping, i,
- mapping_gfp_mask (mapping) |
+ GFP_HIGHMEM |
__GFP_COLD |
gfpmask);
if (IS_ERR(page))
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] X201 + i915 pll problem
Has anyone seen and/or fixed: [drm:drm_mode_debug_printmodeline], Modeline 12:1280x800 60 68940 1280 1296 1344 1408 800 801 804 816 0x48 0xa [drm:ironlake_crtc_dpms], crtc 1 dpms off [drm:ironlake_crtc_dpms], crtc 1 is disabled [drm:intel_crtc_mode_set], using SSC reference clock of 120 MHz [drm:intel_crtc_mode_set] *ERROR* Couldn't find PLL settings for mode! [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on crtc 88022e4ff000 fbcon_init: detected unhandled fb_set_par error, error code -22 Its an Arrandale X201, I have one with a slightly different panel and it seems fine, this one another person has doesn't. (II) intel(0): EDID for output LVDS1 (II) intel(0): Manufacturer: LEN Model: 4011 Serial#: 0 (II) intel(0): Year: 2009 Week: 0 (II) intel(0): EDID Version: 1.3 (II) intel(0): Digital Display Input (II) intel(0): Max Image Size [cm]: horiz.: 26 vert.: 16 (II) intel(0): Gamma: 2.20 (II) intel(0): DPMS capabilities: StandBy Suspend Off (II) intel(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 (II) intel(0): First detailed timing is preferred mode (II) intel(0): redX: 0.575 redY: 0.360 greenX: 0.370 greenY: 0.555 (II) intel(0): blueX: 0.155 blueY: 0.110 whiteX: 0.313 whiteY: 0.329 (II) intel(0): Manufacturer's mask: 0 (II) intel(0): Supported detailed timing: (II) intel(0): clock: 68.9 MHz Image Size: 261 x 163 mm (II) intel(0): h_active: 1280 h_sync: 1296 h_sync_end 1344 h_blank_end 1408 h_border: 0 (II) intel(0): v_active: 800 v_sync: 801 v_sync_end 804 v_blanking: 816 v_border: 0 (II) intel(0): Supported detailed timing: (II) intel(0): clock: 61.0 MHz Image Size: 261 x 163 mm (II) intel(0): h_active: 1280 h_sync: 1328 h_sync_end 1360 h_blank_end 1478 h_border: 0 (II) intel(0): v_active: 800 v_sync: 803 v_sync_end 809 v_blanking: 825 v_border: 0 (II) intel(0): Unknown vendor-specific block f (II) intel(0): LTN121AT07L02 (II) intel(0): EDID (in hex): (II) intel(0): 000030ae1140 (II) intel(0): 00130103801a1078ea5cd5935c5e8e27 (II) intel(0): 1c50540001010101010101010101 (II) intel(0): 010101010101ee1a0080502010301030 (II) intel(0): 130005a31019d01700c650201930 (II) intel(0): 3020360005a31019000f0081 (II) intel(0): 0a3c810a321609004ca3415400fe (II) intel(0): 004c544e313231415430374c30320038 Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] X201 + i915 pll problem
On 2010.07.01 13:18:39 +1000, Dave Airlie wrote: Has anyone seen and/or fixed: https://bugs.freedesktop.org/show_bug.cgi?id=27471 Looks this timing is really a corner case in our PLL calculation, which is not covered in current error range. So I tried to fallback to the most close one. [drm:drm_mode_debug_printmodeline], Modeline 12:1280x800 60 68940 1280 1296 1344 1408 800 801 804 816 0x48 0xa [drm:ironlake_crtc_dpms], crtc 1 dpms off [drm:ironlake_crtc_dpms], crtc 1 is disabled [drm:intel_crtc_mode_set], using SSC reference clock of 120 MHz [drm:intel_crtc_mode_set] *ERROR* Couldn't find PLL settings for mode! [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on crtc 88022e4ff000 fbcon_init: detected unhandled fb_set_par error, error code -22 Its an Arrandale X201, I have one with a slightly different panel and it seems fine, this one another person has doesn't. (II) intel(0): EDID for output LVDS1 (II) intel(0): Manufacturer: LEN Model: 4011 Serial#: 0 (II) intel(0): Year: 2009 Week: 0 (II) intel(0): EDID Version: 1.3 (II) intel(0): Digital Display Input (II) intel(0): Max Image Size [cm]: horiz.: 26 vert.: 16 (II) intel(0): Gamma: 2.20 (II) intel(0): DPMS capabilities: StandBy Suspend Off (II) intel(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 (II) intel(0): First detailed timing is preferred mode (II) intel(0): redX: 0.575 redY: 0.360 greenX: 0.370 greenY: 0.555 (II) intel(0): blueX: 0.155 blueY: 0.110 whiteX: 0.313 whiteY: 0.329 (II) intel(0): Manufacturer's mask: 0 (II) intel(0): Supported detailed timing: (II) intel(0): clock: 68.9 MHz Image Size: 261 x 163 mm (II) intel(0): h_active: 1280 h_sync: 1296 h_sync_end 1344 h_blank_end 1408 h_border: 0 (II) intel(0): v_active: 800 v_sync: 801 v_sync_end 804 v_blanking: 816 v_border: 0 (II) intel(0): Supported detailed timing: (II) intel(0): clock: 61.0 MHz Image Size: 261 x 163 mm (II) intel(0): h_active: 1280 h_sync: 1328 h_sync_end 1360 h_blank_end 1478 h_border: 0 (II) intel(0): v_active: 800 v_sync: 803 v_sync_end 809 v_blanking: 825 v_border: 0 (II) intel(0): Unknown vendor-specific block f (II) intel(0): LTN121AT07L02 (II) intel(0): EDID (in hex): (II) intel(0):000030ae1140 (II) intel(0):00130103801a1078ea5cd5935c5e8e27 (II) intel(0):1c50540001010101010101010101 (II) intel(0):010101010101ee1a0080502010301030 (II) intel(0):130005a31019d01700c650201930 (II) intel(0):3020360005a31019000f0081 (II) intel(0):0a3c810a321609004ca3415400fe (II) intel(0):004c544e313231415430374c30320038 Dave. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
