[Intel-gfx] [PATCH] libdrm execute on different ring buffer

introduce an new API for command to execute on different ring buffer. This is need for VAAPI to decode H.264 on BSD ring buffer Signed-off-by: Xiang Hai hao Signed-off-by: Zou Nan hai --- include/drm/i915_drm.h|4 +++- intel/intel_bufmgr.c | 13 + intel/intel_bufmgr.h

[Intel-gfx] [PATCH] drm/i915: use wake_up instead of drm wrapper.

From: Dave Airlie Since b9241ea31fae4887104e5d1b3b18f4009c25a0c4 drm/i915: Don't wait interruptible for possible plane buffer flush and previous to that 48764bf43f746113fc77877d7e80f2df23ca4cbb drm/i915: add i915_lp_ring_sync helper The irq wait queue has uninterruptible waiters, however the DR

Re: [Intel-gfx] [intel-gfx][PATCH] intel: add a new interface drm_intel_bo_alloc_direct

>>-Original Message- >>From: intel-gfx-bounces+nanhai.zou=intel@lists.freedesktop.org >>[mailto:intel-gfx-bounces+nanhai.zou=intel@lists.freedesktop.org] On >>Behalf Of Eric Anholt >>Sent: 2010年5月28日 2:59 >>To: Xiang, Haihao >>Cc: intel-gfx@lists.freedesktop.org >>Subject: Re: [Inte

[Intel-gfx] [PATCH] drm/i915/gen4: Fix interrupt setup ordering

Unmask, then enable interrupts, then enable interrupt sources; matches PCH ordering. The old way (sources, enable, unmask) gives a window during which interrupt conditions would appear in ISR but would never reach IIR and thus never raise an IRQ. Since interrupts only trigger on rising edges in I

Re: [Intel-gfx] [intel-gfx][PATCH] intel: add a new interface drm_intel_bo_alloc_direct

On Thu, 27 May 2010 11:22:02 +0800, "Xiang, Haihao" wrote: > On Thu, 2010-05-27 at 04:52 +0800, Eric Anholt wrote: > > On Tue, 25 May 2010 13:06:50 +0800, "Xiang, Haihao" > > wrote: > > > This interface is the same as drm_intel_bo_alloc except the allocated > > > size isn't rounded up, so it b

Re: [Intel-gfx] [PATCH 04/11] drm/i915: Propagate error from unbinding an unfenceable object.

On Thu, 27 May 2010 09:05:04 -0700, Jesse Barnes wrote: > Looks ok to me. Out of curiosity, are you seeing errors here on unbind > with some loads? Since you ask, yes... But it is usually -5. ;-) -ickle -- Chris Wilson, Intel Open Source Technology Centre _

Re: [Intel-gfx] [PATCH 04/11] drm/i915: Propagate error from unbinding an unfenceable object.

On Thu, 27 May 2010 13:18:15 +0100 Chris Wilson wrote: > Signed-off-by: Chris Wilson > Cc: Jesse Barnes > --- > drivers/gpu/drm/i915/i915_gem.c | 10 +++--- > 1 files changed, 7 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_ge

Re: [Intel-gfx] [PATCH 02/11] drm/i915: Hold the spinlock whilst resetting unpin_work along error path

On Thu, 27 May 2010 13:18:13 +0100 Chris Wilson wrote: > Delay taking the mutex until we need to and ensure that we hold the > spinlock when resetting unpin_work on the error path. Also defer the > debugging print messages until after we have released the spinlock. > > Signed-off-by: Chris Wilso

[Intel-gfx] [PATCH] drm/i915: Avoid moving from CPU domain during pwrite

We can avoid an early clflush when pwriting if we use the current CPU write domain rather than moving the object to the GTT domain for the purposes of the pwrite. This has the advantage of not flushing the presumably hot data that we want to upload into the bo, and of ascribing the clflush to the e

[Intel-gfx] [PATCH 2/2] drm/i915: Fix up address spaces in slow_kernel_write()

