Re: TTM merging?

2008-05-15 Thread Keith Packard
On Thu, 2008-05-15 at 07:30 +0200, Thomas Hellström wrote: Static wc-d maps into fairly static objects like scanout buffers or buffer pools are not inefficient. They provide the by far highest throughput for writing (even beats cache-coherent). But they may take some time to set up or tear

Re: TTM merging?

2008-05-15 Thread Thomas Hellström
Keith Packard wrote: On Thu, 2008-05-15 at 07:30 +0200, Thomas Hellström wrote: Static wc-d maps into fairly static objects like scanout buffers or buffer pools are not inefficient. They provide the by far highest throughput for writing (even beats cache-coherent). But they may take

Re: TTM merging?

2008-05-15 Thread Ian Romanick
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Keith Packard wrote: | On Wed, 2008-05-14 at 21:41 +0200, Thomas Hellström wrote: | | As you've previously mentioned, this requires caching policy changes and | it needs to be used with some care. | | I did't need that in my drivers as GEM handles the

Re: TTM merging?

2008-05-15 Thread Keith Packard
On Thu, 2008-05-15 at 10:03 -0700, Ian Romanick wrote: Er...what about glMapBuffer? Are we now going to force drivers to implement that via copies? No, we'll support it, and make it as fast as possible. The goal is to not use it inside the driver, not to break GL apps. -- [EMAIL PROTECTED]

Re: TTM merging?

2008-05-15 Thread Philipp Klaus Krause
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Anholt schrieb: No. Gem can't coop with it. Let's say you have a 512M system with two 1G video cards, 4G swap space, and you want to fill both card's videoram with render-and-forget textures for whatever purpose. Who's selling that

[Bug 15728] [945GM][kernel 2.6.25] Fail to run GL program after resume

2008-05-15 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=15728 --- Comment #7 from Jie Luo [EMAIL PROTECTED] 2008-05-14 20:31:47 PST --- Created an attachment (id=16546) -- (http://bugs.freedesktop.org/attachment.cgi?id=16546) reg dump after resume -- Configure bugmail:

[Bug 15728] [945GM][kernel 2.6.25] Fail to run GL program after resume

2008-05-15 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=15728 --- Comment #8 from Jie Luo [EMAIL PROTECTED] 2008-05-14 20:33:06 PST --- Created an attachment (id=16547) -- (http://bugs.freedesktop.org/attachment.cgi?id=16547) reg dump after resume and reload i915 kernel module -- Configure bugmail:

[Bug 15728] [945GM][kernel 2.6.25] Fail to run GL program after resume

2008-05-15 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=15728 --- Comment #9 from Jie Luo [EMAIL PROTECTED] 2008-05-14 20:39:15 PST --- From the regdump, it seems some register not restore properly during resume. This maybe the problem. -- Configure bugmail:

[Bug 15945] New: [AvP1 Alien Demo (wine)] flickering artifacts

2008-05-15 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=15945 Summary: [AvP1 Alien Demo (wine)] flickering artifacts Product: Mesa Version: unspecified Platform: x86 (IA32) URL: http://bugs.winehq.org/show_bug.cgi?id=12944 OS/Version: Linux

[RFC] handling panic under X

2008-05-15 Thread Jesse Barnes
The attached patches, which depend on kernel mode setting, will allow us to see some kernel messages even if a panic occurs while X is running. I think the approach is fairly sound (using a notifier to let mode setting drivers switch the front buffer), but there are some details to be worked

leaks in git mesa master

2008-05-15 Thread Shunichi Fuji
Hi, I encountered huge-grown memory leak in recently update and investigated by valgrind. The leak found in _tnl_UpdateFixedFunctionProgram that was 'state_key key' keep created always. ==5636== 1,319,960 bytes in 32,999 blocks are definitely lost in loss record 63 of 65 ==5636==at

[Bug 10709] 2.6.26-rc2 hosed X?

2008-05-15 Thread bugme-daemon
http://bugzilla.kernel.org/show_bug.cgi?id=10709 --- Comment #1 from [EMAIL PROTECTED] 2008-05-15 22:57 --- In my email from above I mentioned that X behaves strangly and suspend/resume does not work. The latter seems to be solved with the patch from