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
http://lkml.org/lkml/2008/5/13/188
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 0x4005B0
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 out
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 (Al
http://bugzilla.kernel.org/show_bug.cgi?id=10709
Summary: 2.6.26-rc2 hosed X?
Product: Drivers
Version: 2.5
KernelVersion: 2.6.26-rc2
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: nor
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: http://bugs.freedesktop.org/userprefs.cg
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
http://bugs.freedesktop.org/show_bug.cgi?id=15728
--- Comment #6 from Jie Luo <[EMAIL PROTECTED]> 2008-05-14 20:31:00 PST ---
Created an attachment (id=16545)
--> (http://bugs.freedesktop.org/attachment.cgi?id=16545)
reg dump before suspend
--
Configure bugmail: http://bugs.freedesktop.or
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: http://bugs.freedesktop.org/
-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 tha
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]
-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 th
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
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 t
14 matches
Mail list logo
