Re: [Intel-gfx] Semaphore cleanups

2011-09-16 Thread Daniel Vetter
On Thu, Sep 15, 2011 at 07:08:56PM -0700, Ben Widawsky wrote: > FWIW, I thought my original patch was the easiest to read, but this certainly > removes the most magic. These had a ton of input from Daniel Vetter, and Chris > Wilson. The goal is only to make the code more readable, and easier to >

Re: [Intel-gfx] [PATCH 5/5] drm/i915: tracepoints for semaphores

2011-09-16 Thread Daniel Vetter
On Thu, Sep 15, 2011 at 07:09:01PM -0700, Ben Widawsky wrote: > The tracepoints give enough info to figure the updates and compares > (document terminology for signals and waits) and dependencies therein of > the semaphore mailboxes. > > Here are arguments to perf to get interesting info (mostly c

Re: [Intel-gfx] [PATCH 5/5] drm/i915: tracepoints for semaphores

2011-09-16 Thread Chris Wilson
On Fri, 16 Sep 2011 09:58:53 +0200, Daniel Vetter wrote: > We already have trace_i915_gem_request_add in i915_add_request which is > essentially giving out the same information (well, minus the hopefully > correct singal_mbox reg addresses). I think we can drop this one. I thought that as well, b

Re: [Intel-gfx] [PATCH 5/5] drm/i915: tracepoints for semaphores

2011-09-16 Thread Daniel Vetter
On Fri, Sep 16, 2011 at 09:37:41AM +0100, Chris Wilson wrote: > On Fri, 16 Sep 2011 09:58:53 +0200, Daniel Vetter wrote: > > We already have trace_i915_gem_request_add in i915_add_request which is > > essentially giving out the same information (well, minus the hopefully > > correct singal_mbox re

Re: [Intel-gfx] [PATCH 5/5] drm/i915: tracepoints for semaphores

2011-09-16 Thread Chris Wilson
On Fri, 16 Sep 2011 11:07:29 +0200, Daniel Vetter wrote: > On Fri, Sep 16, 2011 at 09:37:41AM +0100, Chris Wilson wrote: > > On Fri, 16 Sep 2011 09:58:53 +0200, Daniel Vetter wrote: > > > We already have trace_i915_gem_request_add in i915_add_request which is > > > essentially giving out the same

[Intel-gfx] [PATCH 1/2] Fix "always false" conditionals

2011-09-16 Thread przanoni
From: Paulo Zanoni Enums are unsigned by default in gcc and we can't rely on any specific signedess for the other compilers. i965_render.c: In function ‘i965_prepare_composite’: i965_render.c:2018:2: warning: comparison of unsigned expression < 0 is always false i965_render.c:2025:2: warning: c

[Intel-gfx] [PATCH 2/2] Remove useless assertion

2011-09-16 Thread przanoni
From: Paulo Zanoni Removes 17 instances of: warning: comparison of unsigned expression >= 0 is always true Signed-off-by: Paulo Zanoni --- src/xvmc/intel_batchbuffer.h |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/src/xvmc/intel_batchbuffer.h b/src/xvmc/intel_batchbu

Re: [Intel-gfx] [PATCH 1/2] Fix "always false" conditionals

2011-09-16 Thread Chris Wilson
On Fri, 16 Sep 2011 18:53:01 -0300, przan...@gmail.com wrote: > From: Paulo Zanoni > > Enums are unsigned by default in gcc and we can't rely on any specific > signedess for the other compilers. > > i965_render.c: In function ‘i965_prepare_composite’: > i965_render.c:2018:2: warning: compari