From: Akash Goel akash.g...@intel.com
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
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 364/364
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
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 many
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 increase
On 13 December 2014 at 00:26, Damien Lespiau damien.lesp...@intel.com 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
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 to
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
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
On Fri, 12 Dec 2014, Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Fri, Dec 12, 2014 at 02:18:15PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
Use new Sideband offset to read max/min/gaur freq based on the SKU it
is running on. Based on the Number
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 daniel.vet...@ffwll.ch
wrote:
Adding relevant mailing lists.
On Sat, Nov 8, 2014 at 7:34 PM, Emmanuel Benisty benist...@gmail.com
wrote:
Hi,
The
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.
after ei
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
use
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 already blown
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 is this
15 matches
Mail list logo
