[Intel-gfx] [PATCH v2] drm/i915: use semaphores for the display plane

In theory this will have performance and power improvements. Performance because we don't need to stall when the scanout BO is busy, and power because we don't have to stall when the BO is busy (and the ring can even go to sleep if the HW supports it). v2: squash 2 patches into 1 (me) un-inline th

[Intel-gfx] [PATCH] Mask reserved bits in display/sprite address registers

The patch file for this change is attached. Had to send it from Outlook and wanted to avoid corrupting the patch. Hence, the attachment. Armin mask.patch Description: mask.patch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.

[Intel-gfx] [PATCH] Removed IVB forced enable of sprite dest key

The patch file for this change is attached. Had to send it from Outlook and wanted to avoid corrupting the patch. Hence, the attachment. Armin destkey.patch Description: destkey.patch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://

Re: [Intel-gfx] i915_gem_init_aliasing_ppgtt() loop after 55a254ac63a3ac1867d1501030e7fba69c7d4aeb

On Thu, Apr 05, 2012 at 03:04:39PM +0300, Konstantin Belousov wrote: > On Thu, Apr 05, 2012 at 01:55:12PM +0200, Daniel Vetter wrote: > > On Thu, Apr 5, 2012 at 13:04, Konstantin Belousov > > wrote: > > > it seems that the loop in i915_gem_init_aliasing_ppgtt() over pd_entries > > > that calculat

Re: [Intel-gfx] i915_gem_init_aliasing_ppgtt() loop after 55a254ac63a3ac1867d1501030e7fba69c7d4aeb

On Thu, Apr 05, 2012 at 01:55:12PM +0200, Daniel Vetter wrote: > On Thu, Apr 5, 2012 at 13:04, Konstantin Belousov wrote: > > it seems that the loop in i915_gem_init_aliasing_ppgtt() over pd_entries > > that calculates pt_addr does nothing after the commit 55a254ac in the > > !dmar case. Would it

Re: [Intel-gfx] i915_gem_init_aliasing_ppgtt() loop after 55a254ac63a3ac1867d1501030e7fba69c7d4aeb

On Thu, Apr 5, 2012 at 13:04, Konstantin Belousov wrote: > it seems that the loop in i915_gem_init_aliasing_ppgtt() over pd_entries > that calculates pt_addr does nothing after the commit 55a254ac in the > !dmar case. Would it be better to move needs_dmar check over the whole > loop ? For the !dm

[Intel-gfx] i915_gem_init_aliasing_ppgtt() loop after 55a254ac63a3ac1867d1501030e7fba69c7d4aeb

Hi, it seems that the loop in i915_gem_init_aliasing_ppgtt() over pd_entries that calculates pt_addr does nothing after the commit 55a254ac in the !dmar case. Would it be better to move needs_dmar check over the whole loop ? pgpyf1Pcayllx.pgp Description: PGP signature ___

[Intel-gfx] Updated -next

Hi all, I've pushed out a new -next and testing tree. Highlights: - first batch of hsw enabling (Eugeni) - first batch of vlv enabling (Jesse and others) - a few cleanups spurred by the above items - pwrite/pread rework and speedups - less mappable pressure and reloc optimizations (Chris) - mmap_o