Since we now get_user_pages() outside of the mutex prior to performing the copy, we kmap() the page inside the copy routine and so need to perform an ordinary memcpy() and not copy_from_user(). Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 42 +++

[Intel-gfx] [PATCH 1/2] drm/i915: Use non-atomic kmap for slow copy paths

As we do not have a requirement to be atomic and avoid sleeping whilst performing the slow copy for shmem based pread and pwrite, we can use kmap instead, thus simplifying the code. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 82 ++ 1 f

[Intel-gfx] [PATCH 11/11] drm/i915: Cleanup after failed initialization of ringbuffers

The callers expect us to cleanup any partially initialised structures before reporting the error. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 19 ++- 1 files changed, 18 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/

[Intel-gfx] [PATCH 10/11] drm/i915: Reject bind_to_gtt() early if object > aperture

If the object is bigger than the entire aperture, reject it early before evicting everything in a vain attempt to find space. v2: Use E2BIG as suggested by Owain G. Ainsworth. Signed-off-by: Chris Wilson Cc: sta...@kernel.org --- drivers/gpu/drm/i915/i915_gem.c |8 1 files changed,

[Intel-gfx] [PATCH 09/11] drm/i915: Check error code whilst moving buffer to GTT domain.

Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_fb.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c index 6f53cf7..f8c76e6 100644 --- a/drivers/gpu/drm/i915/intel_fb.c +++ b/drivers/gpu/drm

[Intel-gfx] [PATCH 08/11] drm/i915: Remove spurious warning "Failure to install fence"

This particular warning is harmless as we emit during the normal pinning process where the batch buffer requires more fences than is available without eviction. Only if we fail to evict enough fences does this become a problem, so include the requested number of fences in the ultimate *error* messa

[Intel-gfx] [PATCH 07/11] drm/i915: Rebind bo if currently bound with incorrect alignment.

Whilst pinning the buffer, check that that its current alignment matches the requested alignment. If it does not, rebind. This should clear up any final render errors whilst resuming, for reference: Bug 27070 - [i915] Page table errors with empty ringbuffer https://bugs.freedesktop.org/show_b

[Intel-gfx] [PATCH 06/11] drm/i915: Include pitch in set_base debug statement.

Add the pitch that we about to write into the control register along with the base, offset and coordinates that go into the other control registers. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_display.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/dri

[Intel-gfx] [PATCH 05/11] drm/i915: Only print "nothing to do" debug message as required.

If the FBC is already disabled, then we do not even attempt to disable FBC and so there is no point emitting a debug statement at that point, having already emitted one saying why we are disabling FBC. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_display.c |5 +++-- 1 files cha

[Intel-gfx] [PATCH 04/11] drm/i915: Propagate error from unbinding an unfenceable object.

Signed-off-by: Chris Wilson Cc: Jesse Barnes --- drivers/gpu/drm/i915/i915_gem.c | 10 +++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 1c65f0b..6425c2a 100644 --- a/drivers/gpu/drm/i915/i915_gem.c

[Intel-gfx] [PATCH 03/11] drm/i915: Avoid nesting of domain changes when setting display plane

Nesting domain changes will cause confusion when trying to interpret the tracepoints describing the sequence of changes for the object, as well as obscuring the order of operations for the reader of the code. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c |8 +++- 1 file

[Intel-gfx] [PATCH 02/11] drm/i915: Hold the spinlock whilst resetting unpin_work along error path

Delay taking the mutex until we need to and ensure that we hold the spinlock when resetting unpin_work on the error path. Also defer the debugging print messages until after we have released the spinlock. Signed-off-by: Chris Wilson Cc: Jesse Barnes Cc: Kristian Høgsberg --- drivers/gpu/drm/i9

[Intel-gfx] [PATCH 01/11] drm/i915: Only print an message if there was an error

Only report an error if the GPU has actually detected one, otherwise we are just hung. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_irq.c | 38 -- 1 files changed, 24 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b

[Intel-gfx] A compendium of trivial patches.

Hi Eric, just a few outstanding trivial patches for you to read on your commute. :) -ickle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx