From: "Konstantin A. Lepikhov" <lakostis@anti-leasure.ru> To: ALT Linux Hardware Mailing List <hardware@altlinux.ru> Subject: [Hardware] насчет swsusp + i855GM [Suspending with i915 and DRI (possible solution?)] Date: Wed, 12 Jan 2005 17:36:50 +0300 Message-ID: <20050112143650.GA17894@lks.home> (raw) Hi! JFYI как возможный workaround (хотя надо смотреть патчи для xorg). ----- Forwarded message from Bernard Blackham <bernard@blackham.com.au> ----- Date: Fri, 7 Jan 2005 22:12:25 +0800 From: Bernard Blackham <bernard@> To: dri-devel@ Subject: Suspending with i915 and DRI (possible solution?) Organization: Dagobah Systems User-Agent: Mutt/1.5.6+20040907i Greetings, I have an Intel i855GM chipset in my laptop, running Xorg 6.8.1 with i810 and i915_dri for DRI, and kernel 2.6.10 with the i915 kernel module. DRI is all well and happy, and glxgears achieves about 800fps. I use Software Suspend 2 (2.1.5.11) from softwaresuspend.berlios.de, and upon suspending and resuming, I found that GL apps would freeze when trying to be launched (as has been reported before). So I did some digging and poking, and wrote the attached little C program that calls I915_RESUME_DMA in the i915 drm driver, and surprisingly, this lets me run GL applications once more without restarting X. If I simply run it after resuming and returning back to X, I can run GL applications again. Even more interestingly though, is if I run it after resuming but before returning back to X, existing GL applications don't lock up and continue to run, with some small mishaps: - on the first suspend invocation (from a freshly started X), Xorg will consume 99% CPU (though still be otherwise functional) until I kill glxgears *and* switch VTs to text and back to X. On subsequent suspend invocations, this doesn't happen. If I'm not running glxgears or a GL app when suspending, it doesn't happen either. - glxgears' reported fps will drop from the usual 800fps on a freshly started X, to about 200fps on a suspend/resumed one, but CPU usage is pretty close to zero indicating that it's certainly not software-GL. I can still play tuxracer after resume with no noticable differences. - running tuxracer whilst suspending and resuming results in a garbled screen (fair enough though :). You can make out enough of the screen to exit tuxracer and restart it again... I guess I'll have to stop tuxracer whilst suspending for now ;) So this is really just a quick hack but is it worth considering moving into something like the X dri driver? (eg, on vt switch?) And is it just working for me out of pure luck? :) I can imagine that to restore full DRI would take much more work (textures and the like). TIA, Bernard. -- Bernard Blackham <bernard at blackham dot com dot au> #include <sys/ioctl.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #define DRM_IOCTL_I915_INIT 0x40 typedef struct _drm_i915_init { enum { I915_INIT_DMA = 0x01, I915_CLEANUP_DMA = 0x02, I915_RESUME_DMA = 0x03 } func; unsigned int mmio_offset; int sarea_priv_offset; unsigned int ring_start; unsigned int ring_end; unsigned int ring_size; unsigned int front_offset; unsigned int back_offset; unsigned int depth_offset; unsigned int w; unsigned int h; unsigned int pitch; unsigned int pitch_bits; unsigned int back_pitch; unsigned int depth_pitch; unsigned int cpp; unsigned int chipset; } drm_i915_init_t; int main() { drm_i915_init_t init; init.func = I915_RESUME_DMA; int fd = open("/dev/dri/card0", O_RDWR); if (fd == -1) { perror("open"); return 1; } if (ioctl(fd, DRM_IOCTL_I915_INIT, &init) == -1) { perror("ioctl"); return 1; } return 0; } ----- End forwarded message ----- -- WBR, Konstantin chat with ==>ICQ: 109916175 Lepikhov, speak to ==>JID: lakostis@jabber.org aka L.A. Kostis write to ==>mailto:lakostis@pisem.net.nospam ...The information is like the bank... (c) EC8OR
next reply other threads:[~2005-01-12 14:36 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2005-01-12 14:36 Konstantin A. Lepikhov [this message] 2005-01-12 14:42 ` Maxim Tyurin 2005-01-18 7:23 ` Maxim Tyurin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20050112143650.GA17894@lks.home \ --to=lakostis@anti-leasure.ru \ --cc=hardware@altlinux.ru \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux hardware support This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/hardware/0 hardware/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 hardware hardware/ http://lore.altlinux.org/hardware \ hardware@altlinux.ru hardware@lists.altlinux.org hardware@lists.altlinux.ru hardware@lists.altlinux.com hardware@altlinux.org public-inbox-index hardware Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.hardware AGPL code for this site: git clone https://public-inbox.org/public-inbox.git