[ANNOUNCE] libdrm 2.4.29
This publishes some new API for Intel to be able to cap the number of VMA that libdrm_intel caches amongst its bo. This is intended to be used by clients to prevent applications (such as the xserver) from exhausting their per-process limits on inactive GTT mmaps whilst also mitigating against the costs of recreating those mmaps. -Chris Chris Wilson (6): intel: Clean up mmaps on freeing the buffer intel: Add an interface to limit vma caching intel: Evict cached VMA in order to make room for new mappings intel: Update map-count for an early error return during mapping intel: Remove the fresh assertions used to debug the vma cacheing configure: Bump version for 2.4.29 Dave Airlie (1): test/radeon: add missing files for dist git tag: 2.4.29 http://dri.freedesktop.org/libdrm/libdrm-2.4.29.tar.bz2 MD5: 96d5e3e9edd55f4b016fe3b5dd0a1953 libdrm-2.4.29.tar.bz2 SHA1: 054ca4f6b9145b1bb5192f3cba4dd1835fcc5977 libdrm-2.4.29.tar.bz2 SHA256: e2432dc93e933479132123a1dca382294c30f55bc895bb737b6bdd6f2b8c452e libdrm-2.4.29.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.29.tar.gz MD5: 2596e48b4d2663ed075f0a86e977cf99 libdrm-2.4.29.tar.gz SHA1: 68d46937f5e725b439a8ed748211f0a27168caf3 libdrm-2.4.29.tar.gz SHA256: d60ecf6fc52f92663ee80cc94560ead56b493e4b91d1ee99f2292f7ecdab40b2 libdrm-2.4.29.tar.gz -- Chris Wilson, Intel Open Source Technology Centre signature.asc Description: Digital signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: EXA performance problem
On Sun, 27 Nov 2011 15:55:12 +0100, Christoph Bartoschek bartosc...@or.uni-bonn.de wrote: Hi, I still have a huge performance problem with Xorg. One application that painted 2 Mio rectangles on the screen within a second or so with XFree86 needs about a minute with Xorg. The easiest way for anyone else to reproduce this issue would be if you were to identify the most common slow op and translate that into the appropriate x11perf command line. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-video-intel 2.17.0
A few months have passed, and we have accumulated a surprising number of bug fixes. Oops! We would strongly encourage everyone to upgrade. -Chris Bugs fixed in this release (compared to 2.16.0) --- * Video clobbering composite batch state http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635953 * Incorrect reuse of surface bindings within a batch for multiple formats https://bugs.freedesktop.org/show_bug.cgi?id=40926 * Nothing was rendered for text with procedural sources https://bugs.freedesktop.org/show_bug.cgi?id=31819 * Handle fallbacks involving alpha maps * Workaround blitter hang on SandyBridge and IvyBridge https://bugzilla.kernel.org/show_bug.cgi?id=27892 https://bugs.freedesktop.org/show_bug.cgi * Workaround pipe control issues on SandyBridge * Use correct maximum PS thread count on IvyBridge * Protect against failed pixmap allocation for XV https://bugs.freedesktop.org/show_bug.cgi?id=40439 git tag: 2.17.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.17.0.tar.bz2 MD5: 6d7b1f199dba5820f250888b136186ff xf86-video-intel-2.17.0.tar.bz2 SHA1: 04ad9fa1f4c4e0a90f48752a709bf14700c864af xf86-video-intel-2.17.0.tar.bz2 SHA256: 8b8450f2a2cc52ef31a83414e2f290e748a956690e11b41759d5650aaedc4387 xf86-video-intel-2.17.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.17.0.tar.gz MD5: 7443f0054f9c81aad7facecbef3daef0 xf86-video-intel-2.17.0.tar.gz SHA1: aeea2c4e8e9c25b84802c2f0dc26942ccc3590c1 xf86-video-intel-2.17.0.tar.gz SHA256: 7da1d957b4abe6da38958f3c282d857138e7318028286dc1a1f57df5e0ff0da8 xf86-video-intel-2.17.0.tar.gz -- Chris Wilson, Intel Open Source Technology Centre signature.asc Description: Digital signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: xrender issue
On Fri, 04 Nov 2011 11:26:07 +0100, Hans-Peter Budek peter.bu...@gmx.de wrote: Hi, if I set an alpha-map to a destination picture via XRenderChangePicture(s-Dpy, Dest, CPAlphaMap, Att) ; the following XRenderComposite() call crash my X-server: Backtrace: [ 9911.289] 0: /usr/X11R6/bin/X (xorg_backtrace+0x37) [0x80e8997] [ 9911.289] Segmentation fault at address (nil) [ 9911.289] Fatal server error: [ 9911.289] Caught signal 11 (Segmentation fault). Server aborting [ 9911.289] [ 9911.289] Please consult the The X.Org Foundation support X.Org X Server 1.9.5 [ 9887.642] (II) Module intel: vendor=X.Org Foundation [ 9887.642] compiled for 1.9.5, module version = 2.14.0 is this a known bug? It is now. I'll have a fix shortly, though you will still be triggering CPU fallbacks. Do you mind describing you use-case for alphamaps and could you create a little benchmark for your workload? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: xrender issue
On Fri, 04 Nov 2011 15:11:28 +0100, Hans-Peter Budek peter.bu...@gmx.de wrote:
Chris Wilson wrote:
Do you mind describing you use-case for alphamaps and could you create a
little benchmark for your workload?
-Chris
I´am programming a animated crossfade from one window to another.
Both windows are not created by my application. The content
of both windows is previously stored in a ARGB32 picture
(without a usable alpha channel). To apply an alpha channel, I use:
So what I think you want to achieve is:
dst = a * srcA + (1-a) * srcB
which can be acheived (and hitting the accelerated paths) with:
Picture a = XRenderCreateSolidFill(dpy, (XRenderColor){.alpha = 0x *
Fade});
Picture ia = XRenderCreateSolidFill(dpy, (XRenderColor){.alpha = 0x *
(1-Fade)});
XRenderComposite(dpy, PictOpSrc, srcA, a, dst, 0, 0, 0, 0, 0, 0, width,
height);
XRenderComposite(dpy, PictOpAdd, srcB, ia, dst, 0, 0, 0, 0, 0, 0, width,
height);
XRenderFreePicture(dpy, ia);
XRenderFreePicture(dpy, a);
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-video-intel 2.15.0
After a quiet couple of days, I want to get the bug fixes we have accumulated shipped. Thank you everybody for your invaluable testing and feedback. -Chris We are pleased to announce this major release of the xf86-video-intel driver, roughly on schedule at 3 months since 2.14.0. With the many bug fixes in this release, we encourage everyone to upgrade to 2.14. The priority for this quarter has been simply to be unexciting and stabilise the driver further, seeking to capitalise upon the improvements elsewhere in the stack. Bugs fixed in this snapshot (compared to 2.14.903) -- * Turn off relaxed fencing by default for older chipsets This was continuing to destabilize those system, so for the release we disabled the feature. If you wish to help us debug this, you can re-enable the optimisation with Option RelaxedFencing True. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36147 * Build fix for xserver-1.7.7 * KDE glitches on SNB [Technically fixed in the previous snapshot, but I'm really pleased that this got fixed in time for the release!] https://bugs.freedesktop.org/show_bug.cgi?id=35808 Chris Wilson (3): dri: Rearrange code to compile against xorg-server-1.7 Turn relaxed-fencing off by default for older (pre-G33) chipsets configure,NEWS: 2.15.0 release git tag: 2.15.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.15.0.tar.bz2 MD5: ba56ae395a9769ada1fef2014468bee9 xf86-video-intel-2.15.0.tar.bz2 SHA1: 78ec39a4470cfc0bf13d269fb915f6c5a498ee62 xf86-video-intel-2.15.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.15.0.tar.gz MD5: fab96925b6b2fd6863be8e7b59ceb38b xf86-video-intel-2.15.0.tar.gz SHA1: 0a5cb7f40ad9b1fe10479aeea55e42110fb21810 xf86-video-intel-2.15.0.tar.gz -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xf86-video-intel 2.15.0
After a quiet couple of days, I want to get the bug fixes we have accumulated shipped. Thank you everybody for your invaluable testing and feedback. -Chris We are pleased to announce this major release of the xf86-video-intel driver, roughly on schedule at 3 months since 2.14.0. With the many bug fixes in this release, we encourage everyone to upgrade to 2.14. The priority for this quarter has been simply to be unexciting and stabilise the driver further, seeking to capitalise upon the improvements elsewhere in the stack. Bugs fixed in this snapshot (compared to 2.14.903) -- * Turn off relaxed fencing by default for older chipsets This was continuing to destabilize those system, so for the release we disabled the feature. If you wish to help us debug this, you can re-enable the optimisation with Option RelaxedFencing True. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36147 * Build fix for xserver-1.7.7 * KDE glitches on SNB [Technically fixed in the previous snapshot, but I'm really pleased that this got fixed in time for the release!] https://bugs.freedesktop.org/show_bug.cgi?id=35808 Chris Wilson (3): dri: Rearrange code to compile against xorg-server-1.7 Turn relaxed-fencing off by default for older (pre-G33) chipsets configure,NEWS: 2.15.0 release git tag: 2.15.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.15.0.tar.bz2 MD5: ba56ae395a9769ada1fef2014468bee9 xf86-video-intel-2.15.0.tar.bz2 SHA1: 78ec39a4470cfc0bf13d269fb915f6c5a498ee62 xf86-video-intel-2.15.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.15.0.tar.gz MD5: fab96925b6b2fd6863be8e7b59ceb38b xf86-video-intel-2.15.0.tar.gz SHA1: 0a5cb7f40ad9b1fe10479aeea55e42110fb21810 xf86-video-intel-2.15.0.tar.gz -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] libdrm 2.4.25
My need for releasing libdrm at this moment is to get the bug fix out for running current Intel Mesa drivers with older kernels. But 2.4.25 looks to be an exciting release in its own right! Dave Airlie has added his dumb fb interface so that plymouth and friends can use a generic kms/fb backend, moving the complexity out of plymouth and down into the kernel where it already existed. And from Ilija Hadzic we an improvement to handle vblanks on more than 2 monitors. -Chris Ben Skeggs (1): Implement drmGetCap() to query device/driver capabilities Chris Wilson (2): intel: Also handle mrb_exec fallback with ring == I915_EXEC_RENDER configure: version bump for 2.4.25 release Daniel Vetter (1): Cleanup gen2 tiling confusion Dave Airlie (4): drm: add dumb interface libkms: add dumb support libdrm: oops fix get cap return value. drm_mode: fix types on recently added ioctls Ilija Hadzic (1): libdrm: (revised) vblank wait on crtc 1 Javier Jardón (1): build: Update autotools configuration Kristian Høgsberg (1): Build modetest for all chipsets, always build modeprint Matt Turner (1): don't try to build modetest without libkms git tag: 2.4.25 http://dri.freedesktop.org/libdrm/libdrm-2.4.25.tar.bz2 MD5: f53dc4c72109b17908e4113c3b8addfe libdrm-2.4.25.tar.bz2 SHA1: b950f29cd1c4bb9f1c98a926486a47256b0a4194 libdrm-2.4.25.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.25.tar.gz MD5: e9636c60e67ed0f90b327b599e833514 libdrm-2.4.25.tar.gz SHA1: 3b90c39946aaf14af0e97956306e7e908327a629 libdrm-2.4.25.tar.gz -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: Any ideas about this? (i915 caused kernel oops while suspending to RAM)
On Tue, 22 Mar 2011 22:21:24 +0100, Åukasz MaÅko e...@yen.ipipan.waw.pl wrote: It says (or at leas it seems so) that it was the i915 graphics drm module which caused it. My machine has i945GM graphics chipset. Currently I'm running xserver 1.10.0 and intel driver 2.14.0. Both of these oopses happened with 2.6.37.4 kernel, which I've been using since Saturday. There were no such problems with earlier kernels. You were fortunate, as the bug in all its guises is much older indeed. The final fix, I hope, was: commit 9334ef755f060e251f3f395caeda1a58b6834ea3 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Fri Jan 28 11:53:03 2011 + drm: Don't switch fb when disabling an output In drm_crtc_helper_set_config, we call drm_crtc_helper_set_mode which may return early and do no operation if the crtc is to be disabled. In this case we merrily swap to the new fb, discarding the old_fb believing that it has been cleaned up. However, due to the early return, the old_fb was not presented to the backend for correct reaping, and nor was the new one - which is about to be reaped via the drm_helper_disable_unused_functions(), leading to incorrect refcounting of the pinned objects. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=27722 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29857 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29230 Tested-by: Takashi Iwai ti...@suse.de Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Intel (Xorg-7.6): No kernel modesetting driver detected
On Mon, 24 Jan 2011 12:27:20 -0600 (CST), al...@verizon.net wrote: Waiting with bated breath for us to come with a happy resolution on the intel driver. You need to enable kernel modesetting to use the current stable releases of -intel. Check you have CONFIG_DRM_I915 and CONFIG_DRM_I915_KMS enabled for your kernel. The latter can be optionally replaced with i915.modeset on the boot command line or at module load time. This does presume that you have at least a 2.6.29 kernel. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Intel (Xorg-7.6): No kernel modesetting driver detected
On Mon, 24 Jan 2011 19:01:57 -0600 (CST), al...@verizon.net wrote: For some reason, the boot parameter you suggested (grub excerpt): Â Â Â Â Â Â Â Â kernel /boot/LFSkernel root=/dev/sda3 i915.modeset=1 does not work. Â The system remains regular (non-KMS), thus the Original Post (problem) Then your modprobe is not parsing the command line for any relevant module parameters and would need to put those into 'echo options i915 modeset=1 /etc/modprobe.d/i915-modeset.conf' Is there a way, once up in KMS, to dynamically switch to my old VGA Text mode (from this crazy 240x67) and, ideally, back to KMS too? look at Documentation/fb/modedb.txt for a description of the video= parameter to specify the mode for the console. Something like video=640x480 will restore the VGA mode with 80x25 characters. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-video-intel 2.14.0
Immediately upon tagging the last snapshot, I hit an assertion failure. Typical. However, nobody else has complained of any new issue arising from the snapshot, so I hereby proclaim 2.14.0 is ready for distribution. Enjoy. -Chris Chris Wilson (3): i965: Fix off-by-one in assert NEWS: Release notes for 2.14.0 configure: version bump for 2.14.0 git tag: 2.14.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.14.0.tar.bz2 MD5: 05f187582aeabda57fcd6f2782cfbf8e xf86-video-intel-2.14.0.tar.bz2 SHA1: 103193a01b9c29d6f71a620ad99c6e1495276e68 xf86-video-intel-2.14.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.14.0.tar.gz MD5: 83ae6bc074094433d0cdf147582218ae xf86-video-intel-2.14.0.tar.gz SHA1: ceedff38447e99419db84466ac0e0f13d766ebba xf86-video-intel-2.14.0.tar.gz -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xf86-video-intel 2.14.0
Immediately upon tagging the last snapshot, I hit an assertion failure. Typical. However, nobody else has complained of any new issue arising from the snapshot, so I hereby proclaim 2.14.0 is ready for distribution. Enjoy. -Chris Chris Wilson (3): i965: Fix off-by-one in assert NEWS: Release notes for 2.14.0 configure: version bump for 2.14.0 git tag: 2.14.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.14.0.tar.bz2 MD5: 05f187582aeabda57fcd6f2782cfbf8e xf86-video-intel-2.14.0.tar.bz2 SHA1: 103193a01b9c29d6f71a620ad99c6e1495276e68 xf86-video-intel-2.14.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.14.0.tar.gz MD5: 83ae6bc074094433d0cdf147582218ae xf86-video-intel-2.14.0.tar.gz SHA1: ceedff38447e99419db84466ac0e0f13d766ebba xf86-video-intel-2.14.0.tar.gz -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-video-intel 2.13.903
Time for another xf86-video-intel snapshot. Hopefully this will be the last before we tag the release. Please test. -Chris Adam Jackson (2): xv: Fix interlace computation dri2: Fix interlace computation Chris Wilson (16): NEWS: 2.14, I meant the upcoming 2.14 release! G35 is gen4 and not gen3 Undo: Disable BLT for i830 and 845G Suggest where to find xorg-macros in case it's missing Revert Suggest where to find xorg-macros in case it's missing Remove the deprecated function 'XNFprintf' i830: amalgamate consecutive composites into a single primitive dri: Differentiate identical get vblank failed messages with line no Don't replace the scanout bo through PutImage dri: Protect against using dri with an non-gem pixmap dri: Fix the use of the uninitialised bo for flink dri: Don't wait upon a NULL current mode dri: Only issue a warning for an impossible flip return 5 times If the crtc is not enabled, then it can't be on NEWS: Add entry for 2.13.903 configure: version bump for 2.13.903 snapshot Mario Kleiner (2): Fix reporting of pageflip completion events on multi-head. Check consistency of pageflip completion vblank count. U. Artie Eoff (2): configure: updated m4 macro check in configure.ac configure: suggest upstream to find macros in case they're missing. git tag: 2.13.903 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.13.903.tar.bz2 MD5: 98a6cf2e9535a7ed56f03b0f6cbeb1c1 xf86-video-intel-2.13.903.tar.bz2 SHA1: 4ef6414055ceb3f98e4fec3481f3d9e7f08a5512 xf86-video-intel-2.13.903.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.13.903.tar.gz MD5: 15d76b9f35609eb21a9dc8f9195729e0 xf86-video-intel-2.13.903.tar.gz SHA1: f5466905dba77c20cb32a9190487515f38e27451 xf86-video-intel-2.13.903.tar.gz -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xf86-video-intel 2.13.903
Time for another xf86-video-intel snapshot. Hopefully this will be the last before we tag the release. Please test. -Chris Adam Jackson (2): xv: Fix interlace computation dri2: Fix interlace computation Chris Wilson (16): NEWS: 2.14, I meant the upcoming 2.14 release! G35 is gen4 and not gen3 Undo: Disable BLT for i830 and 845G Suggest where to find xorg-macros in case it's missing Revert Suggest where to find xorg-macros in case it's missing Remove the deprecated function 'XNFprintf' i830: amalgamate consecutive composites into a single primitive dri: Differentiate identical get vblank failed messages with line no Don't replace the scanout bo through PutImage dri: Protect against using dri with an non-gem pixmap dri: Fix the use of the uninitialised bo for flink dri: Don't wait upon a NULL current mode dri: Only issue a warning for an impossible flip return 5 times If the crtc is not enabled, then it can't be on NEWS: Add entry for 2.13.903 configure: version bump for 2.13.903 snapshot Mario Kleiner (2): Fix reporting of pageflip completion events on multi-head. Check consistency of pageflip completion vblank count. U. Artie Eoff (2): configure: updated m4 macro check in configure.ac configure: suggest upstream to find macros in case they're missing. git tag: 2.13.903 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.13.903.tar.bz2 MD5: 98a6cf2e9535a7ed56f03b0f6cbeb1c1 xf86-video-intel-2.13.903.tar.bz2 SHA1: 4ef6414055ceb3f98e4fec3481f3d9e7f08a5512 xf86-video-intel-2.13.903.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.13.903.tar.gz MD5: 15d76b9f35609eb21a9dc8f9195729e0 xf86-video-intel-2.13.903.tar.gz SHA1: f5466905dba77c20cb32a9190487515f38e27451 xf86-video-intel-2.13.903.tar.gz -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: commit 53fbc9f1760ee481cba1f6dceb9e7c97282a2976 broke vmware
On Sat, 1 Jan 2011 01:55:05 +0800, Jeff Chua jeff.chua.li...@gmail.com wrote: On Sat, Jan 1, 2011 at 1:12 AM, Julien Cristau jcris...@debian.org wrote: On Sat, Jan  1, 2011 at 00:56:48 +0800, Jeff Chua wrote: Vmware 7.1.3 crashed with the commit. Reverting it makes vmware happy again. Symptom: upon starting starting vmware, X crashed. X log?  gdb backtrace? Hope this help ... This should fix it: commit 537fa55ed2449e91f3dd1e04abc720c6818d7227 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Sun Jan 2 09:06:28 2011 + dri: Fix the use of the uninitialised bo for flink Reported-by: Jeff Chua jeff.chua.li...@gmail.com Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Problem with resolution 1366x768 on intel 945 GME
On Wed, 15 Dec 2010 17:24:49 +0530, DarkKnight BrightWarrior bindasbe...@gmail.com wrote: I want 1366x768 resolution with rotation support. Use the intel driver as that is the one for your chipset. xrandr -o left,right,inverted,normal function as expected on my 945s. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Intel card not detected after upgrade
On Mon, 13 Dec 2010 00:27:06 +0100, Ole Tange o...@tange.dk wrote: I just upgraded a Debian system. After the upgrade X refuses to use the intel driver but insists on using VESA. The -intel driver no longer uses UMS and relies on Kernel Mode Setting instead. In order to activate KMS it needs to be either enabled when compiled into your kernel, or you need to add i915.modeset=1 to your module options, e.g.: $ echo options i915 modeset=1 /etc/modprobe.d/i915-kms.conf This should have been taken care of during a debian upgrade. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Intel card not detected after upgrade
On Mon, 13 Dec 2010 22:09:27 +0100, Ole Tange o...@tange.dk wrote: This was actually taken care of by the upgrade. What was missing was adding i915 to /etc/modules; when I added that, everything worked as expected. This is the second time I have be bitten by a missing loaded module (First time: http://www.mail-archive.com/xorg@lists.freedesktop.org/msg12767.html). It would be terrible helpful if the error message for Xorg mentioned that you might need to load a module, as Xorg clearly detected my intel card and thus should be able to guess that I probably wanted to use the intel driver. If Xorg.0.log had contained a message like: It should have autoloaded the i915 module before giving up. I'll look into that, thanks. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] libdrm 2.4.23
I've tagged a release for libdrm 2.4.23 principally to expose the new kernel parameters for BLT support on SandyBridge and relaxed fencing which are needed to build the next release of xf86-video-intel. However, I'm lacking sufficient privileges to actually upload the tarballs myself at the moment, so you'll have to make do with the git tag! -Chris Adam Jackson (1): s/drmStrdup/strdup/ Albert Damen (1): intel: initialize bufmgr.bo_mrb_exec unconditionally Chris Wilson (9): intel: Downgrade error warnings to debug intel: Prepare for BLT ring split. intel: enable relaxed fence allocation for i915 intel: Compute in-aperture size for relaxed fenced objects intel: Add a forward declaration of struct drm_clip_rect intel: If the command is fenced inform the kernel intel: Reorder need_fence vs fenced_command to avoid fences on gen4 tests: Update for ENOENT returns from unknown handles configure: Bump version to 2.4.23 Dave Airlie (1): drm: don't do the create the node ourselves if we have udev. Eric Anholt (5): intel: Remove stale comment. intel: Shove the fake bufmgr subdata implementation into the fake bufmgr. intel: Remove gratuitous assert on bo_reference. intel: Drop silly asserts on mappings present at unmap time. intel: Fix drm_intel_gem_bo_wait_rendering to wait for read-only usage too. Francisco Jerez (5): nouveau: Define buffer object usage flags. nouveau: Let the user choose the push buffer size. nouveau: Define the HAS_PAGEFLIP getparam. nouveau: Avoid unnecessary call to CPU_FINI. nouveau: Add implicit pushbuf flush before gpuobj destruction. Marek Olšák (1): radeon: silence valgrind warnings by zeroing memory git tag: 2.4.23 http://dri.freedesktop.org/libdrm/libdrm-2.4.23.tar.bz2 MD5: 7577ff36ec364d88fae466d4f7fc5fc6 libdrm-2.4.23.tar.bz2 SHA1: 9d651d1e394654c02343e3d95c0f8a442a91ac75 libdrm-2.4.23.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.23.tar.gz MD5: 82b116a4fc80d44fafe80af9b53100cb libdrm-2.4.23.tar.gz SHA1: 585d3028e838badea1fc057027f7eee837ea680d libdrm-2.4.23.tar.gz -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xf86-video-intel 2.13.902
It's getting close to party time, and so for all of those lucky enough to be receiving Sandy Bridge stocking fillers this Christmas, Intel would like to present you with a working driver... But first you have to help us test it! So without further ado, here is the first release candidate for 2010Q4. -Chris Chris Wilson (26): uxa: Fix crash after allocation failure i915: Disable maximum state addresses uxa: Relax fencing some more for gen3 Disable BLT for i830 and 845G i965: Use reciprocal scale factors to avoid the divide per-vertex-element i965: Upload an entire vbo in a single pwrite, rather than per-rectangle i965: Amalgamate surface binding tables Wait on the current buffer to complete when running synchronously. i965: Check for potential vertex array overflow every time i965: Also flush the vertex buffer when restarting the array. display: Flush any pending batches before changing modes. uxa: Prevent reading past the last byte on upload/download snb: Emit more invariants only once snb: Cache state between composite ops snb: Cache pixmap binding locations snb: Restore drawrect, we need the implicit flush snb: Only emit CC and DepthStencil bos once per batch uxa: Emit the damage after the render for the workaround in uxa_solid_rects Always flush the batch before blocking for new X requests i965: Invalidate pixmap binding location on reuse. i965: The RenderCache flush after every glyph is required for compiz i965: Mark sure we mark reused render targets as dirty Revert i965: The RenderCache flush after every glyph is required for compiz configure: Bump required libdrm to 2.4.23 NEWS: Add entry for the 2.13.902 snapshot configure: version bump for 2.13.902 Keith Packard (1): Mark outputs as DPMSModeOn and restore backlight at mode set Matthias Hopf (1): Don't use hardware acceleration on Sandybridge rev 07 hardware or earlier. git tag: 2.13.902 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.13.902.tar.bz2 MD5: e93b7967df7839b0e4d220a2a7a2d0b7 xf86-video-intel-2.13.902.tar.bz2 SHA1: 3ecd3c8bcdf8229131335e3ba59eeb4380532284 xf86-video-intel-2.13.902.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.13.902.tar.gz MD5: 4e43c1861687da2f9621cc50931b5dc7 xf86-video-intel-2.13.902.tar.gz SHA1: 99512d07300948a0098065d10362d0e4b93679f8 xf86-video-intel-2.13.902.tar.gz -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: [ANNOUNCE] xf86-video-intel 2.13.0
On Thu, 30 Sep 2010 13:22:50 -0500, Robby Workman r...@rlworkman.net wrote: I hate to dredge up what might be an old discussion by now, but kwin in KDE 4.5.1 won't work here (resulting in desktop crash) unless I disable compositing entirely. This is with latest stable releases of everything in ftp.x.org/pub/individual/*/, to include libdrm-2.4.22, mesa-7.8.2, xorg-server-1.9.0, and xf86-video-intel-2.13.0 on a Lenovo T400 with this: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller Where's the crash? If you could file a bug on fd.o then it will get fixed. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [Intel-gfx] Intel 2010Q2 release
On Sun, 27 Jun 2010 13:36:15 +0300, Vasily Khoruzhick anars...@gmail.com wrote: Ð ÑообÑении Ð¾Ñ 25 иÑÐ½Ñ 2010 05:07:37 авÑÐ¾Ñ Jin, Gordon напиÑал: Thanks community for helping improve the drivers. If you find new issues, please file bugs referring to http://intellinuxgraphics.org/how_to_report_bug.html. I'm getting GPU hang (it's easy to reproduce it) on 945gm with xf86-video- intel-2.12.0 (actually whole 2010Q2 package) in KDE 4.4.2 with effects enabled. I'm sure that xf86-video-intel-2.12.0 is culprit, as I downgraded to 2.11.0 and system is stable again. Can you please file a bug as detailed above? Getting the i915_error_state and Xorg.log would be most useful. Are you using XRender or OpenGL desktop effects? Thanks. -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [Intel-gfx] Intel 2010Q2 release
On Sun, 27 Jun 2010 14:30:24 +0300, Vasily Khoruzhick anars...@gmail.com wrote: Ok, I'll file bug once I reproduce it once again (can't reproduce it since posted first mail :(). Thankyou, the information will be appreciated. Btw, there's another bug - I can't enable external monitor with kde effects (opengl) enabled, 'xrandr --output VGA1 --mode 1920x1080 --below LVDS1' causes black screen both on VGA1 and LVDS1 (1280x800). It works fine with effects disabled, and fine at all with xf86- video-intel 2.11.0. Bug is 100% reproducible. You need libdrm.git, in particular: commit 726210f87d558d558022f35bc8c839e798a19f0c Author: Chris Wilson ch...@chris-wilson.co.uk Date: Thu Jun 24 11:38:00 2010 +0100 intel: Limit tiled pitches to 8192 on pre-i965. Fixes: Bug 28515 - Failed to allocate framebuffer when exceed 2048 width https://bugs.freedesktop.org/show_bug.cgi?id=28515 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Xorg server using 100% CPU. Can reproduce. Need help to track the issue
On Tue, 11 May 2010 14:58:35 -0400, phil lemelin phil.leme...@gmail.com wrote: Good evening list, I'm having a reproducible issue with the X when using vmg ( http://magnifier.sourceforge.net/ ). It will systematically make the Xorg process use 100% cpu and basically locks the machine. I just start it, move it around and I hit the issue. Sounds like https://bugzilla.kernel.org/show_bug.cgi?id=15911 -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel and Xorg freeze - what may be the problem?
On Tue, 20 Apr 2010 11:10:29 +0200, Åukasz MaÅko e...@yen.ipipan.waw.pl wrote: Today I got my Xorg display (under KDE) frozen. Keyboard and mouse were responding, but nothing was changing on the display (but mouse pointer, which moved). What was interesting, was a message in the console: (EE) intel(0): Failed to submit batch buffer, expect rendering corruption or even a frozen display: Input/output error. intel_bufmgr_gem.c:1060: Error setting domain 11869: Input/output error In the same time, in syslog I got this: Apr 20 08:37:10 laptok kernel: : [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Apr 20 08:37:10 laptok kernel: : render error detected, EIR: 0x Apr 20 08:37:10 laptok kernel: : [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 2935568 at 2935567) What may be the reason my laptop behaved like this? Usually my machine is rock steady. I'm using intel driver 2.11.0, kernel 2.6.33.2 and xserver 1.7.6 (with 1.8.0 xrandr is not working). My graphics chip is Intel i945GM. The kernel detected a GPU hang, usually triggered by the userspace driver ordering the GPU to perform an undefined operation. With a more recent kernel, 2.6.34-rc1 or later, /sys/kernel/debug/dri/0/i915_error_state will contain the erroneous batch buffer and hopefully sufficient information to identify the cause. With your current kernel, there is a slim chance that intel_gpu_dump will be able to grab the illegal batch buffer, but usually it just contains noise post-hangcheck. Please update your kernel and if it reoccurs, file a bug, including i915_error_state. -ickle -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel and Xorg freeze - what may be the problem?
On Tue, 20 Apr 2010 12:55:44 +0200, Gábor Lénárt l...@lgb.hu wrote: On Tue, Apr 20, 2010 at 12:07:14PM +0200, Åukasz MaÅko wrote: Dnia wtorek, 20 kwietnia 2010, Gábor Lénárt napisaÅ: Hei, Maybe this report is similar to this one (ubuntu bugreport): https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/5 54835 But I am not sure it's really the same, though ... No, I can use XVideo without any problems (I do it to watch films on my laptop). Yes, but at least the kernel messages seems to be quite similar. Also I have this problem unrelated to XVideo (though it can trigger me the bug all the time) sometimes ... So there can be some common thing behind these problems at least, hmmm. The kernel Xorg messages are just alerting you to a problem in a very generic manner. Every Intel GPU hang generates these identical messages, and there appear to be an infinite number of ways we can hang the GPU. (Ignoring all the other methods we can use to cause the GPU/system to hang/stall.) In order to distinguish the different causes we need the means to reproduce and the i915_error_state recorded at the time of the error, as well as identification of hardware and any other hints gathered from the system. http://intellinuxgraphics.org/how_to_report_bug.html http://intellinuxgraphics.org/i915_error_state.html Hope this helps. -ickle -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: commit d6b7f96fde1add92fd11f5a75869ae6fc688bf77 causes Xserver segmentation fault
On Thu, 25 Mar 2010 15:47:54 +0800, Jeff Chua jeff.chua.li...@gmail.com wrote: Chris, I git pulled the latest code today, and it's still causing segmentation fault running VMware on this commit. Reverting it solves the problem. Is there anything that can be done to resolve this in a proper way than reverting the code? Can you identify which byte is causing the SEGV? Is it the first or near the end of the image? Admittedly it's immaterial, I just want to know why. If you can endure running X under valgrind, that will be very useful. -ickle -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problem regarding configuring X server
Excerpts from Flittigs at PICT's message of Tue Sep 15 11:47:57 +0100 2009: So we configured xproto with following command : *sudo ./autogen.sh --prefix=/opt/gfx-test/ There is your problem. Always think long and hard before you invoke root privileges. In this case sudo is sanitising your environment and removing PKG_CONFIG_PATH and ACLOCAL. Configure and build the xserver (and its dependencies) using your normal account, and iff you need more privileges invoke sudo to perform the 'make install'. Though I would just change the prefix to install into a writeable location. -ickle -- chris.wil...@intel.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Cairo with glitz backend
On Thu, 2009-03-05 at 08:21 +0100, Marco wrote: On Wed, Mar 4, 2009 at 10:02 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: So currently aside from glitz, there are experiments to show that simply doing basic compositing using OpenGL can be much faster than XRender: http://cgit.freedesktop.org/~anholt/cairo/log/?h=gl and http://cgit.freedesktop.org/~ickle/cairo/log/?h=opengl A slightly more ambitious (though it does have quite a few fundamental flaws of its own, chiefly among those is that he hasn't asked anyone from the cairo community to review it...) http://github.com/akyrtzi/cairo-gral/tree/master And my favourite (slightly biased since I'm the author ;-) is an example of what you can achieve with direct rendering: http://cgit.freedesktop.org/~ickle/cairo/log/?h=drm which, I claim, is just about as fast as you can make cairo on an eee/i915. (I welcome any patches to make it, and cairo, even faster :-) The discussion was intriguing, so i tried your latest cairo with drm backend (http://cgit.freedesktop.org/~ickle/cairo/log/?h=drm) because I have an i915 chipset (GM45). The gm45 is an i965 chipset, which is a different generation from i915 and although much more powerful, that same flexibility needs a different backend. This is one of the reasons why cairo-drm is a dead-end, and moving the EXA drivers to pixman-drm makes more sense. But writing a specific cairo backend is much easier, and hence why I started there. Recompiled all the stuff with --enable-drm --enable-xlib-xrender --enable-dri2 --enable-gl with my brand new intel video drivers(2.6.3) with UXA on top of libdrm 2.4.5 I was going to add that's insufficient for drm on i915 class hardware since tiling is fubar and you need a few extra patches to fix that up. (Adding another user (i.e. neither X nor libGL) really helped with the robustness of the drivers. ;-) I have to say that I thougth there would be a boost for all gnome applications, but I hardly see any difference from cairo (1.8.6) standard (debian packaging). I remember passing from standard backends to glitz showed a great performance boost. The sad truth here is that cairo is not used in the most performant manner by gnome - their usage of GdkPixbuf sucks, for example. How i could be sure cairo is using drm backend (apart the fact that libcairo is linked with libdrm)? A cairo backend has to be explicitly created by the application, as such apart from the dri2 test application there are no X-based cairo-drm applications, that I know of. Instead my motivation for cairo-drm was to accelerate cairo on wayland (which I thoroughly recommend everyone to play with ;-) Are there any tests I could check to see how fast is cairo with drm backend? The cairo performance suite in cairo/perf/ is a good starting point. It contains mostly synthetic benchmarks, but it should provide a guide as to how the individual operations compare. Alternatively you can record a cairo-trace of your favourite application and replay that using any backend and thus compare. If you do record an interesting trace, please submit it to the cairo list as I'm trying to gather a set of real-world benchmarks. Anyway I think these new works about cairo backends coul be very primising. In part, I feel this a digression. The only real reason for a cairo backend is interoperability with an acceleration architecture (xlib, win32, quartz, [GL, DirectX]). drm/GEM is interesting as it promises to provide a h/w accelerated image surface that should be interoperable with both xlib and GL (and also usable in headless scenarios). However, the real work lies in developing our existing architecture (i.e. pixman and XRender) to benefit from recent improvements within cairo (e.g. the shift away from tessellation to polygon rasterisation, blend modes etc) and to complete the driver implementations to accelerate patterns. -ickle ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Cairo with glitz backend
On Tue, 2009-03-03 at 17:24 -0800, Bipin George Mathew wrote: I was looking into way of accelerating Cairo using a glitz-backend and had a bunch of related questions: - What is the current status of glitz? Is anyone working on it? People contribute patches occasionally, just recently we received quite a few to address some bit rot and improve conformance. - From the paper here http://www.usenix.org/events/usenix04/tech/freenix/full_papers/nilsson/nilsson_html/index.html, it looks like glitz was experimental. What are the areas that needs to be worked on in-order to make it mainstream? For glitz to be considered supported we essentially need two things: 1. It should pass the test suite. 2. A responsive and long-term maintainer (for both the cairo backend the glitz library). - What are the other options of accelerating Cairo? Glitz was an experiment to implement the XRender protocol on top of OpenGL. This may not be the best approach to take. Instead the emphasis has shifted onto using the new (introduced into cairo after glitz was conceived) high level backend api to offload as much of the drawing operation as possible to the h/w. (Or at least entertain that possibility and investigate different solutions.) So currently aside from glitz, there are experiments to show that simply doing basic compositing using OpenGL can be much faster than XRender: http://cgit.freedesktop.org/~anholt/cairo/log/?h=gl and http://cgit.freedesktop.org/~ickle/cairo/log/?h=opengl A slightly more ambitious (though it does have quite a few fundamental flaws of its own, chiefly among those is that he hasn't asked anyone from the cairo community to review it...) http://github.com/akyrtzi/cairo-gral/tree/master And my favourite (slightly biased since I'm the author ;-) is an example of what you can achieve with direct rendering: http://cgit.freedesktop.org/~ickle/cairo/log/?h=drm which, I claim, is just about as fast as you can make cairo on an eee/i915. (I welcome any patches to make it, and cairo, even faster :-) -ickle ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Intel-gfx] xf86-video-intel memory leakage
On Thu, 2009-02-12 at 10:26 +0100, Stefano Avallone wrote: On Monday 09 February 2009 20:28:14 Johannes Engel wrote: Jesse Barnes wrote: Interesting, thanks for trying to narrow it down. I don't see anything on re-review that would cause huge increases in the amount of memory used, though the additional alignment we apply in that patch will increase things somewhat, so might make the problem happen faster. Are you using UXA or EXA? You are probably right here, Jesse: Letting Xorg run with UXA on my GM945 turns out to show a similar problem after a couple of hours or similar. sudo lsof | grep drm mm object | wc -l shows the incredible number of 2407... Since cairo-perf will cause a leak of a couple of GiB in a few seconds on my i915, I was able to track down the cause pretty quickly. It turns out not to be limited to uxa at all, just uxa exercises the bufmgr much more than exa. The issue appears to be the bufmgr cache handling which appears unbounded. Its use was introduced with: commit a893f176dda0b64f7dadfda6bf0331240037851e Author: Carl Worth cwo...@cworth.org Date: Fri Jul 25 15:56:35 2008 -0700 Add call to intel_bufmgr_gem_enable_reuse So you can try reverting that commit and confirming if that clears the issue for you. Longer term, I think the buffer cache should be moved into the kernel, as when using client-side rendering we may end up with a bo cache per application. Moving it to the kernel should allow the cache to be shared and for it to reaped in low memory conditions. AIUI, we need to cache bo in order to reduce the cost associated with creating a new shmem object, mapping the page lists and to minimise clflush. The easiest approach would seem to be to add a dev_priv-cache_list and a new create ioctl that took interested domains and returned the current ones for the new object. (One of the improvements I found in cache usage was in relaxing the busy condition for buffers which I knew would only be used for GPU writes and so would be serialised by the batch scheduling.) Suggestions? Ideas? Patches? -ickle ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
