Re: [Intel-gfx] [PATCH] drm/i915: fixup sparse warnings

On Mon, Dec 03, 2012 at 09:13:52PM +, Chris Wilson wrote: > On Thu, 29 Nov 2012 22:18:51 +0100, Daniel Vetter > wrote: > > - __iomem where there is none (I love how we mix these things up). > > - Use gfp_t instead of an other plain type. > > - Unconfuse one place about enum pipe vs enum trans

Re: [Intel-gfx] [PATCH] drm/i915: fixup sparse warnings

On Thu, 29 Nov 2012 22:18:51 +0100, Daniel Vetter wrote: > - __iomem where there is none (I love how we mix these things up). > - Use gfp_t instead of an other plain type. > - Unconfuse one place about enum pipe vs enum transcoder - for the pch > transcoder we actually use the pipe enum. Fixup

[Intel-gfx] [PATCH] drm/i915: Reduce memory pressure during shrinker by preallocating swizzle pages

On a machine with bit17 swizzling, we need to store the bit17 of the physical page address in put-pages. This requires a memory allocation, on average less than a page, which may be difficult to satisfy is the request to put-pages is on behalf of the shrinker. We could allow that allocation to pull

Re: [Intel-gfx] [PATCH 09/14] drm/i915: Remove check for conflicting relocation write-domains

On Mon, Dec 03, 2012 at 11:49:07AM +, Chris Wilson wrote: > Simply use the last write-domain set for the object in the batch, > trusting userspace to have correctly flushed the caches between usage as > a write target. This check dates back from the golden age of having only > a single operatio

Re: [Intel-gfx] [PATCH] drm/i915: Reduce memory pressure during shrinker by preallocating swizzle pages

On Mon, 3 Dec 2012 18:29:30 +0100, Daniel Vetter wrote: > On Mon, Dec 03, 2012 at 04:30:59PM +, Chris Wilson wrote: > > On a machine with bit17 swizzling, we need to store the bit17 of the > > physical page address in put-pages. This requires a memory allocation, > > on average less than a pag

Re: [Intel-gfx] [PATCH v3] drm/i915: Don't allow ring tail to reach the same cacheline as head

On Mon, Dec 03, 2012 at 06:43:32PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > From BSpec: > "If the Ring Buffer Head Pointer and the Tail Pointer are on the same > cacheline, the Head Pointer must not be greater than the Tail > Pointer." > > The easiest way to enforce

Re: [Intel-gfx] [PATCH] drm/i915: Reduce memory pressure during shrinker by preallocating swizzle pages

On Mon, Dec 03, 2012 at 04:30:59PM +, Chris Wilson wrote: > On a machine with bit17 swizzling, we need to store the bit17 of the > physical page address in put-pages. This requires a memory allocation, > on average less than a page, which may be difficult to satisfy is the > request to put-page

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Removed unsused define

On Mon, Dec 03, 2012 at 04:26:17PM +, Damien Lespiau wrote: > From: Damien Lespiau > > Signed-off-by: Damien Lespiau We've used this to detect the MT enabling on pre-production hw. Since I don't see any harm in keeping the #define around. So I'll punt on this one. -Daniel -- Daniel Vetter

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix dieing -> dying typo

On Mon, Dec 03, 2012 at 04:26:16PM +, Damien Lespiau wrote: > From: Damien Lespiau > > Signed-off-by: Damien Lespiau Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Intel-gfx] Working from home (Mon 3 Dec)

I'm not coming to the office today. I have a cold. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3] drm/i915: Don't allow ring tail to reach the same cacheline as head

From: Ville Syrjälä From BSpec: "If the Ring Buffer Head Pointer and the Tail Pointer are on the same cacheline, the Head Pointer must not be greater than the Tail Pointer." The easiest way to enforce this is to reduce the reported ring space. References: Gen2 BSpec "1. Programming Environment"

Re: [Intel-gfx] [PATCH v3 2/4] drm/i915: Wait for pending flips in intel_pipe_set_base()

On Fri, Nov 30, 2012 at 04:44:04PM +0100, Daniel Vetter wrote: > On Fri, Nov 30, 2012 at 3:01 PM, Ville Syrjälä > wrote: > > I had another look at this, and I think you're aiming for something other > > than what this patch is trying to do. > > Oh, I know that I'm trying to volunteer you to do a

Re: [Intel-gfx] [PATCH 01/10] drm/i915: rip out pre-DDI stuff from haswell_crtc_mode_set

On Mon, Dec 03, 2012 at 01:03:14PM -0200, Paulo Zanoni wrote: > Hi > > 2012/11/29 Daniel Vetter : > > Especially getting rid of all things lvds is ... great! > > > > v2: Drop the two additional pre-hsw hunks noticed by Paulo Zanoni. > > > > v3: > > - handle DP ports correctly (spoted by Paulo) > >

[Intel-gfx] [PATCH] drm/i915: Reduce memory pressure during shrinker by preallocating swizzle pages

On a machine with bit17 swizzling, we need to store the bit17 of the physical page address in put-pages. This requires a memory allocation, on average less than a page, which may be difficult to satisfy is the request to put-pages is on behalf of the shrinker. We could allow that allocation to pull

[Intel-gfx] [PATCH 2/2] drm/i915: Removed unsused define

From: Damien Lespiau Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/i915_reg.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index e5fe800..0c9a502 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i

[Intel-gfx] [PATCH 1/2] drm/i915: Fix dieing -> dying typo

From: Damien Lespiau Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/i915_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 9be450e..951f355 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/

[Intel-gfx] Bug Team Status

Another week, another bug team status: == Paulo Zanoni Investigated and fixed a lot of VGA Haswell bugs with some general bugzilla bookkeeping: - Fix our FDI link "retrain" code (if the first training attempt failed, the subsequent ones would always fail) - Reject modes we can't set (we only

Re: [Intel-gfx] [PATCH 02/14] drm/i915: Decouple the object from the unbound list before freeing pages

On Mon, Dec 03, 2012 at 11:49:00AM +, Chris Wilson wrote: > As we may actually allocate in order to save the physical swizzling bits > during the free, we have to be careful not to trigger the shrinker on > the same object. > > Signed-off-by: Chris Wilson Since this one here smells like a po

Re: [Intel-gfx] 3.7-rc7 IVB forcewake resume timeouts...

