[Intel-gfx] [PATCH v4] intel: New libdrm interface to create unbound wc user mappings for objects

2014-12-14 Thread akash . goel
From: Akash Goel A new libdrm interface 'drm_intel_gem_bo_map_wc' is provided by this patch. Through this interface Gfx clients can create write combining virtual mappings of the Gem object. It will provide the same funtionality of 'mmap_gtt' interface without the constraints of limited aperture

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Opportunistically reduce flushing at execbuf

2014-12-14 Thread shuang . he
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) -Summary- Platform Delta drm-intel-nightly Series Applied PNV 364/364

Re: [Intel-gfx] [PATCH 1/4] drm/cache: Use wbinvd helpers

2014-12-14 Thread Chris Wilson
On Sat, Dec 13, 2014 at 07:08:21PM -0800, Ben Widawsky wrote: > When the original drm code was written there were no centralized functions for > doing a coordinated wbinvd across all CPUs. Now (since 2010) there are, so use > them instead of rolling a new one. > > Cc: Intel GFX > Signed-off-by: B

Re: [Intel-gfx] [PATCH 2/4] drm/cache: Try to be smarter about clflushing on x86

2014-12-14 Thread Chris Wilson
On Sat, Dec 13, 2014 at 07:08:22PM -0800, Ben Widawsky wrote: > Any GEM driver which has very large objects and a slow CPU is subject to very > long waits simply for clflushing incoherent objects. Generally, each > individual > object is not a problem, but if you have very large objects, or very m

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Opportunistically reduce flushing at execbuf

2014-12-14 Thread Ville Syrjälä
On Sat, Dec 13, 2014 at 07:08:24PM -0800, Ben Widawsky wrote: > If we're moving a bunch of buffers from the CPU domain to the GPU domain, and > we've already blown out the entire cache via a wbinvd, there is nothing more > to > do. > > With this and the previous patches, I am seeing a 3x FPS incr

Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl: Skylake also supports DP MST

2014-12-14 Thread Dave Airlie
On 13 December 2014 at 00:26, Damien Lespiau wrote: > I've checked that TRANS_DDI_MODE, DP_TP_CTL MST bits are identical to > HSW/BDW on SKL, as well as the long vs short HPD bits. So we have a good > chance to be working as well as prevous platforms. > > Signed-off-by: Damien Lespiau Seems like

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Opportunistically reduce flushing at execbuf

2014-12-14 Thread Ben Widawsky
On Sun, Dec 14, 2014 at 03:12:21PM +0200, Ville Syrjälä wrote: > On Sat, Dec 13, 2014 at 07:08:24PM -0800, Ben Widawsky wrote: > > If we're moving a bunch of buffers from the CPU domain to the GPU domain, > > and > > we've already blown out the entire cache via a wbinvd, there is nothing > > more

Re: [Intel-gfx] [PATCH 2/4] drm/cache: Try to be smarter about clflushing on x86

2014-12-14 Thread Jesse Barnes
On 12/14/2014 4:59 AM, Chris Wilson wrote: One of the things wbinvd is considered evil for is that it blocks the CPU for an indeterminate amount of time - upsetting latency critcial aspects of the OS. For example, the x86/mm has similar code to use wbinvd for large clflushes that caused a bit of

[Intel-gfx] [Regression] 3.18 black screen after boot (bisected)

2014-12-14 Thread Heinz Diehl
Hi, since kernel 3.18 I'm no longer able to run X on my machine. While 3.17.6 is fine, 3.18 leaves me with a black screen when starting X. Booting into runlevel 1/3 is fine. I did a "git bisect", and the offending commit is this one: [root@kiera linux-git]# git bisect bad 83f45fc360c8e16a3304748

Re: [Intel-gfx] [PATCH 3/4] drm/i915: New offset for reading frequencies on CHV.

2014-12-14 Thread Jani Nikula
On Fri, 12 Dec 2014, Ville Syrjälä wrote: > On Fri, Dec 12, 2014 at 02:18:15PM +0530, deepa...@linux.intel.com wrote: >> From: Deepak S >> >> Use new Sideband offset to read max/min/gaur freq based on the SKU it >> is running on. Based on the Number of EU, we read different bits to >> identify t

Re: [Intel-gfx] [Regression] 83f45fc turns machine's screen off

2014-12-14 Thread Daniel Vetter
On Sun, Dec 14, 2014 at 02:07:19AM +0100, Emmanuel Benisty wrote: > Hi Daniel, > > > On Mon, Nov 10, 2014 at 10:19 PM, Daniel Vetter > > wrote: > >> Adding relevant mailing lists. > >> > >> > >> On Sat, Nov 8, 2014 at 7:34 PM, Emmanuel Benisty > >> wrote: > >>> Hi, > >>> > >>> The following co

Re: [Intel-gfx] [drm:hsw_unclaimed_reg_detect] *ERROR* Unclaimed register detected. Please use the i915.mmio_debug=1 to debug this problem.

2014-12-14 Thread Daniel Vetter
On Fri, Dec 12, 2014 at 01:31:54PM +0100, Toralf Förster wrote: > A syslog entry of a newly installed ThinkPad T440s advices me : > > Dec 12 00:17:59 t44 kernel: [drm:hsw_unclaimed_reg_detect] *ERROR* Unclaimed > register detected. Please use the i915.mmio_debug=1 to debug this problem. > > aft

Re: [Intel-gfx] [PATCH 1/4] drm/cache: Use wbinvd helpers

2014-12-14 Thread Daniel Vetter
On Sun, Dec 14, 2014 at 12:43:10PM +, Chris Wilson wrote: > On Sat, Dec 13, 2014 at 07:08:21PM -0800, Ben Widawsky wrote: > > When the original drm code was written there were no centralized functions > > for > > doing a coordinated wbinvd across all CPUs. Now (since 2010) there are, so > > u

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Opportunistically reduce flushing at execbuf

2014-12-14 Thread Daniel Vetter
On Sun, Dec 14, 2014 at 03:37:36PM -0800, Ben Widawsky wrote: > On Sun, Dec 14, 2014 at 03:12:21PM +0200, Ville Syrjälä wrote: > > On Sat, Dec 13, 2014 at 07:08:24PM -0800, Ben Widawsky wrote: > > > If we're moving a bunch of buffers from the CPU domain to the GPU domain, > > > and > > > we've alr

Re: [Intel-gfx] [Regression] 3.18 black screen after boot (bisected)

2014-12-14 Thread Daniel Vetter
On Sun, Dec 14, 2014 at 12:58:31PM +0100, Heinz Diehl wrote: > Hi, > > since kernel 3.18 I'm no longer able to run X on my machine. While > 3.17.6 is fine, 3.18 leaves me with a black screen when starting > X. Booting into runlevel 1/3 is fine. > > I did a "git bisect", and the offending commit i