Re: drm: Branch 'master' - 2 commits

2011-12-06 Thread Chris Wilson
On Mon, 05 Dec 2011 14:23:55 -0800, Eric Anholt wrote: > On Mon, 5 Dec 2011 02:31:58 -0800 (PST), ic...@kemper.freedesktop.org (Chris > Wilson) wrote: > > configure.ac |2 +- > > intel/intel_bufmgr_gem.c | 27 +-- > > 2 files changed, 22 insertions(+),

Re: drm: Branch 'master' - 2 commits

2011-12-05 Thread Eric Anholt
On Mon, 5 Dec 2011 02:31:58 -0800 (PST), ic...@kemper.freedesktop.org (Chris Wilson) wrote: > configure.ac |2 +- > intel/intel_bufmgr_gem.c | 27 +-- > 2 files changed, 22 insertions(+), 7 deletions(-) > > New commits: > commit e73161a02b604742e3da3bca

Re: drm: Branch 'master' - 2 commits

2008-03-06 Thread Thomas Hellström
Dave Airlie wrote: >>> >>> >> Yes, I think so. One reason to lock is to make sure the GTT page table >> is really repopulated after a resume, but that can be handled in the DRM >> driver resume function, and we could perhaps >> change the user-space lock_mm() to ignore kernel_bos. >>

Re: drm: Branch 'master' - 2 commits

2008-03-06 Thread Dave Airlie
> > > Yes, I think so. One reason to lock is to make sure the GTT page table > is really repopulated after a resume, but that can be handled in the DRM > driver resume function, and we could perhaps > change the user-space lock_mm() to ignore kernel_bos. It defintely should all be handled in

Re: drm: Branch 'master' - 2 commits

2008-03-06 Thread Thomas Hellström
Dave Airlie wrote: >> 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... >>

Re: drm: Branch 'master' - 2 commits

2008-03-05 Thread Dave Airlie
> 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

Re: drm: Branch 'master' - 2 commits

2008-03-05 Thread Thomas Hellström
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

Re: drm: Branch 'master' - 2 commits

2008-03-05 Thread Dave Airlie
> > > > 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.

Re: drm: Branch 'master' - 2 commits

2008-03-05 Thread Thomas Hellström
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 |