On 4/23/2018 3:43 PM, Ville Syrjälä wrote:
On Mon, Apr 23, 2018 at 10:55:54AM +0530, Nautiyal, Ankit K wrote:
On 4/20/2018 7:42 PM, Ville Syrjälä wrote:
On Fri, Apr 20, 2018 at 07:01:47PM +0530, Nautiyal, Ankit K wrote:
From: Ankit Nautiyal
This patch adds helper functions for determining
On 4/23/2018 3:52 PM, Jani Nikula wrote:
On Mon, 23 Apr 2018, "Nautiyal, Ankit K" wrote:
On 4/20/2018 7:42 PM, Ville Syrjälä wrote:
On Fri, Apr 20, 2018 at 07:01:47PM +0530, Nautiyal, Ankit K wrote:
From: Ankit Nautiyal
+bool
+drm_mode_aspect_ratio_allowed(const struct drm_file *file_priv,
== Series Details ==
Series: series starting with [1/3] drm/i915/dp: Check if the sink crc we read
is 6 bytes.
URL : https://patchwork.freedesktop.org/series/42154/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4082 -> Patchwork_8783 =
== Summary - FAILURE ==
Serious un
We attempt to read 6 bytes, make sure we have.
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 62f82c4298ac..7dcc874b7d8f 100644
---
With sink-crc now being relevant only for PSR static frames, move the
code to intel_psr.c and rename the function.
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/intel_dp.c | 35 ---
drivers/gpu/drm/i
Sink crc is calculated by the sink for static frames irrespective of
what the driver sets in TEST_SINK_START dpcd. Since PSR is the only use
case for sink crc, we don't really need the sink_crc_{start, stop} code.
The second problem with the current implementation is vblank waits.
Enabling vblank
== Series Details ==
Series: drm/i915: Build request info on stack before printk (rev2)
URL : https://patchwork.freedesktop.org/series/42150/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4082_full -> Patchwork_8781_full =
== Summary - WARNING ==
Minor unknown changes co
== Series Details ==
Series: drm/i915: Don't dump umpteen thousand requests
URL : https://patchwork.freedesktop.org/series/42151/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4082 -> Patchwork_8782 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_
== Series Details ==
Series: drm/i915: Build request info on stack before printk (rev2)
URL : https://patchwork.freedesktop.org/series/42150/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4082 -> Patchwork_8781 =
== Summary - SUCCESS ==
No regressions found.
External
Quoting Chris Wilson (2018-04-24 02:08:39)
> printk unhelpfully inserts a '\n' between consecutive calls, and since
> our drm_printf wrapper may be emitting info a seq_file instead,
> KERN_CONT is not an option. To work with any drm_printf destination, we
> need to build up the output into a tempor
If we have more than a few, possibly several thousand request in the
queue, don't show the central portion, just the first few and the last
being executed and/or queued. The first few should be enough to help
identify a problem in execution, and most often comparing the first/last
in the queue is e
printk unhelpfully inserts a '\n' between consecutive calls, and since
our drm_printf wrapper may be emitting info a seq_file instead,
KERN_CONT is not an option. To work with any drm_printf destination, we
need to build up the output into a temporary buf on the stack and then
feed the complete lin
printk unhelpfully inserts a '\n' between consecutive calls, and since
our drm_printf wrapper may be emitting info a seq_file instead,
KERN_CONT is not an option. To work with any drm_printf destination, we
need to build up the output into a temporary buf on the stack and then
feed the complete lin
On Fri, 2018-04-20 at 15:57 -0700, Rodrigo Vivi wrote:
> On Fri, Apr 20, 2018 at 03:27:56PM -0700, José Roberto de Souza
> wrote:
> > Any write in any display register was causing HW to exit PSR,
> > masking it to allow more power savings. Writes to pipe related
> > registers will still cause HW to
== Series Details ==
Series: series starting with [v2,1/6] drm/i915: Stop tracking
timeline->inflight_seqnos (rev2)
URL : https://patchwork.freedesktop.org/series/42139/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4082 -> Patchwork_8780 =
== Summary - FAILURE ==
Serio
== Series Details ==
Series: series starting with [v2,1/6] drm/i915: Stop tracking
timeline->inflight_seqnos (rev2)
URL : https://patchwork.freedesktop.org/series/42139/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Stop tracking timeline->inflight_seqnos
-O:driv
== Series Details ==
Series: drm/i915/kbl: Add KBL GT2 sku (rev2)
URL : https://patchwork.freedesktop.org/series/42144/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4081_full -> Patchwork_8779_full =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_
== Series Details ==
Series: series starting with [v2,1/6] drm/i915: Stop tracking
timeline->inflight_seqnos (rev2)
URL : https://patchwork.freedesktop.org/series/42139/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
84a91bc19416 drm/i915: Stop tracking timeline->inflight_seqno
In the existing ABI, each engine operates its own timeline
(fence.context) and so should execute independently of any other. If we
install a blocker on all other engines, that should not affect execution
on the local engine.
v2: Move the requirements checks from the fixture to subtest so that
the
We need to move to a more flexible timeline that doesn't assume one
fence context per engine, and so allow for a single timeline to be used
across a combination of engines. This means that preallocating a fence
context per engine is now a hindrance, and so we want to introduce the
singular timeline
On Mon, Apr 23, 2018 at 03:28:03PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> Adding a missing GT2 sku discovered off hardware.
>
> Signed-off-by: Matt Atwood
> Reviewed-by: Clint Taylor
pushed to dinq, thanks for patch and review.
> ---
> include/drm/i915_pciids.h | 1
== Series Details ==
Series: drm/i915/kbl: Add KBL GT2 sku (rev2)
URL : https://patchwork.freedesktop.org/series/42144/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4081 -> Patchwork_8779 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwor
== Series Details ==
Series: drm/i915/kbl: Add KBL GT2 sku
URL : https://patchwork.freedesktop.org/series/42144/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4081 -> Patchwork_8778 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freed
From: Matt Atwood
Adding a missing GT2 sku discovered off hardware.
Signed-off-by: Matt Atwood
Reviewed-by: Clint Taylor
---
include/drm/i915_pciids.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 70f0c25..bab70ff 100644
--- a/
On 04/23/2018 03:01 PM, matthew.s.atw...@intel.com wrote:
From: Matt Atwood
Adding a missing GT2 sku discovered off hardware.
Signed-off-by: Matt Atwood
---
include/drm/i915_pciids.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
From: Matt Atwood
Adding a missing GT2 sku discovered off hardware.
Signed-off-by: Matt Atwood
---
include/drm/i915_pciids.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 70f0c25..a58a548 100644
--- a/include/drm/i915_pciids.h
+
Hi
I have a secondary monitor connected via USB-C adapter to HDMI. It
can manage resolutions up to 2560x1440.
Most of the time, when the system is booted the resolution is detected
ok, but If I suspend the machine, or replug the screen, or alternate
to the text console, the resolution is "downgr
Sorry, I added a debug patch when submitting to trybot and forgot to
remove that from my local branch. I will resubmit to a new series.
Yunwei
On 4/23/2018 12:55 PM, Rodrigo Vivi wrote:
On Mon, Apr 23, 2018 at 09:12:46AM -0700, Yunwei Zhang wrote:
L3Bank could be fused off in hardware for de
== Series Details ==
Series: series starting with [v2,1/6] drm/i915: Stop tracking
timeline->inflight_seqnos
URL : https://patchwork.freedesktop.org/series/42139/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4081 -> Patchwork_8777 =
== Summary - FAILURE ==
Serious unkn
In the existing ABI, each engine operates its own timeline
(fence.context) and so should execute independently of any other. If we
install a blocker on all other engines, that should not affect execution
on the local engine.
v2: Move the requirements checks from the fixture to subtest so that
the
== Series Details ==
Series: series starting with [v2,1/6] drm/i915: Stop tracking
timeline->inflight_seqnos
URL : https://patchwork.freedesktop.org/series/42139/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Stop tracking timeline->inflight_seqnos
-O:drivers/gpu
== Series Details ==
Series: series starting with [v2,1/6] drm/i915: Stop tracking
timeline->inflight_seqnos
URL : https://patchwork.freedesktop.org/series/42139/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
397f93096828 drm/i915: Stop tracking timeline->inflight_seqnos
-:17:
On Mon, Apr 23, 2018 at 01:24:39PM -0700, Dhinakaran Pandiyan wrote:
>
>
>
> On Mon, 2018-04-23 at 12:34 -0700, Rodrigo Vivi wrote:
> > On Mon, Apr 23, 2018 at 12:21:39PM -0700, Dhinakaran Pandiyan wrote:
> > >
> > >
> > >
> > > On Fri, 2018-04-20 at 14:15 +0300, Mika Kahola wrote:
> > > > On
On Mon, 2018-04-23 at 12:34 -0700, Rodrigo Vivi wrote:
> On Mon, Apr 23, 2018 at 12:21:39PM -0700, Dhinakaran Pandiyan wrote:
> >
> >
> >
> > On Fri, 2018-04-20 at 14:15 +0300, Mika Kahola wrote:
> > > On Fri, 2018-04-20 at 11:22 +0300, Jani Nikula wrote:
> > > > On Fri, 20 Apr 2018, Mika Kah
On Mon, Apr 23, 2018 at 09:12:46AM -0700, Yunwei Zhang wrote:
> L3Bank could be fused off in hardware for debug purpose, and it
> is possible that subslice is enabled while its corresponding L3Bank pairs
> are disabled. In such case, if MCR packet control register(0xFDC) is
> programed to point to
On Mon, Apr 23, 2018 at 12:21:39PM -0700, Dhinakaran Pandiyan wrote:
>
>
>
> On Fri, 2018-04-20 at 14:15 +0300, Mika Kahola wrote:
> > On Fri, 2018-04-20 at 11:22 +0300, Jani Nikula wrote:
> > > On Fri, 20 Apr 2018, Mika Kahola wrote:
> > > >
> > > > On Thu, 2018-04-19 at 17:09 +0300, Jani Nik
On Fri, 2018-04-20 at 14:15 +0300, Mika Kahola wrote:
> On Fri, 2018-04-20 at 11:22 +0300, Jani Nikula wrote:
> > On Fri, 20 Apr 2018, Mika Kahola wrote:
> > >
> > > On Thu, 2018-04-19 at 17:09 +0300, Jani Nikula wrote:
> > > >
> > > > On Wed, 18 Apr 2018, Mika Kahola wrote:
> > > > >
> > >
== Series Details ==
Series: series starting with [v2,1/6] drm/i915: Stop tracking
timeline->inflight_seqnos
URL : https://patchwork.freedesktop.org/series/42139/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4079 -> Patchwork_8776 =
== Summary - FAILURE ==
Serious unkn
== Series Details ==
Series: series starting with [v2,1/6] drm/i915: Stop tracking
timeline->inflight_seqnos
URL : https://patchwork.freedesktop.org/series/42139/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Stop tracking timeline->inflight_seqnos
-O:drivers/gpu
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Use ktime on wait_for
URL : https://patchwork.freedesktop.org/series/42115/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4078_full -> Patchwork_8774_full =
== Summary - WARNING ==
Minor unknown changes
== Series Details ==
Series: series starting with [v2,1/6] drm/i915: Stop tracking
timeline->inflight_seqnos
URL : https://patchwork.freedesktop.org/series/42139/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b1a184759165 drm/i915: Stop tracking timeline->inflight_seqnos
-:17:
== Series Details ==
Series: drm/i915: Remove src adjustment in intel_check_sprite_plane.
URL : https://patchwork.freedesktop.org/series/42113/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4078_full -> Patchwork_8773_full =
== Summary - WARNING ==
Minor unknown changes
== Series Details ==
Series: drm/hisilicon/hibmc: Using module_pci_driver.
URL : https://patchwork.freedesktop.org/series/42103/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4078_full -> Patchwork_8771_full =
== Summary - WARNING ==
Minor unknown changes coming with Pat
In the future, we want to move a request between engines. To achieve
this, we first realise that we have two timelines in effect here. The
first runs through the GTT is required for ordering vma access, which is
tracked currently by engine. The second is implied by sequential
execution of commands
In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the ring now
occurs along multiple engines), leading to much hilarity in miscomputing
the pos
In commit 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine"), we
moved from a global inflight counter to per-engine counters in the
hope that will be easy to run concurrently in future. However, with the
advent of the desire to move requests between engines, we do need a
global counter to pr
We need to move to a more flexible timeline that doesn't assume one
fence context per engine, and so allow for a single timeline to be used
across a combination of engines. This means that preallocating a fence
context per engine is now a hindrance, and so we want to introduce the
singular timeline
When userspace is passing around swapbuffers using DRI, we frequently
have to open and close the same object in the foreign address space.
This shows itself as the same object being rebound at roughly 30fps
(with a second object also being rebound at 30fps), which involves us
having to rewrite the
We don't need to track every ring for its lifetime as they are managed
by the contexts/engines. What we do want to track are the live rings so
that we can sporadically clean up requests if userspace falls behind. We
can simply restrict the gt->rings list to being only gt->live_rings.
v2: s/live/ac
Quoting Tvrtko Ursulin (2018-04-23 17:52:54)
>
> On 23/04/2018 14:43, Chris Wilson wrote:
> > In the existing ABI, each engine operates its own timeline
> > (fence.context) and so should execute independently of any other. If we
> > install a blocker on all other engines, that should not affect ex
On 23/04/2018 14:43, Chris Wilson wrote:
In the existing ABI, each engine operates its own timeline
(fence.context) and so should execute independently of any other. If we
install a blocker on all other engines, that should not affect execution
on the local engine.
Signed-off-by: Chris Wilson
L3Bank could be fused off in hardware for debug purpose, and it
is possible that subslice is enabled while its corresponding L3Bank pairs
are disabled. In such case, if MCR packet control register(0xFDC) is
programed to point to a disabled bank pair, a MMIO read into L3Bank range
will return 0 inst
This warning just started appearing during boot on a machine I upgraded
to 4.17-rc2. The warning seems to have been there since 2015, but it
has never triggered before today.
Dave
[1.158500] fb: switching to inteldrmfb from EFI VGA
[1.159073] Console: switching to colour dummy de
Thanks! :)
On 04/23/18 18:25, Jani Nikula wrote:
On Mon, 23 Apr 2018, Zhi Wang wrote:
Hi Jani:
I picked out the patch which causes conflicts and may put it back in the
next back merge from drm-intel-next to gvt-next. So there shouldn't be
any conflict in this pull. Thanks for your efforts.
On 23/04/18 08:51, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-04-23 16:37:17)
On 23/04/18 06:43, Chris Wilson wrote:
In the existing ABI, each engine operates its own timeline
(fence.context) and so should execute independently of any other. If we
install a blocker on all other en
Quoting Antonio Argenziano (2018-04-23 16:37:17)
>
>
> On 23/04/18 06:43, Chris Wilson wrote:
> > In the existing ABI, each engine operates its own timeline
> > (fence.context) and so should execute independently of any other. If we
> > install a blocker on all other engines, that should not affe
On 23/04/18 06:43, Chris Wilson wrote:
In the existing ABI, each engine operates its own timeline
(fence.context) and so should execute independently of any other. If we
install a blocker on all other engines, that should not affect execution
on the local engine.
Signed-off-by: Chris Wilson
C
On Mon, Apr 23, 2018 at 4:37 AM, Mika Kuoppala
wrote:
> We use jiffies to determine when wait expires. However
> Imre did find out that jiffies can and will do a >1
> increments on certain situations [1]. When this happens
> in a wait_for loop, we return timeout errorneously
> much earlier than wh
On Mon, Apr 23, 2018 at 04:39:54PM +0200, Maarten Lankhorst wrote:
> Op 23-04-18 om 16:30 schreef Ville Syrjälä:
> > On Mon, Apr 23, 2018 at 12:49:22PM +0200, Maarten Lankhorst wrote:
> >> The rounding can cause a perfectly normal 16x16 src to full-screen
> >> dst to be rounded down, even without c
Quoting Mika Kuoppala (2018-04-23 14:03:02)
> Chris Wilson writes:
> > @@ -148,6 +149,12 @@ static void intel_breadcrumbs_fake_irq(struct
> > timer_list *t)
> > if (!b->irq_armed)
> > return;
> >
> > + /* If the user has disabled the fake-irq, restore the hangchecking */
Op 23-04-18 om 16:30 schreef Ville Syrjälä:
> On Mon, Apr 23, 2018 at 12:49:22PM +0200, Maarten Lankhorst wrote:
>> The rounding can cause a perfectly normal 16x16 src to full-screen
>> dst to be rounded down, even without clipping involved. Because of
>> this we should just remove the adjustment,
On Mon, Apr 23, 2018 at 12:49:22PM +0200, Maarten Lankhorst wrote:
> The rounding can cause a perfectly normal 16x16 src to full-screen
> dst to be rounded down, even without clipping involved. Because of
> this we should just remove the adjustment, as no other driver or plane
> does it.
>
> Signe
== Series Details ==
Series: drm: Don't pass the index to drm_property_add_enum() (rev2)
URL : https://patchwork.freedesktop.org/series/40122/
State : failure
== Summary ==
Applying: drm: Don't pass the index to drm_property_add_enum()
error: patch failed: drivers/gpu/drm/drm_connector.c:1069
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Use ktime on wait_for
URL : https://patchwork.freedesktop.org/series/42115/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4078 -> Patchwork_8774 =
== Summary - SUCCESS ==
No regressions found.
Extern
== Series Details ==
Series: drm/i915: Remove src adjustment in intel_check_sprite_plane.
URL : https://patchwork.freedesktop.org/series/42113/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4078 -> Patchwork_8773 =
== Summary - SUCCESS ==
No regressions found.
Externa
On Fri, 20 Apr 2018, Paul Menzel wrote:
> Dear Jose,
>
>
> On 04/19/18 01:41, Souza, Jose wrote:
>> If the initial fbdev configuration(intel_fbdev_initial_config()) runs and
>
> Nit: Space before (.
>
>> there still no sink connected it will cause
>> drm_fb_helper_initial_config() to return 0 as n
Acked-by: Stanislav Lisovskiy
Best Regards,
Lisovskiy Stanislav
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo>
From: Ville Syrjala [ville.syrj...@linux.intel.com]
Sent: Friday, March 16, 2018 9:04 PM
To: dri-de...@lists.f
Quoting Patchwork (2018-04-23 14:40:51)
> igt@core_auth@basic-auth:
> fi-glk-j4005: PASS -> INCOMPLETE (k.org#198133, fdo#103359)
> fi-bdw-gvtdvm: PASS -> INCOMPLETE (fdo#105600)
> fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927)
> fi-cnl-psr: PASS
Ping
From: Intel-gfx [intel-gfx-boun...@lists.freedesktop.org] on behalf of StanLis
[stanislav.lisovs...@intel.com]
Sent: Monday, April 23, 2018 10:34 AM
To: dri-de...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH v7
In the existing ABI, each engine operates its own timeline
(fence.context) and so should execute independently of any other. If we
install a blocker on all other engines, that should not affect execution
on the local engine.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/gem_exec_sche
== Series Details ==
Series: series starting with [1/6] drm/i915: Stop tracking
timeline->inflight_seqnos
URL : https://patchwork.freedesktop.org/series/42111/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4078 -> Patchwork_8772 =
== Summary - FAILURE ==
Serious unknown
== Series Details ==
Series: series starting with [1/6] drm/i915: Stop tracking
timeline->inflight_seqnos
URL : https://patchwork.freedesktop.org/series/42111/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Stop tracking timeline->inflight_seqnos
-O:drivers/gpu/dr
== Series Details ==
Series: series starting with [1/6] drm/i915: Stop tracking
timeline->inflight_seqnos
URL : https://patchwork.freedesktop.org/series/42111/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cdd8eb08a9de drm/i915: Stop tracking timeline->inflight_seqnos
-:14: ER
== Series Details ==
Series: drm/hisilicon/hibmc: Using module_pci_driver.
URL : https://patchwork.freedesktop.org/series/42103/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4078 -> Patchwork_8771 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https:/
On 23/04/2018 11:14, Chris Wilson wrote:
When userspace is passing around swapbuffers using DRI, we frequently
have to open and close the same object in the foreign address space.
This shows itself as the same object being rebound at roughly 30fps
(with a second object also being rebound at 30fp
Chris Wilson writes:
> Instead of synchronously cancelling the timer and re-enabling it inside
> the reset callbacks, keep the timer enabled and let it die on its next
> wakeup if no longer required. This allows
> intel_engine_reset_breadcrumbs() to be used from an atomic
> (timer/softirq) contex
Quoting Tvrtko Ursulin (2018-04-23 13:33:04)
>
> On 23/04/2018 11:13, Chris Wilson wrote:
> > We need to move to a more flexible timeline that doesn't assume one
> > fence context per engine, and so allow for a single timeline to be used
> > across a combination of engines. This means that preallo
Quoting Tvrtko Ursulin (2018-04-23 11:44:19)
>
> On 23/04/2018 11:13, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 0097a77fae8d..1635975dbc16 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i91
On 23/04/2018 11:13, Chris Wilson wrote:
We need to move to a more flexible timeline that doesn't assume one
fence context per engine, and so allow for a single timeline to be used
across a combination of engines. This means that preallocating a fence
context per engine is now a hindrance, and s
Ping?
>Понедельник, 9 апреля 2018, 15:26 +03:00 от Tvrtko Ursulin
>:
>
>
>[Adding some people to Cc for more ack/nack type feedback.]
>
>Executive question is ack or nack on replacing intel_gpu_top with a new
>implementation which uses only perf PMU for counter gathering.
>
>A short history on
We use jiffies to determine when wait expires. However
Imre did find out that jiffies can and will do a >1
increments on certain situations [1]. When this happens
in a wait_for loop, we return timeout errorneously
much earlier than what the real wallclock would say.
We can't afford our waits to ti
We need to be careful to not let compiler evaluate
the expiration and the operation on it's terms.
Document and enforce that COND will be evaluated
before checking timeout expiration.
Suggested-by: Chris Wilson
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drive
On 23/04/2018 11:36, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-23 11:25:54)
On 23/04/2018 11:13, Chris Wilson wrote:
We don't need to track every ring for its lifetime as they are managed
by the contexts/engines. What we do want to track are the live rings so
that we can sporadicall
The rounding can cause a perfectly normal 16x16 src to full-screen
dst to be rounded down, even without clipping involved. Because of
this we should just remove the adjustment, as no other driver or plane
does it.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_sprite.c | 5 -
On 23/04/2018 11:13, Chris Wilson wrote:
In the future, we want to move a request between engines. To achieve
this, we first realise that we have two timelines in effect here. The
first runs through the GTT is required for ordering vma access, which is
tracked currently by engine. The second is
Quoting Tvrtko Ursulin (2018-04-23 11:25:54)
>
> On 23/04/2018 11:13, Chris Wilson wrote:
> > We don't need to track every ring for its lifetime as they are managed
> > by the contexts/engines. What we do want to track are the live rings so
> > that we can sporadically clean up requests if userspa
On 23/04/2018 11:13, Chris Wilson wrote:
We don't need to track every ring for its lifetime as they are managed
by the contexts/engines. What we do want to track are the live rings so
that we can sporadically clean up requests if userspace falls behind. We
can simply restrict the gt->rings list
On Mon, 23 Apr 2018, Zhi Wang wrote:
> Hi Jani:
>
> I picked out the patch which causes conflicts and may put it back in the
> next back merge from drm-intel-next to gvt-next. So there shouldn't be
> any conflict in this pull. Thanks for your efforts.
Thanks, pulled to drm-intel-next-queued.
J
On 23/04/2018 11:13, Chris Wilson wrote:
In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the ring now
occurs along multiple engines), lead
On Mon, 23 Apr 2018, "Nautiyal, Ankit K" wrote:
> On 4/20/2018 7:42 PM, Ville Syrjälä wrote:
>> On Fri, Apr 20, 2018 at 07:01:47PM +0530, Nautiyal, Ankit K wrote:
>>> From: Ankit Nautiyal
>>> +bool
>>> +drm_mode_aspect_ratio_allowed(const struct drm_file *file_priv,
>>> +
On Mon, Apr 23, 2018 at 11:19:08AM +0530, Nautiyal, Ankit K wrote:
>
>
> On 4/20/2018 7:52 PM, Ville Syrjälä wrote:
> > On Fri, Apr 20, 2018 at 07:01:49PM +0530, Nautiyal, Ankit K wrote:
> >> From: Ankit Nautiyal
> >>
> >> We parse the EDID and add all the modes in the connector's modelist.
> >>
In the future, we want to move a request between engines. To achieve
this, we first realise that we have two timelines in effect here. The
first runs through the GTT is required for ordering vma access, which is
tracked currently by engine. The second is implied by sequential
execution of commands
On 23/04/2018 10:06, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-23 09:47:57)
On 20/04/2018 14:20, Chris Wilson wrote:
void i915_retire_requests(struct drm_i915_private *i915)
{
- struct intel_engine_cs *engine;
- enum intel_engine_id id;
+ struct intel_ring *ring,
We don't need to track every ring for its lifetime as they are managed
by the contexts/engines. What we do want to track are the live rings so
that we can sporadically clean up requests if userspace falls behind. We
can simply restrict the gt->rings list to being only gt->live_rings.
Suggested-by:
We need to move to a more flexible timeline that doesn't assume one
fence context per engine, and so allow for a single timeline to be used
across a combination of engines. This means that preallocating a fence
context per engine is now a hindrance, and so we want to introduce the
singular timeline
When userspace is passing around swapbuffers using DRI, we frequently
have to open and close the same object in the foreign address space.
This shows itself as the same object being rebound at roughly 30fps
(with a second object also being rebound at 30fps), which involves us
having to rewrite the
In commit 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine"), we
moved from a global inflight counter to per-engine counters in the
hope that will be easy to run concurrently in future. However, with the
advent of the desire to move requests between engines, we do need a
global counter to pr
In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the ring now
occurs along multiple engines), leading to much hilarity in miscomputing
the pos
On Mon, Apr 23, 2018 at 10:55:54AM +0530, Nautiyal, Ankit K wrote:
>
>
> On 4/20/2018 7:42 PM, Ville Syrjälä wrote:
> > On Fri, Apr 20, 2018 at 07:01:47PM +0530, Nautiyal, Ankit K wrote:
> >> From: Ankit Nautiyal
> >>
> >> This patch adds helper functions for determining if aspect-ratio is
> >>
On Mon, Apr 23, 2018 at 10:43:47AM +0530, Nautiyal, Ankit K wrote:
>
>
> On 4/20/2018 7:37 PM, Ville Syrjälä wrote:
> > On Fri, Apr 20, 2018 at 07:01:46PM +0530, Nautiyal, Ankit K wrote:
> >> From: Ankit Nautiyal
> >>
> >> To enable aspect-ratio support in DRM, blindly exposing the aspect
> >> r
1 - 100 of 120 matches
Mail list logo
