Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6683
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
Regards
Shashank
On 7/1/2015 6:26 PM, Daniel Vetter wrote:
On Tue, Jun 30, 2015 at 09:49:57PM +0530, Shashank Sharma wrote:
Userspace always sets force. Are you sure this actually improves anything?
Yes we do. We have had this code for commercial projects, and that's really
important to have
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6681
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
From: Ville Syrjälä
Split ilk_update_wm() into two parts; one doing the programming
and the other the calculations.
v2: Fix typo in commit message
v3 (by Matt): Heavily rebased for current codebase.
Reviewed-by(v2): Paulo Zanoni
Signed-off-by: Ville Syrjälä
Signed-off-by: Matt Roper
---
dr
Determine whether we need to apply this workaround at atomic check time
and just set a flag that will be used by the main watermark update
routine.
Moving this workaround into the atomic framework reduces
ilk_update_sprite_wm() to just a standard watermark update, so drop it
completely and just en
Calculate pipe watermarks during atomic calculation phase, based on the
contents of the atomic transaction's state structure. We still program
the watermarks at the same time we did before, but the computation now
happens much earlier.
While this patch isn't too exciting by itself, it paves the w
Add a simple mechanism to trigger final watermark updates in an
asynchronous manner once the next vblank occurs. No platform types
actually support atomic watermark programming until a future patch, so
there should be no functional change yet; individual platforms will be
converted to use this mec
Just pull the info out of the CRTC state structure rather than staging
it in an additional structure.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 84 ++---
1 file changed, 28 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915
Just pull the info out of the plane state structure rather than staging
it in an additional structure.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 133 +---
1 file changed, 70 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i91
Since we allocate a few CRTC states on the stack, also switch the 'wm'
struct here to be a union so that we're not wasting stack space with
other platforms' watermark values.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 8 --
drivers/gpu/drm/i915/intel_drv.h | 54
From: Matt Roper
In addition to calculating final watermarks, let's also pre-calculate a
set of intermediate watermark values at atomic check time. These
intermediate watermarks are a combination of the watermarks for the old
state and the new state; they should satisfy the requirements of both
Here's a second RFC for transitioning watermark updates to an atomic model. As
in the first series, I'm only transitioning a single platform style to start
with (ilk-style watermarks). For pre-gen9 platforms, two sets of watermarks
are pre-computed at atomic 'check' time --- one set that can be p
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6680
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
Signed-off-by: Damien Lespiau
---
lib/igt_aux.h | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/lib/igt_aux.h b/lib/igt_aux.h
index 9ea50de..2979314 100644
--- a/lib/igt_aux.h
+++ b/lib/igt_aux.h
@@ -91,8 +91,16 @@ void intel_require_memory(uint32_t count, uint32
Makes using GDB better on those binaries.
Signed-off-by: Damien Lespiau
---
lib/tests/Makefile.am | 2 +-
tools/Makefile.am | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/tests/Makefile.am b/lib/tests/Makefile.am
index 938d2ab..f09d2fe 100644
--- a/lib/tests/Makef
When developing, it's quite annoying that the version changes every
commit, causing the library to be rebuild and everything single binary
re-linked.
Add a config option to skip that.
I remember Ville asking for this "feature" as well.
Cc: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
confi
Useful knowledge for anyone looking at the documentation and following
the linkes.
Signed-off-by: Damien Lespiau
---
lib/igt_stats.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/lib/igt_stats.c b/lib/igt_stats.c
index b7053c3..70650ec 100644
--- a/lib/igt_stats.c
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6679
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On Wed, Jul 01, 2015 at 05:15:26PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Everything is covered either by fbc.lock or mm.stolen_lock, and
> intel_fbc.c is already responsible for grabbing the appropriate locks
> when it needs them.
>
> Signed-off-by: Paulo Zanoni
5-7 Reviewed-by: C
On Wed, Jul 01, 2015 at 05:15:23PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Make sure we're not going to have weird races in really weird cases
> where a lot of different CRTCs are doing rendering and modesets at the
> same time.
>
> With this change and the stolen_lock from the previ
On Wed, Jul 01, 2015 at 05:15:21PM -0300, Paulo Zanoni wrote:
Looks much cleaner with the split.
> +void intel_fbc_cleanup_cfb(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> +
> + if (dev_priv->fbc.uncompressed_size == 0)
> + return;
>
On Wed, Jul 01, 2015 at 05:15:20PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We want to move the FBC code out of i915_gem_stolen.c, but that code
> directly adds/removes stolen memory nodes. Let's create this
> abstraction, so i915_gme_stolen.c is still in control of all the
> stolen me
On Wed, Jul 01, 2015 at 10:13:38PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> CxSR (or maxfifo on VLV/CHV) blocks somne changes to the plane control
> register (enable bit at least, not quite sure about the rest). So in
> order to have the plane enable/disable when we w
On Wed, Jul 01, 2015 at 05:15:22PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Which should protect dev_priv->mm.stolen usage. This will allow us to
> simplify the relationship between stolen memory, FBC and struct_mutex.
Too coarse. The locking need only be around the stolen drm_mm, i.e
From: Paulo Zanoni
Which should protect dev_priv->mm.stolen usage. This will allow us to
simplify the relationship between stolen memory, FBC and struct_mutex.
Cc: Chris Wilson
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h| 7 +++-
drivers/gpu/drm/i915/i915_gem_stol
From: Paulo Zanoni
With the abstractions created by the last patch, we can move this code
and the only thing inside intel_fbc.c that knows about dev_priv->mm is
the code that reads stolen_base.
We also had to move a call to i915_gem_stolen_cleanup_compression()
- now called intel_fbc_cleanup_cfb
From: Paulo Zanoni
So don't grab the lock before calling the function.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index
From: Paulo Zanoni
So release the lock earlier.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e12ed4f..219e4c5 100644
--
From: Paulo Zanoni
Everything is covered either by fbc.lock or mm.stolen_lock, and
intel_fbc.c is already responsible for grabbing the appropriate locks
when it needs them.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_debugfs.c | 4
drivers/gpu/drm/i915/intel_display.c | 14
From: Paulo Zanoni
We want to move the FBC code out of i915_gem_stolen.c, but that code
directly adds/removes stolen memory nodes. Let's create this
abstraction, so i915_gme_stolen.c is still in control of all the
stolen memory handling. These abstractions will also allow us to add
locking assert
From: Paulo Zanoni
Make sure we're not going to have weird races in really weird cases
where a lot of different CRTCs are doing rendering and modesets at the
same time.
With this change and the stolen_lock from the previous patch, we can start
removing the struct_mutex locking we have around FBC
From: Paulo Zanoni
Hi
So, based on the reviews, here's v4 of the series, now with
dev_priv->mm.stolen_lock. This allows us to completely get rid of struct_mutex
locking around FBC calls. Kudos to Chris for the suggestion.
The patch that added intel_fbc_stop() got removed from this series becaus
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6678
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
2015-07-01 16:13 GMT-03:00 :
> From: Ville Syrjälä
>
> CxSR (or maxfifo on VLV/CHV) blocks somne changes to the plane control
> register (enable bit at least, not quite sure about the rest). So in
> order to have the plane enable/disable when we want we need to first
> kick the hardware out of cx
2015-07-01 9:19 GMT-03:00 Daniel Vetter :
> On Thu, Jun 25, 2015 at 03:16:37PM +0200, Daniel Vetter wrote:
>> On Thu, Jun 25, 2015 at 02:18:06PM +0300, David Weinehall wrote:
>> > On Thu, Jun 25, 2015 at 09:37:22AM +0200, Daniel Vetter wrote:
>> > > On Thu, Jun 25, 2015 at 09:14:09AM +0300, David W
From: Ville Syrjälä
CxSR (or maxfifo on VLV/CHV) blocks somne changes to the plane control
register (enable bit at least, not quite sure about the rest). So in
order to have the plane enable/disable when we want we need to first
kick the hardware out of cxsr.
Unfortunateloy this requires some ex
On Tue, 2015-06-30 at 15:33 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Here's my second attempt at flipping HDMI 12bpc back on. In my last attempt
> [1]
> Imre found that lots of standard CEA modes (1080p60 etc.) no longer work on
> BXT due to the 12bpc port clock land
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6676
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
Hi Michel,
Although I cannot comment on the exact implementation I can give you
general some tips which you might find useful.
On 1 July 2015 at 16:28, Michel Thierry wrote:
> Gen8+ supports 48-bit virtual addresses, but some objects must always be
> allocated inside the 32-bit address range.
>
On Wed, 2015-07-01 at 15:39 +0200, Daniel Vetter wrote:
> On Wed, Jul 01, 2015 at 02:55:12PM +0530, ankitprasad.r.sha...@intel.com
> wrote:
> > From: Rodrigo Vivi
> >
> > When constructing a batchbuffer, it is sometimes crucial to know the
> > largest hole into which we can fit a fenceable buffe
On Wed, Jul 01, 2015 at 03:54:55PM +0100, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 07/01/2015 10:25 AM, ankitprasad.r.sha...@intel.com wrote:
> >From: Ankitprasad Sharma
> >
> >This patch adds support for clearing buffer objects via blitter
> >engines. This is particularly useful for clearing out th
On Wed, Jul 01, 2015 at 04:06:49PM +0100, Tvrtko Ursulin wrote:
>
>
> On 07/01/2015 10:25 AM, ankitprasad.r.sha...@intel.com wrote:
> >From: Ankitprasad Sharma
> >
> >Extend the drm_i915_gem_create structure to add support for
> >creating Stolen memory backed objects. Added a new flag through
>
On 07/01/2015 10:25 AM, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
Extend the drm_i915_gem_create structure to add support for
creating Stolen memory backed objects. Added a new flag through
which user can specify the preference to allocate the object from
stolen memory, wh
On 07/01/2015 10:25 AM, ankitprasad.r.sha...@intel.com wrote:
From: Chris Wilson
If we run out of stolen memory when trying to allocate an object, see if
we can reap enough purgeable objects to free up enough contiguous free
space for the allocation. This is in principle very much like evictin
There are some allocations that must be only referenced by 32-bit
offsets. To limit the chances of having the first 4GB already full,
objects not requiring this workaround use DRM_MM_SEARCH_BELOW/
DRM_MM_CREATE_TOP flags
In specific, any resource used with flat/heapless (0x-0xf000)
Gen
On 01/07/2015 16:27, Michel Thierry wrote:
Otherwise it can overflow in 48-bit mode, and cause an incorrect
exec_start.
Before commit 5f19e2bff ("drm/i915: Merged the many do_execbuf()
parameters into a structure"), it was already an u64, so it could be
seen as a regression (or as an optimizatio
On 7/1/2015 4:43 PM, Chris Wilson wrote:
On Wed, Jul 01, 2015 at 04:27:32PM +0100, Michel Thierry wrote:
+ flags |= PIN_ZONE_4G;
+ if (entry->flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS)
+ flags &= ~PIN_ZONE_4G;
+
if (!drm_mm_node_allocated(&vma->node)) {
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6675
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On Wed, Jul 01, 2015 at 04:27:32PM +0100, Michel Thierry wrote:
> There are some allocations that must be only referenced by 32-bit
> offsets. To limit the chances of having the first 4GB already full,
> objects not requiring this workaround use DRM_MM_SEARCH_BELOW/
> DRM_MM_CREATE_TOP flags
>
> I
On Wed, Jul 01, 2015 at 08:17:37AM -0700, Jesse Barnes wrote:
> On 07/01/2015 06:56 AM, Daniel Vetter wrote:
> > On Tue, Jun 30, 2015 at 01:30:27PM -0700, Jesse Barnes wrote:
> >> On 06/30/2015 07:36 AM, Chris Wilson wrote:
> >>> On Tue, Jun 30, 2015 at 11:26:11AM -0300, Paulo Zanoni wrote:
>
On Wed, Jul 01, 2015 at 08:14:30AM -0700, Jesse Barnes wrote:
> On 07/01/2015 06:53 AM, Peter Antoine wrote:
> > On Wed, 1 Jul 2015, Francisco Jerez wrote:
> >
> >> Peter Antoine writes:
> >>
> >>> On Tue, 30 Jun 2015, Francisco Jerez wrote:
> >>>
> Francisco Jerez writes:
>
> > Pe
On Wed, Jul 01, 2015 at 04:27:16PM +0100, Michel Thierry wrote:
> These are the rebased patches, after Mika's final ppgtt clean-up series landed
> (it relies in the macros added). New functions also follow these changes.
>
> In order expand the GPU address space, a 4th level translation is added,
On Wed, Jul 01, 2015 at 04:27:31PM +0100, Michel Thierry wrote:
> GTT was only 32b and its max value is 4GB. In order to allow objects
> bigger than 4GB in 48b PPGTT, i915_gem_userptr_ioctl we could check
> against max 48b range (1ULL << 48).
>
> But since the check no longer applies, just kill th
Gen8+ supports 48-bit virtual addresses, but some objects must always be
allocated inside the 32-bit address range.
In specific, any resource used with flat/heapless (0x-0xf000)
General State Heap or Intruction State Heap must be in a 32-bit range
(GSH / ISH), because the General State
This transitional patch doesn't do much for the existing code. However,
it should make upcoming patches to use the full 48b address space a bit
easier. The patch also introduces the PML4, ie. the new top level structure
of the page tables.
v2: Renamed pdp_free to be similar to pd/pt (unmap_and_f
PML4 has no special attributes, and there will always be a PML4.
So simply initialize it at creation, and destroy it at the end.
The code for 4lvl is able to call into the existing 3lvl page table code
to handle all of the lower levels.
v2: Return something at the end of gen8_alloc_va_range_4lvl
When 48b is enabled, gen8_ppgtt_insert_entries needs to read the Page Map
Level 4 (PML4), before it selects which Page Directory Pointer (PDP)
it will write to.
Similarly, gen8_ppgtt_clear_range needs to get the correct PDP/PD range.
This patch was inspired by Ben's "Depend exclusively on map and
Gen8+ supports 48-bit virtual addresses, but some objects must always be
allocated inside the 32-bit address range.
In specific, any resource used with flat/heapless (0x-0xf000)
General State Heap (GSH) or Intruction State Heap (ISH) must be in a
32-bit range, because the General State
The insert_entries function was the function used to write PTEs. For the
PPGTT it was "hardcoded" to only understand two level page tables, which
was the case for GEN7. We can reuse this for 4 level page tables, and
remove the concept of insert_entries, which was never viable past 2
level page tabl
There are some allocations that must be only referenced by 32-bit
offsets. To limit the chances of having the first 4GB already full,
objects not requiring this workaround use DRM_MM_SEARCH_BELOW/
DRM_MM_CREATE_TOP flags
In specific, any resource used with flat/heapless (0x-0xf000)
Gen
Use 48b addresses if hw supports it (i915.enable_ppgtt=3).
Note, aliasing PPGTT remains 32b only.
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
drivers/gpu/drm/i915/i915_params.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gp
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Michel Thierry
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 001fd3d..12b8465 100644
--- a/configure.ac
+++ b/configure.ac
@@ -20,7 +20,7 @@
AC_PREREQ([2.63])
AC_INIT([l
Otherwise it can overflow in 48-bit mode, and cause an incorrect
exec_start.
Before commit 5f19e2bff ("drm/i915: Merged the many do_execbuf()
parameters into a structure"), it was already an u64, so it could be
seen as a regression (or as an optimization that looked good at that time).
Cc: John H
GTT was only 32b and its max value is 4GB. In order to allow objects
bigger than 4GB in 48b PPGTT, i915_gem_userptr_ioctl we could check
against max 48b range (1ULL << 48).
But since the check no longer applies, just kill the limit.
v2: Use the default ctx to infer the ppgtt max size (Akash).
v3:
gen8_clamp_pd clamps to the next page directory boundary, but the macro
gen8_for_each_pde already has a check to stop at the page directory boundary.
Furthermore, i915_pte_count also restricts to the next page table
boundary.
v2: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
Su
In a 48b world, users can try to allocate buffers bigger than 4GB; in
these cases it is important that size is a 64b variable.
Also added a warning for illegal bind with size = 0.
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem.c | 5 +++--
drivers/gpu/drm/i915/i915_gem_gtt.
Signed-off-by: Ben Widawsky
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_gpu_error.c | 17 +
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i91
As a step towards implementing 4 levels, while not discarding the
existing pte insert functions, we need to pass the sg_iter through.
The current function understands to the page directory granularity.
An object's pages may span the page directory, and so using the iter
directly as we write the PTE
v2: Clean up patch after rebases.
v3: gen8_dump_ppgtt for 32b and 48b PPGTT.
v4: Use used_pml4es/pdpes (Akash).
v5: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
Signed-off-by: Ben Widawsky
Signed-off-by: Michel Thierry (v2+)
---
drivers/gpu/drm/i915/i915_debugfs.c | 18 --
In 64b (48bit canonical) PPGTT addressing, the PDP0 register contains
the base address to PML4, while the other PDP registers are ignored.
In LRC, the addressing mode must be specified in every context descriptor.
v2: PML4 update in legacy context switch is left for historic reasons,
the preferre
Up until now, ppgtt->pdp has always been the root of our page tables.
Legacy 32b addresses acted like it had 1 PDP with 4 PDPEs.
In preparation for 4 level page tables, we need to stop use ppgtt->pdp
directly unless we know it's what we want. The future structure will use
ppgtt->pml4 for the top l
The dynamic page allocation patch series added it for GEN6, this patch
adds them for GEN8.
v2: Consolidate pagetable/page_directory events
v3: Multiple rebases.
v4: Rebase after s/page_tables/page_table/.
v5: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
Signed-off-by: Ben Widaw
Similar to PDs, while setting up a page directory pointer, make all entries
of the pdp point to the scratch pdp before mapping (and make all its entries
point to the scratch page); this is to be safe in case of out of bound
access or proactive prefetch.
Although the ggtt is always 32-bit, the scr
These are the rebased patches, after Mika's final ppgtt clean-up series landed
(it relies in the macros added). New functions also follow these changes.
In order expand the GPU address space, a 4th level translation is added, the
Page Map Level 4 (PML4). This PML4 has 256 PML4 Entries (PML4E), PML
On Wed, Jul 1, 2015 at 2:21 PM, David Weinehall
wrote:
> On Tue, Jun 30, 2015 at 03:01:06PM +0100, Chris Wilson wrote:
>> On Tue, Jun 30, 2015 at 04:36:55PM +0300, David Weinehall wrote:
>> > On Tue, Jun 30, 2015 at 02:32:19PM +0100, Chris Wilson wrote:
>> > > On Tue, Jun 30, 2015 at 04:01:23PM +0
Francisco Jerez writes:
> Peter Antoine writes:
>
>> On Wed, 1 Jul 2015, Francisco Jerez wrote:
>>
>>> Peter Antoine writes:
>>>
On Tue, 30 Jun 2015, Francisco Jerez wrote:
> Francisco Jerez writes:
>
>> Peter Antoine writes:
>>
>>> On Mon, 29 Jun 2015, Peter Ant
On 07/01/2015 06:56 AM, Daniel Vetter wrote:
> On Tue, Jun 30, 2015 at 01:30:27PM -0700, Jesse Barnes wrote:
>> On 06/30/2015 07:36 AM, Chris Wilson wrote:
>>> On Tue, Jun 30, 2015 at 11:26:11AM -0300, Paulo Zanoni wrote:
2015-06-30 11:15 GMT-03:00 Chris Wilson :
> On Tue, Jun 30, 2015 at
On 07/01/2015 06:53 AM, Peter Antoine wrote:
> On Wed, 1 Jul 2015, Francisco Jerez wrote:
>
>> Peter Antoine writes:
>>
>>> On Tue, 30 Jun 2015, Francisco Jerez wrote:
>>>
Francisco Jerez writes:
> Peter Antoine writes:
>
>> On Mon, 29 Jun 2015, Peter Antoine wrote:
>>
> Userspace always sets force. Are you sure this actually improves anything?
Yes we do. We have had this code for commercial projects, and that's really
important to have proper interrupt handling as well as to avoid race
condition between multiple HDMI detects from interrupt handler and
userspace
On 07/01/2015 10:25 AM, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
Extend the drm_i915_gem_create structure to add support for
creating Stolen memory backed objects. Added a new flag through
which user can specify the preference to allocate the object from
stolen memory, w
Peter Antoine writes:
> On Wed, 1 Jul 2015, Francisco Jerez wrote:
>
>> Peter Antoine writes:
>>
>>> On Tue, 30 Jun 2015, Francisco Jerez wrote:
>>>
Francisco Jerez writes:
> Peter Antoine writes:
>
>> On Mon, 29 Jun 2015, Peter Antoine wrote:
>>
>>> On Thu, 25 Ju
On Wed, Jul 01, 2015 at 05:54:06PM +0300, Ander Conselvan De Oliveira wrote:
> On Tue, 2015-06-30 at 18:41 +0300, Jani Nikula wrote:
> > On Tue, 30 Jun 2015, Daniel Vetter wrote:
> > > On Tue, Jun 30, 2015 at 04:47:06PM +0300, Jani Nikula wrote:
> > >> On Tue, 30 Jun 2015, Ander Conselvan de Olive
Hi,
On 07/01/2015 10:25 AM, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
This patch adds support for clearing buffer objects via blitter
engines. This is particularly useful for clearing out the memory
from stolen region.
Because CPU cannot access it? I would put that into
On Tue, 2015-06-30 at 18:41 +0300, Jani Nikula wrote:
> On Tue, 30 Jun 2015, Daniel Vetter wrote:
> > On Tue, Jun 30, 2015 at 04:47:06PM +0300, Jani Nikula wrote:
> >> On Tue, 30 Jun 2015, Ander Conselvan de Oliveira
> >> wrote:
> >> > Similarly to what is done for SKL, clear the dpll_hw_state o
On Wed, Jul 01, 2015 at 03:25:09PM +0100, Michel Thierry wrote:
> On 7/1/2015 3:26 PM, Daniel Vetter wrote:
> >On Wed, Jul 01, 2015 at 03:05:44PM +0100, Michel Thierry wrote:
> >>On 6/30/2015 4:16 PM, Mika Kuoppala wrote:
> >>>Previously we have pointed the page where the individual ppgtt
> >>>scra
On Wed, Jul 01, 2015 at 04:09:19PM +0200, Daniel Vetter wrote:
> On Wed, Jul 01, 2015 at 02:21:40PM +0100, Chris Wilson wrote:
> > On Wed, Jul 01, 2015 at 03:19:31PM +0200, Daniel Vetter wrote:
> > > On Wed, Jul 01, 2015 at 09:04:08AM +0100, Chris Wilson wrote:
> > > > On Tue, Jun 30, 2015 at 04:42
On 7/1/2015 3:26 PM, Daniel Vetter wrote:
On Wed, Jul 01, 2015 at 03:05:44PM +0100, Michel Thierry wrote:
On 6/30/2015 4:16 PM, Mika Kuoppala wrote:
Previously we have pointed the page where the individual ppgtt
scratch structures refer to, to be the instance which GGTT setup have
allocated. So
On Wed, Jul 01, 2015 at 03:05:44PM +0100, Michel Thierry wrote:
> On 6/30/2015 4:16 PM, Mika Kuoppala wrote:
> >Previously we have pointed the page where the individual ppgtt
> >scratch structures refer to, to be the instance which GGTT setup have
> >allocated. So it has been shared.
> >
> >To achi
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: 2cc898e05de1d1269ecd2d4208f8e890b4f8adad
commit: 3b7e4f82f3600c2251ea3411052419b7351addd2 [318/324] drm/i915: Per-DDI
I_boost override
config: i386-randconfig-r0-201526 (attached as .config)
reproduce:
git checkout 3b7
On Wed, Jul 01, 2015 at 04:07:08PM +0200, Daniel Vetter wrote:
> On Wed, Jul 01, 2015 at 02:17:28PM +0100, Chris Wilson wrote:
> > On Wed, Jul 01, 2015 at 03:07:18PM +0200, Daniel Vetter wrote:
> > > On Wed, Jul 01, 2015 at 10:27:21AM +0100, Chris Wilson wrote:
> > > > Dave Gordon made the good sug
On Wed, Jul 01, 2015 at 03:58:50PM +0300, Jani Nikula wrote:
> Nuke three copies of the same switch case.
>
> Hopefully we can switch to a drm generic function later on, but that
> will require us to swich to enum mipi_dsi_pixel_format first.
>
> Reviewed-by: Ville Syrjälä
> Signed-off-by: Jani
On Wed, Jul 01, 2015 at 02:21:40PM +0100, Chris Wilson wrote:
> On Wed, Jul 01, 2015 at 03:19:31PM +0200, Daniel Vetter wrote:
> > On Wed, Jul 01, 2015 at 09:04:08AM +0100, Chris Wilson wrote:
> > > On Tue, Jun 30, 2015 at 04:42:00PM -0700, Rodrigo Vivi wrote:
> > > > Let's do a frontbuffer invalid
On 6/30/2015 4:16 PM, Mika Kuoppala wrote:
Previously we have pointed the page where the individual ppgtt
scratch structures refer to, to be the instance which GGTT setup have
allocated. So it has been shared.
To achive full isolation between ppgtts also in this regard,
^achieve
allo
On Wed, Jul 01, 2015 at 02:17:28PM +0100, Chris Wilson wrote:
> On Wed, Jul 01, 2015 at 03:07:18PM +0200, Daniel Vetter wrote:
> > On Wed, Jul 01, 2015 at 10:27:21AM +0100, Chris Wilson wrote:
> > > Dave Gordon made the good suggestion that once the ringbuffers were
> > > setup, the actual queuing
On Tue, Jun 30, 2015 at 06:12:59PM -0300, Paulo Zanoni wrote:
> 2015-06-30 11:34 GMT-03:00 Chris Wilson :
> > I presume that start/stop are the highest, and control the sw state. And
> > that enable/disable are just hw interaction. And who sets fbc.enabled?
> > start()? enable()? disable()? stop()?
2015-07-01 11:02 GMT-03:00 Chris Wilson :
> On Wed, Jul 01, 2015 at 04:00:23PM +0200, Daniel Vetter wrote:
>> On Tue, Jun 30, 2015 at 03:34:55PM +0100, Chris Wilson wrote:
>> > On Tue, Jun 30, 2015 at 10:53:10AM -0300, Paulo Zanoni wrote:
>> > > From: Paulo Zanoni
>> > >
>> > > Let's make sure the
On Wed, Jul 01, 2015 at 04:00:23PM +0200, Daniel Vetter wrote:
> On Tue, Jun 30, 2015 at 03:34:55PM +0100, Chris Wilson wrote:
> > On Tue, Jun 30, 2015 at 10:53:10AM -0300, Paulo Zanoni wrote:
> > > From: Paulo Zanoni
> > >
> > > Let's make sure the future Paulos don't forget that we need
> > > s
On Tue, Jun 30, 2015 at 03:34:55PM +0100, Chris Wilson wrote:
> On Tue, Jun 30, 2015 at 10:53:10AM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > Let's make sure the future Paulos don't forget that we need
> > struct_mutex when touching dev_priv->mm.stolen.
>
> As I elluded to in patc
On Tue, Jun 30, 2015 at 01:30:27PM -0700, Jesse Barnes wrote:
> On 06/30/2015 07:36 AM, Chris Wilson wrote:
> > On Tue, Jun 30, 2015 at 11:26:11AM -0300, Paulo Zanoni wrote:
> >> 2015-06-30 11:15 GMT-03:00 Chris Wilson :
> >>> On Tue, Jun 30, 2015 at 10:53:10AM -0300, Paulo Zanoni wrote:
> Fro
Mika Kuoppala writes:
> Imre Deak writes:
>
>> By running igt/store_dword_loop_render on BXT we can hit a coherency
>> problem where the seqno written at GPU command completion time is not
>> seen by the CPU. This results in __i915_wait_request seeing the stale
>> seqno and not completing the re
1 - 100 of 185 matches
Mail list logo
