Hi Lionel,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[cannot apply to v5.3-rc8 next-20190904]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
On 09/09/2019 10:23, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-09-09 10:19:08)
On 09/09/2019 08:12, Chris Wilson wrote:
And give up if we never even make it to the start.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111592
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
On 09/09/2019 08:12, Chris Wilson wrote:
And give up if we never even make it to the start.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111592
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/perf_pmu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
We'll use this information later to verify that a client trying to
reconfigure the stream does so on the right engine.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/i915_perf.c | 7 +++
2 files changed, 12 insertions(+)
diff --git
Here we introduce a mechanism by which the execbuf part of the i915
driver will be able to request that a batch buffer containing the
programming for a particular OA config be created.
We'll execute these OA configuration buffers right before executing a
set of userspace commands so that a
Introduces a new parameters to execbuf so that we can specify syncobj
handles as well as timeline points.
v2: Reuse i915_user_extension_fn
v3: Check that the chained extension is only present once (Chris)
v4: Check that dma_fence_chain_find_seqno returns a non NULL fence (Lionel)
v5: Use
An upcoming change needs not to be interrupted.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_active.c | 4 +++-
drivers/gpu/drm/i915/i915_active.h | 5 ++---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
We haven't run into issues with programming the global OA/NOA
registers configuration from CPU so far, but HW engineers actually
recommend doing this from the command streamer. On TGL in particular
one of the clock domain in which some of that programming goes might
not be powered when we poke
We're planning to use this for a couple of new feature where we need
to provide additional parameters to execbuf.
v2: Check for invalid flags in execbuffer2 (Lionel)
v3: Rename I915_EXEC_EXT -> I915_EXEC_USE_EXTENSIONS (Chris)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson (v1)
At some point in time there was the idea that we could have multiple
stream from the same piece of HW but that never materialized and given
the hard time we already have making everything work with the
submission side, there is no real point having this list of 1 element
around.
Signed-off-by:
Reporting this version will help application figure out what level of
the support the running kernel provides.
v2: Add i915_perf_ioctl_version() (Chris)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_getparam.c | 4
Following a pattern used throughout the driver.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h| 300 +-
drivers/gpu/drm/i915/i915_perf.h | 2 +
drivers/gpu/drm/i915/i915_perf_types.h | 328 +
3 files changed, 331
At some point in time there was the idea that we could have multiple
stream from the same piece of HW but that never materialized and given
the hard time we already have making everything work with the
submission side, there is no real point having this list of 1 element
around.
Signed-off-by:
Following a pattern used throughout the driver.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h| 300 +-
drivers/gpu/drm/i915/i915_perf.h | 2 +
drivers/gpu/drm/i915/i915_perf_types.h | 328 +
3 files changed, 331
We want the ability to dispatch a set of command buffer to the
hardware, each with a different OA configuration. To achieve this, we
reuse a couple of fields from the execbuf2 struct (I CAN HAZ
execbuf3?) to notify what OA configuration should be used for a batch
buffer. This requires the process
Reporting this version will help application figure out what level of
the support the running kernel provides.
v2: Add i915_perf_ioctl_version() (Chris)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_getparam.c | 4
Introduces a new parameters to execbuf so that we can specify syncobj
handles as well as timeline points.
v2: Reuse i915_user_extension_fn
v3: Check that the chained extension is only present once (Chris)
v4: Check that dma_fence_chain_find_seqno returns a non NULL fence (Lionel)
v5: Use
Here we introduce a mechanism by which the execbuf part of the i915
driver will be able to request that a batch buffer containing the
programming for a particular OA config be created.
We'll execute these OA configuration buffers right before executing a
set of userspace commands so that a
We'll use this information later to verify that a client trying to
reconfigure the stream does so on the right engine.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/i915_perf.c | 7 +++
2 files changed, 12 insertions(+)
diff --git
NOA configuration take some amount of time to apply. That amount of
time depends on the size of the GT. There is no documented time for
this. For example, past experimentations with powergating
configuration changes seem to indicate a 60~70us delay. We go with
500us as default for now which should
We haven't run into issues with programming the global OA/NOA
registers configuration from CPU so far, but HW engineers actually
recommend doing this from the command streamer. On TGL in particular
one of the clock domain in which some of that programming goes might
not be powered when we poke
We're planning to use this for a couple of new feature where we need
to provide additional parameters to execbuf.
v2: Check for invalid flags in execbuffer2 (Lionel)
v3: Rename I915_EXEC_EXT -> I915_EXEC_USE_EXTENSIONS (Chris)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson (v1)
Listing configurations at the moment is supported only through sysfs.
This might cause issues for applications wanting to list
configurations from a container where sysfs isn't available.
This change adds a way to query the number of configurations and their
content through the i915 query uAPI.
An upcoming change needs not to be interrupted.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_active.c | 4 +++-
drivers/gpu/drm/i915/i915_active.h | 5 ++---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
We would like to make use of perf in Vulkan. The Vulkan API is much
lower level than OpenGL, with applications directly exposed to the
concept of command buffers (pretty much equivalent to our batch
buffers). In Vulkan, queries are always limited in scope to a command
buffer. In OpenGL, the lack
And give up if we never even make it to the start.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111592
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/perf_pmu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index
== Series Details ==
Series: series starting with [CI,01/13] drm/i915: introduce a mechanism to
extend execbuf2
URL : https://patchwork.freedesktop.org/series/66418/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
66b565b57b3f drm/i915: introduce a mechanism to extend execbuf2
On Sat, Sep 07, 2019 at 07:12:56PM +0100, Chris Wilson wrote:
> The curse of using libigt where it is not wanted; in this case calling
> drop-caches while we hold the forcewake is a recipe for a long wait.
>
> Signed-off-by: Chris Wilson
For the series:
Reviewed-by: Petri Latvala
> ---
>
== Series Details ==
Series: series starting with [CI,01/13] drm/i915: introduce a mechanism to
extend execbuf2
URL : https://patchwork.freedesktop.org/series/66406/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
We would like to make use of perf in Vulkan. The Vulkan API is much
lower level than OpenGL, with applications directly exposed to the
concept of command buffers (pretty much equivalent to our batch
buffers). In Vulkan, queries are always limited in scope to a command
buffer. In OpenGL, the lack
NOA configuration take some amount of time to apply. That amount of
time depends on the size of the GT. There is no documented time for
this. For example, past experimentations with powergating
configuration changes seem to indicate a 60~70us delay. We go with
500us as default for now which should
We want the ability to dispatch a set of command buffer to the
hardware, each with a different OA configuration. To achieve this, we
reuse a couple of fields from the execbuf2 struct (I CAN HAZ
execbuf3?) to notify what OA configuration should be used for a batch
buffer. This requires the process
Listing configurations at the moment is supported only through sysfs.
This might cause issues for applications wanting to list
configurations from a container where sysfs isn't available.
This change adds a way to query the number of configurations and their
content through the i915 query uAPI.
Quoting Tvrtko Ursulin (2019-09-09 10:19:08)
>
> On 09/09/2019 08:12, Chris Wilson wrote:
> > And give up if we never even make it to the start.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111592
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> >
== Series Details ==
Series: series starting with [CI,01/13] drm/i915: introduce a mechanism to
extend execbuf2
URL : https://patchwork.freedesktop.org/series/66418/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: introduce a mechanism to
Being a "low-level" test, we opt to bypass the normal bind/unbind hooks
for the lower level insert_entries/clear_range. For ggtt, the
bind/unbind hooks provide the runtime wakeref and so we must also handle
this in exercising the low level hooks.
<4> [538.151672] RPM raw-wakeref not held
<4>
Other than Broadwell being fubar (and Ironlake + g4x being special in
their own way), there appears to be little fallout from enabling iommu.
(The biggest open question is over performance, TLB misses are much more
expensive and that impacts meda/CL/GL throughput.) Enabling iommu/dmar
makes our CI
Currently, if there is time remaining before the start of the loop, we
do one full iteration over many possible different chunks within the
object. A full loop may take 50+s (depending on speed of indirect GTT
mmapings) and we try separately with LINEAR, X and Y -- at which point
igt times out. If
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig.debug | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 00786a142ff0..ebcb6dbc2393 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++
Despite the widespread and complete failure of Broadwell integrated
graphics when DMAR is enabled, known over the years, we have never been
able to root cause the issue. Instead, we let the failure undermine our
confidence in the iommu system itself when we should be pushing for it to
be always
As soon as we re-enable the various functions within the HW, they may go
off and read data via a GGTT offset. Hence, if we have not yet restored
the GGTT PTE before then, they may read and even *write* random locations
in memory.
Detected by DMAR faults during resume.
Signed-off-by: Chris Wilson
---
drivers/iommu/intel-iommu.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 34f6a3d93ae2..c98cdfd91691 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -439,8 +439,6 @@ static int __init
We wish to avoid our presentation worker from being blocked by normal
workloads if we want to maintain an interactive frame update.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Heinrich Fink
---
drivers/gpu/drm/i915/display/intel_display.c | 3 ++-
1 file changed, 2 insertions(+), 1
For i965, add hw read out to create hw blob of gamma
lut values.
Review comments from old series:
https://patchwork.freedesktop.org/series/58039/
v4: -No need to initialize *blob [Jani]
-Removed right shifts [Jani]
-Dropped dev local var [Jani]
v5: -Returned blob instead of assigning
intel_color_get_gamma_bit_precision() is extended for
cherryview by adding chv_gamma_precision(), i965 will use existing
i9xx_gamma_precision() func only.
Signed-off-by: Swati Sharma
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_color.c | 25 +++--
1 file
For cherryview, add hw read out to create hw blob of gamma
lut values.
Review comments from previous series:
https://patchwork.freedesktop.org/patch/328252
v4: -No need to initialize *blob [Jani]
-Removed right shifts [Jani]
-Dropped dev local var [Jani]
v5: -Returned blob instead of
In this patch series, added state checker to validate gamma lut values
for cherryview and i965 platforms. It's extension of the
patch series https://patchwork.freedesktop.org/patch/328246/?series=58039
which enabled the basic infrastructure and state checker for
few legacy platforms.
v2: Added
On 9/7/2019 4:37 PM, Animesh Manna wrote:
DSB can program large set of data through indexed register write
(opcode 0x9) in one shot. DSB feature can be used for bulk register
programming e.g. gamma lut programming, HDR meta data programming.
v1: initial version.
v2: simplified code by using
On 9/7/2019 4:37 PM, Animesh Manna wrote:
Batch buffer will be created through dsb-reg-write function which can have
single/multiple request based on usecase and once the buffer is ready
commit function will trigger the execution of the batch buffer. All
the registers will be updated
== Series Details ==
Series: series starting with [1/2] drm/i915: Show the logical context ring
state on dumping
URL : https://patchwork.freedesktop.org/series/66422/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6853 -> Patchwork_14323
‐‐‐ Original Message ‐‐‐
On Monday, September 9, 2019 10:38 AM, wrote:
> With commit aa56a292ce623734ddd30f52d73f527d1f3529b5 (even on 5.3.0-rc8) I
> can get a system freeze during chromium compilation (likely due to jumbo /
> high memory usage). Sysrq still works and CPU/fan is low,
Be paranoid and make sure we flush any and all writes out of the WCB
before performing the UC mmio to update the RING_TAIL. (An UC write
should itself be enough to do the flush, hence the paranoia here.) Quite
infrequently, we see problems where the GPU seems to overshoot the
RING_TAIL and so
== Series Details ==
Series: series starting with [CI,01/13] drm/i915: introduce a mechanism to
extend execbuf2
URL : https://patchwork.freedesktop.org/series/66418/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6852_full -> Patchwork_14322_full
On 9/7/2019 4:37 PM, Animesh Manna wrote:
DSB support single register write through opcode 0x1. Generic
api created which accumulate all single register write in a batch
buffer and once DSB is triggered, it will program all the registers
at the same time.
v1: Initial version.
v2: Unused macro
Quoting Matthew Auld (2019-09-09 13:40:52)
> Try to tidy up the cache-coloring such that we rid the code of any
> mm.color_adjust assumptions, this should hopefully make it more obvious
> in the code when we need to actually use the cache-level as the color,
> and as a bonus should make adding a
Quoting Prathap Kumar Valsan (2019-08-26 01:48:01)
> To provide shared last-level-cache isolation to cpu workloads running
> concurrently with gpu workloads, the gpu allocation of cache lines needs
> to be restricted to certain ways. Currently GPU hardware supports four
> class-of-service(CLOS)
Quoting Tvrtko Ursulin (2019-09-09 11:23:56)
>
> On 07/09/2019 11:50, Chris Wilson wrote:
> > As we may unwind incomplete requests (for preemption) prior to
> > processing the CSB and the schedule-out events, we may update rq->engine
> > (resetting it to point back to the parent virtual engine)
== Series Details ==
Series: series starting with [1/2] drm/i915: Show the logical context ring
state on dumping
URL : https://patchwork.freedesktop.org/series/66422/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3f29fa89a00e drm/i915: Show the logical context ring state on
On 07/09/2019 11:50, Chris Wilson wrote:
As we may unwind incomplete requests (for preemption) prior to
processing the CSB and the schedule-out events, we may update rq->engine
(resetting it to point back to the parent virtual engine) prior to
calling execlists_schedule_out(), invalidating the
With commit aa56a292ce623734ddd30f52d73f527d1f3529b5 (even on 5.3.0-rc8) I can
get a system freeze during chromium compilation (likely due to jumbo / high
memory usage). Sysrq still works and CPU/fan is low, so it seems like a
deadlock? and there's no disk reading. I can't read the dump gotten
On 9/7/2019 4:37 PM, Animesh Manna wrote:
As per bspec check for DSB status before programming any
of its register. Inline function added to check the dsb status.
Cc: Michel Thierry
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
On 9/7/2019 4:37 PM, Animesh Manna wrote:
DSB will be used for performance improvement for some special scenario.
DSB engine will be enabled based on need and after completion of its work
will be disabled. Api added for enable/disable operation by using DSB_CTRL
register.
v1: Initial version.
On 9/7/2019 4:37 PM, Animesh Manna wrote:
The lifetime of command buffer can be controlled by the dsb user
throuh refcount. Added refcount mechanism is dsb get/put call
which create/destroy dsb context.
Cc: Jani Nikula
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
On Sat, Sep 07, 2019 at 11:19:55PM +, Mun, Gwan-gyeong wrote:
> On Fri, 2019-09-06 at 09:24 -0400, Ilia Mirkin wrote:
> > On Fri, Sep 6, 2019 at 7:43 AM Ville Syrjälä
> > wrote:
> > > On Fri, Sep 06, 2019 at 11:31:55AM +, Shankar, Uma wrote:
> > > >
> > > > > -Original Message-
>
Make it clear that the color adjust callback applies to the ggtt.
Signed-off-by: Matthew Auld
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 10 +-
drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 2 +-
2 files changed, 6
Try to tidy up the cache-coloring such that we rid the code of any
mm.color_adjust assumptions, this should hopefully make it more obvious
in the code when we need to actually use the cache-level as the color,
and as a bonus should make adding a different color-scheme simpler.
Signed-off-by:
Export color_differs so that we can use it elsewhere.
Signed-off-by: Matthew Auld
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 11 ---
drivers/gpu/drm/i915/i915_vma.h | 6 ++
3
On 9/7/2019 4:37 PM, Animesh Manna wrote:
This patch adds a function, which will internally get the gem buffer
for DSB engine. The GEM buffer is from global GTT, and is mapped into
CPU domain, contains the data + opcode to be feed to DSB engine.
v1: Initial version.
v2:
- removed some
== Series Details ==
Series: drm/i915/display: Mark the modesetting wq as WQ_HIGHPRI
URL : https://patchwork.freedesktop.org/series/66439/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6854_full -> Patchwork_14330_full
On Fri, 2019-09-06 at 19:13 +0100, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-09-02 14:42:44)
> >
> > On 24/07/2019 14:05, Tvrtko Ursulin wrote:
> > >
> > > On 23/07/2019 16:49, Stuart Summers wrote:
> > > > +u32 intel_sseu_get_subslices(const struct sseu_dev_info *sseu,
> > > > u8
On 9/7/19 1:39 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-09-06 23:28:05)
On 9/5/19 2:09 AM, Janusz Krzysztofik wrote:
When trying to reset a device with reset capability disabled or not
supported while rings are full of requests, it has been observed when
running in
On 9/9/2019 6:28 PM, Sharma, Shashank wrote:
On 9/7/2019 4:37 PM, Animesh Manna wrote:
DSB support single register write through opcode 0x1. Generic
api created which accumulate all single register write in a batch
buffer and once DSB is triggered, it will program all the registers
at the
It might prove useful in the future to know if the vma is utilising
huge-GTT-pages. Related to this is the GTT cache, where there is some HW
"quirkiness" where it must be disabled if using 2M pages, so include
that for good measure.
Suggested-by: Chris Wilson
Signed-off-by: Matthew Auld
Cc:
== Series Details ==
Series: series starting with [CI,01/13] drm/i915: introduce a mechanism to
extend execbuf2
URL : https://patchwork.freedesktop.org/series/66418/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6852 -> Patchwork_14322
We'll use this information later to verify that a client trying to
reconfigure the stream does so on the right engine.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/i915_perf.c | 7 +++
2 files changed, 12 insertions(+)
diff --git
An upcoming change needs not to be interrupted.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_active.c | 4 +++-
drivers/gpu/drm/i915/i915_active.h | 5 ++---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
NOA configuration take some amount of time to apply. That amount of
time depends on the size of the GT. There is no documented time for
this. For example, past experimentations with powergating
configuration changes seem to indicate a 60~70us delay. We go with
500us as default for now which should
Before we submit the first context to HW, we need to construct a valid
image of the register state. This layout is defined by the HW and should
match the layout generated by HW when it saves the context image.
Asserting that this should be equivalent should help avoid any undefined
behaviour and
Reporting this version will help application figure out what level of
the support the running kernel provides.
v2: Add i915_perf_ioctl_version() (Chris)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_getparam.c | 4
Listing configurations at the moment is supported only through sysfs.
This might cause issues for applications wanting to list
configurations from a container where sysfs isn't available.
This change adds a way to query the number of configurations and their
content through the i915 query uAPI.
Here we introduce a mechanism by which the execbuf part of the i915
driver will be able to request that a batch buffer containing the
programming for a particular OA config be created.
We'll execute these OA configuration buffers right before executing a
set of userspace commands so that a
We haven't run into issues with programming the global OA/NOA
registers configuration from CPU so far, but HW engineers actually
recommend doing this from the command streamer. On TGL in particular
one of the clock domain in which some of that programming goes might
not be powered when we poke
Include the active context register state when dumping the engine.
Suggested-by: Mika Kuoppala
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
We're planning to use this for a couple of new feature where we need
to provide additional parameters to execbuf.
v2: Check for invalid flags in execbuffer2 (Lionel)
v3: Rename I915_EXEC_EXT -> I915_EXEC_USE_EXTENSIONS (Chris)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson (v1)
Following a pattern used throughout the driver.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h| 300 +--
drivers/gpu/drm/i915/i915_perf.h | 2 +
drivers/gpu/drm/i915/i915_perf_types.h | 327 +
3 files changed, 330
We would like to make use of perf in Vulkan. The Vulkan API is much
lower level than OpenGL, with applications directly exposed to the
concept of command buffers (pretty much equivalent to our batch
buffers). In Vulkan, queries are always limited in scope to a command
buffer. In OpenGL, the lack
We want the ability to dispatch a set of command buffer to the
hardware, each with a different OA configuration. To achieve this, we
reuse a couple of fields from the execbuf2 struct (I CAN HAZ
execbuf3?) to notify what OA configuration should be used for a batch
buffer. This requires the process
Hi all,
This is just a few compilation fixes only seen on CI.
Cheers,
Lionel Landwerlin (13):
drm/i915: introduce a mechanism to extend execbuf2
drm/i915: add syncobj timeline support
drm/i915/perf: drop list of streams
drm/i915/perf: store the associated engine of a stream
Introduces a new parameters to execbuf so that we can specify syncobj
handles as well as timeline points.
v2: Reuse i915_user_extension_fn
v3: Check that the chained extension is only present once (Chris)
v4: Check that dma_fence_chain_find_seqno returns a non NULL fence (Lionel)
v5: Use
At some point in time there was the idea that we could have multiple
stream from the same piece of HW but that never materialized and given
the hard time we already have making everything work with the
submission side, there is no real point having this list of 1 element
around.
Signed-off-by:
On 9/6/19 6:10 PM, Matt Roper wrote:
On Fri, Sep 06, 2019 at 03:46:42PM -0700, Daniele Ceraolo Spurio wrote:
On 9/6/19 3:41 PM, Radhakrishna Sripada wrote:
Disable CPS aware color pipe by setting chicken bit.
BSpec: 52890
HSDES: 1409142259
Cc: Stuart Summers
Cc: Matt Roper
kms_rotation_crc manually starts and stops CRC collection and reads
single CRC values when it needs them. Depending on how long the other
test setup and execution operations take, the CRC buffer (128 entries)
can fill up CRC values that the test never reads or uses. Our CI system
has stumbled
Hi guys,
On Fri, Sep 06, 2019 at 01:42:55PM +0800, Zhenyu Wang wrote:
>
> Hi,
>
> Here's gvt-next-fixes with two recent fixes, one for recent
> guest hang regression and another for guest reset fix.
>
> Thanks.
> --
> The following changes since commit c36beba6b296b3c05a0f29753b04775e5ae23886:
== Series Details ==
Series: drm/i915/ringbuffer: Flush writes before RING_TAIL update
URL : https://patchwork.freedesktop.org/series/66426/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6854 -> Patchwork_14327
Summary
== Series Details ==
Series: series starting with [1/6] drm/i915/selftests: Take runtime wakeref for
igt_ggtt_lowlevel
URL : https://patchwork.freedesktop.org/series/66425/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6854 -> Patchwork_14326
Hello,
5.2.13 is working fine (great) still with a Dell U4919DW connected via USB-C
from a X1 Carbon Gen 6.
5.3-rc8 so far is not (blank screen) and errors:
https://pastebin.com/tXFi6AfK
Seems there has been some refactoring for just this kind of connection in 5.3?
Is there perhaps and issue
== Series Details ==
Series: adding gamma state checker for CHV and i965 (rev2)
URL : https://patchwork.freedesktop.org/series/66297/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d02e018c92fe drm/i915/display: Add gamma precision function for CHV
73751624de48
Searching on the kernel warnings and errors didn't bring it up, but in browsing
bugzilla I stumbled on this.
Bug 111501 - [CFL] Kernel 5.3.0-rc6: i915 fails at typec_displayport 5120x1440
https://bugs.freedesktop.org/show_bug.cgi?id=111501
It's the same monitor and connection type.
Is the
== Series Details ==
Series: series starting with [1/3] drm/i915: export color_differs
URL : https://patchwork.freedesktop.org/series/66433/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6854 -> Patchwork_14329
Summary
/commits/Chris-Wilson/drm-i915-selftests-Take-runtime-wakeref-for-igt_ggtt_lowlevel/20190909-201355
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-s2-201936 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-11) 7.4.0
reproduce:
# save the attached
1 - 100 of 150 matches
Mail list logo