On 29 November 2012 02:57, Ben Widawsky wrote: > On Wed, 28 Nov 2012 11:13:14 +0800 > Daniel J Blueman wrote: > >> Hi Daniel/Ben, >> >> On stock 3.7-rc7, when resuming my Ivy Bridge laptop from suspend, the >> kernel logs: >> >> [drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting for >> f

Re: [Intel-gfx] [PATCH 02/10] drm/i915: don't handle PIPE_LEGACY_BLC_EVENT_STATUS on vlv

On Sat, 1 Dec 2012 13:53:41 +0100 Daniel Vetter wrote: > This is for legacy legacy stuff, and checking with the leftover > pipe from the previous loop is propably not what we want. Since > pipe == 2 after the loop ... > > Cc: Jesse Barnes > Signed-off-by: Daniel Vetter > --- > drivers/gpu/dr

[Intel-gfx] [PATCH 1/1] Add gem_seqno_wrap test

This test uses debugfs entry to set next_seqno close to a wrapping point and then creates a load with dependant buffer objects or with specified command to induce the wrap. Signed-off-by: Mika Kuoppala --- tests/Makefile.am |1 + tests/gem_seqno_wrap.c | 581 +++

Re: [Intel-gfx] [PATCH 06/10] drm/i915: drop unnecessary clearing of pch dp transcoder timings

Hi 2012/11/29 Daniel Vetter : > This has originally been added in > > commit 8db9d77b1b14fd730561f64beea8c00e4478d7c5 > Author: Zhenyu Wang > Date: Wed Apr 7 16:15:54 2010 +0800 > > drm/i915: Support for Cougarpoint PCH display pipeline > > probably to combat issues with hw state left behin

Re: [Intel-gfx] [PATCH 07/10] drm/i915: extract common link_m_n helpers

2012/11/29 Daniel Vetter : > Both the dp and fdi code use the exact same computations (ignore minor > differences in conversion between bits and bytes). > > This makes it even more apparent that we have a _massive_ mess between > cpu transcoder/fdi link/pch transcoder and pch link settings. And als

Re: [Intel-gfx] [PATCH 01/10] drm/i915: rip out pre-DDI stuff from haswell_crtc_mode_set

Hi 2012/11/29 Daniel Vetter : > Especially getting rid of all things lvds is ... great! > > v2: Drop the two additional pre-hsw hunks noticed by Paulo Zanoni. > > v3: > - handle DP ports correctly (spoted by Paulo) > - don't leave {} behind for a single-line block (again spotted by > Paulo) > -

[Intel-gfx] [PATCH 02/14] drm/i915: Decouple the object from the unbound list before freeing pages

As we may actually allocate in order to save the physical swizzling bits during the free, we have to be careful not to trigger the shrinker on the same object. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a

[Intel-gfx] [PATCH 09/14] drm/i915: Remove check for conflicting relocation write-domains

Simply use the last write-domain set for the object in the batch, trusting userspace to have correctly flushed the caches between usage as a write target. This check dates back from the golden age of having only a single operation per batch with the kernel repeating it for each cliprect, and confli

[Intel-gfx] [PATCH 14/14] drm/i915: Allow userspace to request an object at a specific offset

Certain workarounds and workloads require objects at specific or at least known offsets. Privileged users could pin an object into the GTT, but that has obvious limitations for the general case. Instead, the user can construct a batch assuming a particular layout for an object and request that the

[Intel-gfx] [PATCH 08/14] drm/i915: Tighten the checks for invalid relocation domains

Be specific for the GPU domains so that we can detect if userspace ever passed in an invalid combination, as well as accurately reflect the known GPU domains when printing state. Fixes i-g-t/gem_exec_bad_domains References: https://bugs.freedesktop.org/show_bug.cgi?id=57826 Signed-off-by: Chris W

[Intel-gfx] [PATCH 12/14] drm/i915: Allow userspace to hint that the relocations were known

Userspace is able to hint to the kernel that its command stream and auxiliary state buffers already hold the correct presumed addresses and so the relocation process may be skipped if the kernel does not need to move any buffers in preparation for the execbuffer. Thus for the common case where the

[Intel-gfx] [PATCH 13/14] drm/i915: Use the reloc.handle as an index into the execbuffer array

Using copywinwin10 as an example that is dependent upon emitting a lot of relocations (2 per operation), we see improvements of: c2d/gm45: 618000.0/sec to 623000.0/sec. i3-330m: 748000.0/sec to 789000.0/sec. (measured relative to a baseline with neither optimisations applied). Signed-off-by: Chr

[Intel-gfx] [PATCH 10/14] drm/i915: Take the handle idr spinlock once for looking up the exec objects

Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 86 +++- 1 file changed, 46 insertions(+), 40 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 1e53828..75792f6 100644 --

[Intel-gfx] [PATCH 11/14] drm/i915: Move the execbuffer objects list from the stack into the tracker

Instead of passing around the eb-objects hashtable and a separate object list, we can include the object list into the eb-objects structure for convenience. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 58 +--- 1 file changed, 27 insertio

[Intel-gfx] [PATCH 07/14] drm/i915: Preferentially allocate mappable GTT space to uncached bo

Both to reduce GTT wastage due to intermingling colouring and to reduce the number of cached bo allocated in the mappable aperture. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 13 + drivers/gpu/drm/i915/intel_ringbuffer.c | 13 + 2 files

[Intel-gfx] [PATCH 06/14] drm: Optionally create mm blocks from top-to-bottom

Clients like i915 needs to segregate cache domains within the GTT which can lead to small amounts of fragmentation. By allocating the uncached buffers from the bottom and the cacheable buffers from the top, we can reduce the amount of wasted space and also optimize allocation of the mappable portio

[Intel-gfx] [PATCH 04/14] drm/i915: Defer the unbind for a fence change until the next get_fence()

Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h|4 ++ drivers/gpu/drm/i915/i915_gem.c| 10 ++-- drivers/gpu/drm/i915/i915_gem_tiling.c | 87 3 files changed, 29 insertions(+), 72 deletions(-) diff --git a/drivers/gpu/drm/i9

[Intel-gfx] [PATCH 05/14] drm/i915: Avoid forcing relocations through the mappable GTT or CPU

If the object lies outside of the mappable GTT aperture, do not force it through the CPU domain for relocations, but simply flush the writes as we perform them and then queue a chipset flush. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 85 --

[Intel-gfx] [PATCH 03/14] drm/i915: Bail if we attempt to allocate pages for a purged object

Move the existing checking inside bind_to_gtt() to the more appropriate layer in order to prevent recreation of the pages after they have been explicitly truncated. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-

[Intel-gfx] [PATCH 01/14] drm/i915: Move the get_pages assertions up to the right layer

A useful assertion resided inside the get_pages_gtt() routine, which is generally applicable. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c

[Intel-gfx] A bunch of random execbuffer patches

So Daniel likes the "Tighten the checks for invalid relocation domains" so much he wrote a i-g-t for it. Here is the patch to fix it - only I had it inside a patch series to adjust the execbuffer API to reduce the relocation overhead, which in turn requires a couple of other patches. Then I threw i

[Intel-gfx] [ANNOUNCE] xf86-video-intel 2.20.15

Release 2.20.15 (2012-12-03) And lo, enabling more of the common acceleration paths for gen4 revealed another lurking bug - something is wrong with how we prepare Y-tiling surfaces for rendering. For the time being, we can surreptiously disable them for gen4 and avoid h

[Intel-gfx] [PATCH] drm/i915: Close race between processing unpin task and queueing the flip

Before queuing the flip but crucially after attaching the unpin-work to the crtc, we continue to setup the unpin-work. However, should the hardware fire early, we see the connected unpin-work and queue the task. The task then promptly runs and unpins the fb before we finish taking the required refe

[Intel-gfx] [PATCH] drm/i915: Dump RP interrupt limits into debugfs/i915_cur_delayinfo

Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 58e6676..5359f376 100644 --- a/drivers/gpu/drm/i915/i915_

[Intel-gfx] [PATCH] drm/i915: Close race between processing unpin task and queueing the flip

Before queuing the flip but crucially after attaching the unpin-work to the crtc, we continue to setup the unpin-work. However, should the hardware fire early, we see the connected unpin-work and queue the task. The task then promptly runs and unpins the fb before we finish taking the required refe