On 2008.03.06 02:49:10 +, Alec Robertson wrote:
> The latest git drm doesn't compile on 2.6.25-rc3 as flush_agp_mappings has
> been
> removed: http://lwn.net/Articles/267135/
>
> The error message:
> /usr/local/src/drm/linux-core/drm_ttm.c:134: error: implicit declaration of
> function 'flush
> So, over to the somewhat different problem I was referring to, namely
> potential buffer eviction on vt switch where the X server run
> drm_bo_lock_mm(), and will evict any fb scanout BOs. Only the fb layer
> doesn't really notice as long as the BOs sit in VRAM...
Yes I get around this curre
The latest git drm doesn't compile on 2.6.25-rc3 as flush_agp_mappings has been
removed: http://lwn.net/Articles/267135/
The error message:
/usr/local/src/drm/linux-core/drm_ttm.c:134: error: implicit declaration of
function 'flush_agp_mappings'
make[3]: *** [/usr/local/src/drm/linux-core/drm_ttm.
I'm running the latest git xf86-video-ati on a debian unstable thinkpad t41p
with a firegl mobility t2 ati card. Until about a week ago, the git driver was
working fine. Since that time, switching from X to a virtual terminal and back
hangs the system. As this is what suspend and hibernate do, it a
http://bugs.freedesktop.org/show_bug.cgi?id=14656
Shuang He <[EMAIL PROTECTED]> changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #
http://bugs.freedesktop.org/show_bug.cgi?id=13585
Zou Nan hai <[EMAIL PROTECTED]> changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolu
Dave Airlie wrote:
>>>
>>> this adds something to say the kernel initialised the memory region not
>>> the userspace. and blocks userspace from deallocating kernel areas
>>>
>>>
>> Dave,
>> I guess this commit is a fix for the fact that the X server will try to
>> evict fb s
http://bugs.freedesktop.org/show_bug.cgi?id=14840
--- Comment #1 from Alex Deucher <[EMAIL PROTECTED]> 2008-03-05 16:00:11 PST
---
Any chance you could use git bisect to track down the problematic commit?
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- Yo
> >
> > this adds something to say the kernel initialised the memory region not
> > the userspace. and blocks userspace from deallocating kernel areas
> >
> Dave,
> I guess this commit is a fix for the fact that the X server will try to
> evict fb scanout buffers when leaving VT.
http://bugs.freedesktop.org/show_bug.cgi?id=14840
Summary: radeon 60 wakeups after resume
Product: DRI
Version: XOrg CVS
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Keywords: regression
Severity: minor
Eric Anholt wrote:
>> I see two problems with this: One is cosmetic in that
>> DRM_BO_FLAG_CACHED_MAPPED doesn't have the same semantics as
>> !DRM_BO_FLAG_CACHED. You can't use it for user-space buffer pools.
>> The other one is that TG will be needing the functionality of
>> !DRM_BO_FLAG_CACHE
Dave Airlie wrote:
> libdrm/xf86drm.c | 15 ++
> libdrm/xf86mm.h |1
> linux-core/drm_bo.c | 67
> +++---
> linux-core/drm_drv.c |2 +
> linux-core/drm_objects.h |8 -
> shared-core/drm.h |
On Wed, 2008-03-05 at 01:25 +0100, Thomas Hellström wrote:
> Eric Anholt wrote:
> >
> >> c) User-space bo-caching and reuse.
> >> d) User-space buffer pools.
> >>
> >> TG is heading down the d) path since it also fixes the texture
> >> granularity problem.
> >>
> >
> > There's no texture gra
http://bugs.freedesktop.org/show_bug.cgi?id=14656
haihao <[EMAIL PROTECTED]> changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Thomas Hellström wrote:
> Eric Anholt wrote:
>
>>
>> Going from CACHED_MAPPED back to uncached even with buffer reuse is a
>> 22% performance drop (but at least it's not the 79% hit to the face you
>> get without buffer reuse).
>>
>>
> Hmm, this sounds odd. That simply means you must still be do
15 matches
Mail list logo
