Re: [Intel-gfx] [PATCH v7 5/5] drm/i915: Tidy up execbuffer command parsing code

2014-12-13 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] drm/i915: Refactor work that can sleep out of commit (v4)

2014-12-13 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] [Regression] 83f45fc turns machine's screen off

2014-12-13 Thread Emmanuel Benisty
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 commit permanently turns my screen off when x server is >>> started (i3 330M Ironlake): >>> >>>

[Intel-gfx] [PATCH 3/4] drm/cache: Return what type of cache flush occurred

2014-12-13 Thread Ben Widawsky
The caller of the cache flush APIs can sometimes do useful things with the information of how the cache was flushed. For instance, when giving buffers to the GPU to read, we need to make sure all of them have properly invalidated the caches (when not using LLC). If we can determine a wbinvd() occur

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

2014-12-13 Thread Ben Widawsky
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 increase on a certain benchmark which uses a giant 2d array texture. Unless I m

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

2014-12-13 Thread Ben Widawsky
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: Ben Widawsky --- drivers/gpu/drm/drm_cache.c | 12 +++- 1 file ch

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

2014-12-13 Thread Ben Widawsky
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 many objects, the flushing begins to show up in profiles. Because on x86

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

2014-12-13 Thread Matt Turner
On Sat, Dec 13, 2014 at 7:08 PM, 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 many > ob

Re: [Intel-gfx] [PATCH] drm/i915: fix use after free during eDP encoder destroying

2014-12-13 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 3/3] drm/i915: Track & check calls to intel(_logical)_ring_{begin, advance}

2014-12-13 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 2/2] drm/i915/skl: Skylake also supports DP MST

2014-12-13 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