On Wed, 4 Aug 2010 21:11:13 +0200, Daniel Vetter wrote:
> On Wed, Aug 04, 2010 at 08:57:26PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 04, 2010 at 03:36:30PM +0100, Chris Wilson wrote:
> > > Incorporates a similar patch by Daniel Vetter, the alteration being to
> > > report the current busy stat
On Wed, Aug 04, 2010 at 08:57:26PM +0200, Daniel Vetter wrote:
> On Wed, Aug 04, 2010 at 03:36:30PM +0100, Chris Wilson wrote:
> > Incorporates a similar patch by Daniel Vetter, the alteration being to
> > report the current busy state after retiring.
> Woot, nice idea to exactly preserve the seman
On Wed, Aug 04, 2010 at 03:36:30PM +0100, Chris Wilson wrote:
> Incorporates a similar patch by Daniel Vetter, the alteration being to
> report the current busy state after retiring.
Woot, nice idea to exactly preserve the semantics of the old
implementation.
/me bangs the head against the wall fo
Incorporates a similar patch by Daniel Vetter, the alteration being to
report the current busy state after retiring.
Signed-off-by: Chris Wilson
Cc : Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 40 +-
1 files changed, 26 insertions(+), 14 deletions(
On Sun, May 02, 2010 at 11:13:18AM -0700, Eric Anholt wrote:
> I've thought about writing this patch several times. Here's my concern.
> Say I drew to an FBO (render cache dirty) temporarily then freed it. It
> goes into the bo reuse list in userland, and is on the flushing list in
> kernel. Now
On Fri, 23 Apr 2010 14:32:39 +0200, Daniel Vetter
wrote:
> Reporting objects that are not currently used by the gpu but are
> dirty and not yet flushed creates havoc to libdrm's bo reuse:
> The usually immediatly following gtt_map afterwards will stall
> until the gpu has executed the writeback.
Reporting objects that are not currently used by the gpu but are
dirty and not yet flushed creates havoc to libdrm's bo reuse:
The usually immediatly following gtt_map afterwards will stall
until the gpu has executed the writeback.
v2: Fix refcount leak and missing unlock in the error path. Spotte
