== Summary ==
Built on 0ea9000bcb6f394edde5111494a92b0607214cfa drm-intel-nightly:
2016y-01m-15d-19h-09m-45s UTC integration manifest
Test gem_ctx_basic:
pass -> FAIL (bdw-ultra)
Test gem_storedw_loop:
Subgroup basic-render:
dmesg-warn -> PASS
On Fri, 2016-01-15 at 16:45 +0200, Jani Nikula wrote:
> Different subsystems and drivers have different preferred ways of
> receiving bug reports; mailing list or bugzillas at various
> locations. Add "B:" entry for specifying the preference to guide bug
> reporters at the right location.
[]
> diff
On Fri, Jan 15, 2016 at 08:46:53PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> On SKL+ plane scaling is mutually exclusive with color keying. The code
> check for this, but during some refactoring the code got changed to
> also reject primary plane windowing when color k
On Fri, Jan 15, 2016 at 08:48:26PM +0200, Ville Syrjälä wrote:
> On Thu, Oct 15, 2015 at 05:01:58PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Pass BIT(DRM_ROTATE_0) instead of DRM_ROTATE_0 to skl_update_scaler().
> > The former is a mask, the latter just the bit
On Thu, Jan 14, 2016 at 06:32:10PM +0200, Mika Kuoppala wrote:
> CI/Bat got following (shortened) trace on byt and also
> on bsw:
>
> [ cut here ]---
> Unclaimed register detected before reading register 0x186500
> Call Trace:
> __unclaimed_reg_debug+0x68/0x80 [i915]
> vlv_rea
On Fri, Jan 15, 2016 at 05:12:45PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> LRC lifetime is well defined so we can cache the page pointing
> to the object backing store in the context in order to avoid
> walking over the object SG page list from the interrupt context
> without the
On Thu, Jan 14, 2016 at 03:22:08PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Yanked a few more prep patches from my earlier fb offsets[] work [1]. First
> few have r-bs, the rest don't.
>
> The last two patches are new. Things just tickled my OCD a bit too much so
> h
On Thu, Jan 14, 2016 at 06:37:32PM -0800, Matt Roper wrote:
> On Thu, Jan 14, 2016 at 02:53:35PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > ilk_program_watermarks() is supposed to merge the active watermarks from
> > all pipes. Thus we need to use the active confi
On Thu, Oct 15, 2015 at 05:01:58PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Pass BIT(DRM_ROTATE_0) instead of DRM_ROTATE_0 to skl_update_scaler().
> The former is a mask, the latter just the bit number.
>
> Fortunately the only thing skl_update_scaler() does with the
From: Ville Syrjälä
On SKL+ plane scaling is mutually exclusive with color keying. The code
check for this, but during some refactoring the code got changed to
also reject primary plane windowing when color keying is used. There is
no such restriction in the hardware, so restore the original logi
Chris Wilson writes:
> In order to ensure seqno/irq coherency, we current read a ring register.
> We are not sure quite how it works, only that is does. Experiments show
> that e.g. doing a clflush(seqno) instead is not sufficient, but we can
> remove the forcewake dance from the mmio access.
>
>
== Summary ==
Built on 615fbad7f4cea73b1a8eccdcc942c8ca1a708dab drm-intel-nightly:
2016y-01m-15d-09h-46m-32s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
pass -> DMESG-WARN (skl-i5k-2) UNSTABLE
dmesg-warn -> PASS (bdw-
== Summary ==
Built on 615fbad7f4cea73b1a8eccdcc942c8ca1a708dab drm-intel-nightly:
2016y-01m-15d-09h-46m-32s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
pass -> DMESG-WARN (skl-i5k-2) UNSTABLE
pass -> DMESG-WARN (skl-
From: Tvrtko Ursulin
LRC lifetime is well defined so we can cache the page pointing
to the object backing store in the context in order to avoid
walking over the object SG page list from the interrupt context
without the big lock held.
v2: Also cache the mapping. (Chris Wilson)
v3: Unmap on the
On Fri, Jan 15, 2016 at 04:51:46PM +, Chris Wilson wrote:
> Tvrtko was looking through the execbuffer-ioctl and noticed that the
> uABI was tightly coupled to our internal engine identifiers. Close
> inspection also revealed that we leak those internal engine identifiers
> through the busy-ioct
On Fri, Jan 15, 2016 at 04:39:29PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> LRC lifetime is well defined so we can cache the page pointing
> to the object backing store in the context in order to avoid
> walking over the object SG page list from the interrupt context
> without the
Tvrtko was looking through the execbuffer-ioctl and noticed that the
uABI was tightly coupled to our internal engine identifiers. Close
inspection also revealed that we leak those internal engine identifiers
through the busy-ioctl, and those internal identifiers already do not
match the user identi
== Summary ==
Built on 615fbad7f4cea73b1a8eccdcc942c8ca1a708dab drm-intel-nightly:
2016y-01m-15d-09h-46m-32s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
pass -> DMESG-WARN (bdw-ultra) UNSTABLE
Test kms_flip:
Subgroup basic-flip-vs-
From: Tvrtko Ursulin
LRC lifetime is well defined so we can cache the page pointing
to the object backing store in the context in order to avoid
walking over the object SG page list from the interrupt context
without the big lock held.
v2: Also cache the mapping. (Chris Wilson)
v3: Unmap on the
On Fri, Jan 15, 2016 at 04:02:52PM +, Tvrtko Ursulin wrote:
>
> On 15/01/16 13:57, Chris Wilson wrote:
> >On Fri, Jan 15, 2016 at 01:22:39PM +, Tvrtko Ursulin wrote:
> >>Looks like your DDX is the only user not using it in the boolean mode?
> >
> >As far as I am aware, that is the only use
On 15/01/16 16:19, Chris Wilson wrote:
On Fri, Jan 15, 2016 at 04:02:52PM +, Tvrtko Ursulin wrote:
On 15/01/16 13:57, Chris Wilson wrote:
On Fri, Jan 15, 2016 at 01:22:39PM +, Tvrtko Ursulin wrote:
Looks like your DDX is the only user not using it in the boolean mode?
As far as I a
== Summary ==
Built on 615fbad7f4cea73b1a8eccdcc942c8ca1a708dab drm-intel-nightly:
2016y-01m-15d-09h-46m-32s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
pass -> DMESG-WARN (skl-i7k-2) UNSTABLE
Test kms_flip:
Subgroup basic-flip-vs-
On Fri, Jan 15, 2016 at 04:05:24PM +, Tvrtko Ursulin wrote:
>
> On 15/01/16 16:01, Chris Wilson wrote:
> >On Fri, Jan 15, 2016 at 03:10:29PM +, Tvrtko Ursulin wrote:
> >>@@ -1118,15 +1126,22 @@ void intel_lr_context_unpin(struct
> >>drm_i915_gem_request *rq)
> >>+ if (--rq->ctx->engine[
On 15/01/16 16:01, Chris Wilson wrote:
On Fri, Jan 15, 2016 at 03:10:29PM +, Tvrtko Ursulin wrote:
@@ -1118,15 +1126,22 @@ void intel_lr_context_unpin(struct drm_i915_gem_request
*rq)
+ if (--rq->ctx->engine[ring->id].pin_count == 0) {
+ lrc_state_page = i915_gem_object
On 15/01/16 13:57, Chris Wilson wrote:
On Fri, Jan 15, 2016 at 01:22:39PM +, Tvrtko Ursulin wrote:
Looks like your DDX is the only user not using it in the boolean mode?
As far as I am aware, that is the only user that worries about which
engine the object is currently active on.
And li
On Fri, Jan 15, 2016 at 03:10:29PM +, Tvrtko Ursulin wrote:
> @@ -1118,15 +1126,22 @@ void intel_lr_context_unpin(struct
> drm_i915_gem_request *rq)
> + if (--rq->ctx->engine[ring->id].pin_count == 0) {
> + lrc_state_page = i915_gem_object_get_dirty_page(ctx_obj,
> +
On Fri, Jan 15, 2016 at 03:49:00PM +, Morton, Derek J wrote:
> Can this be merged so IGT on Android builds? No one has raise any
> objections since Monday about this patch.
Merged, thanks for the patch.
--
Damien
___
Intel-gfx mailing list
Intel-gf
On Fri, Jan 15, 2016 at 03:12:50PM +, Tvrtko Ursulin wrote:
> +static int
> +eb_select_ring(struct drm_i915_private *dev_priv,
> +struct drm_file *file,
> +struct drm_i915_gem_execbuffer2 *args,
> +struct intel_engine_cs **ring)
> +{
> + unsigned int user
Can this be merged so IGT on Android builds? No one has raise any objections
since Monday about this patch.
//Derek
-Original Message-
From: Morton, Derek J
Sent: Monday, January 11, 2016 1:32 PM
To: intel-gfx@lists.freedesktop.org
Cc: Wood, Thomas; Gore, Tim; ch...@chris-wilson.co.uk;
== Summary ==
Built on 615fbad7f4cea73b1a8eccdcc942c8ca1a708dab drm-intel-nightly:
2016y-01m-15d-09h-46m-32s UTC integration manifest
Test gem_ctx_basic:
pass -> FAIL (bdw-ultra)
Test gem_storedw_loop:
Subgroup basic-render:
pass -> DMESG
From: Devon Davies
tests/kms_frontbuffer_tracking.c: Now builds with DRM_PRIMARY_DISABLE
Each call to the function drmModeSetPlane now has an addtional NULL in the
arguments if DRM_PRIMARY_DISABLE is set.
tests/Android.mk: Allow the above tests to be built without Cairo
Simply remove
On Fri, Jan 15, 2016 at 04:44:46PM +0200, Imre Deak wrote:
> Adding Chris. We would need stolen_base and size early, could you check
> if moving i915_gem_init_stolen() earlier based on the diff at the end
> is ok?
Had a quick discussion with Imre on irc, and yes this is fine. Though we
could move
On Fri, Jan 15, 2016 at 02:45:49PM +, Tvrtko Ursulin wrote:
>
> On 15/01/16 13:53, Chris Wilson wrote:
> >Exercise the busy-ioctl and verify it reports the right active engines
> >using the execbuffer notation.
> >
> >Signed-off-by: Chris Wilson
> >---
> > tests/Makefile.sources | 1 +
> >
== Summary ==
Built on 615fbad7f4cea73b1a8eccdcc942c8ca1a708dab drm-intel-nightly:
2016y-01m-15d-09h-46m-32s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
dmesg-warn -> PASS (bdw-nuci7) UNSTABLE
Test kms_flip:
Subgroup basic-flip-vs-
On 15/01/16 11:44, Chris Wilson wrote:
On Fri, Jan 15, 2016 at 09:53:46AM +, Tvrtko Ursulin wrote:
On 14/01/16 13:34, Chris Wilson wrote:
On Thu, Jan 14, 2016 at 10:32:11AM +, Tvrtko Ursulin wrote:
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.
From: Tvrtko Ursulin
At the moment execbuf ring selection is fully coupled to
internal ring ids which is not a good thing on its own.
This dependency is also spread between two source files and
not spelled out at either side which makes it hidden and
fragile.
This patch decouples this dependenc
From: Tvrtko Ursulin
LRC code was calling GEM API like i915_gem_obj_ggtt_offset from
places where the struct_mutex cannot be grabbed (irq handlers).
To avoid that this patch caches some interesting bits and values
in the engine and context structures.
Some usages are also removed where they are
From: Tvrtko Ursulin
Purpose is to avoid calling i915_gem_obj_ggtt_offset from the
interrupt context without the big lock held.
v2: Renamed gtt_start to gtt_offset. (Daniel Vetter)
v3: Cache the VMA instead of address. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Cc:
From: Tvrtko Ursulin
No need to call ktime_get_raw_ns twice per unlimited wait and can
also elimate a local variable.
v2: Added comment about silencing the compiler warning. (Daniel Vetter)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Dave Gordon
Acked-by: Daniel Vetter
---
drivers/gpu/drm/i9
From: Tvrtko Ursulin
LRC lifetime is well defined so we can cache the page pointing
to the object backing store in the context in order to avoid
walking over the object SG page list from the interrupt context
without the big lock held.
v2: Also cache the mapping. (Chris Wilson)
v3: Unmap on the
On Thursday, January 14, 2016 11:46:46 AM ankitprasad.r.sha...@intel.com wrote:
> From: Ankitprasad Sharma
>
> Some modules, like i915.ko, needs to detect when certain ACPI features
> are active inorder to prevent corruption on contended resources.
> In particular, use of BIOS RapidStart Technolo
On pe, 2016-01-15 at 16:44 +0200, Imre Deak wrote:
> Adding Chris. We would need stolen_base and size early, could you
> check
> if moving i915_gem_init_stolen() earlier based on the diff at the end
> is ok?
Oops, I meant stolen reserved_base and reserved_size.
> On to, 2016-01-14 at 21:26 +0530,
On 15/01/16 13:53, Chris Wilson wrote:
Exercise the busy-ioctl and verify it reports the right active engines
using the execbuffer notation.
Signed-off-by: Chris Wilson
---
tests/Makefile.sources | 1 +
tests/gem_busy.c | 233 +
2 fil
Different subsystems and drivers have different preferred ways of
receiving bug reports; mailing list or bugzillas at various
locations. Add "B:" entry for specifying the preference to guide bug
reporters at the right location.
While at it, document the freedesktop.org bugzilla as the preferred
lo
Adding Chris. We would need stolen_base and size early, could you check
if moving i915_gem_init_stolen() earlier based on the diff at the end
is ok?
On to, 2016-01-14 at 21:26 +0530, Sagar Arun Kamble wrote:
> RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6
> setup register
In legacy mode, we use the gen6 seqno barrier to insert a delay after
the interrupt before reading the seqno (as the seqno write is not
flushed before the interrupt is sent, the interrupt arrives before the
seqno is visible). Execlists ignored the evidence of igt.
Note that is harder, but not impo
When reading from the HWS page, we use barrier() to prevent the compiler
optimising away the read from the volatile (may be updated by the GPU)
memory address. This is more suited to READ_ONCE(); make it so.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Mika Kuoppala
Reviewed-by: Mika Kuopp
Only declare a missed interrupt if we find that the GPU is idle with
waiters and a hangcheck interval has passed in which no new user
interrupts have been raised.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 11 +++
drivers/gpu/drm/i915/i91
Rather than call a function to compute the matching cachelines and
clflush them, just call the clflush *instruction* directly. We also know
that we can use the unpatched plain clflush rather than the clflushopt
alternative.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Imre Deak
---
driver
In order to simplify future patches, extract the
lazy_coherency optimisation our of the engine->get_seqno() vfunc into
its own callback.
v2: Rename the barrier to engine->irq_seqno_barrier to try and better
reflect that the barrier is only required after the user interrupt before
reading the seqno
In order to ensure seqno/irq coherency, we current read a ring register.
We are not sure quite how it works, only that is does. Experiments show
that e.g. doing a clflush(seqno) instead is not sufficient, but we can
remove the forcewake dance from the mmio access.
v2: Baytrail wants a clflush too.
Mika wanted to bump these patches as they should help reduce both real
and false declarations of missed interrupts plaguing Broadwell/Skylake
CI.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listi
On Fri, Jan 15, 2016 at 01:22:39PM +, Tvrtko Ursulin wrote:
> Looks like your DDX is the only user not using it in the boolean mode?
As far as I am aware, that is the only user that worries about which
engine the object is currently active on.
> And libdrm is a bit confused in its return sta
Exercise the busy-ioctl and verify it reports the right active engines
using the execbuffer notation.
Signed-off-by: Chris Wilson
---
tests/Makefile.sources | 1 +
tests/gem_busy.c | 233 +
2 files changed, 234 insertions(+)
create mode 10
Kind Regards,
Derek Yerger
Computer Engineering
10171358 / djy24
[1.] displayport MST external monitors don't return from sleep mode
[2.] When displays go to sleep, upon return from sleep the two monitors
attached to a belkin mini displayport to 2x HDMI, do not return from
sleep. This results
On Thu, 14 Jan 2016, Jani Nikula wrote:
> Support MIPI sequence block v3 in the intel_bios_reader tool. This is
> mostly copied from the kernel. It makes some of the parts a bit
> artifical for an userspace tool, but hey, this pattern has been followed
> all around in IGT and it makes debugging ke
On Fri, 15 Jan 2016, Mika Kahola wrote:
> Fix typo on intel_bios_reader.c
>
> Signed-off-by: Mika Kahola
Pushed, thanks for the patch.
BR,
Jani.
> ---
> tools/intel_bios_reader.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/intel_bios_reader.c b/tools/intel_b
On 15/01/16 12:27, Chris Wilson wrote:
On Fri, Jan 15, 2016 at 11:58:32AM +, Tvrtko Ursulin wrote:
On 15/01/16 11:06, Chris Wilson wrote:
Tvrtko was looking through the execbuffer-ioctl and noticed that the
uABI was tightly coupled to our internal engine identifiers. Close
inspection also
On Fri, Jan 15, 2016 at 11:28:16AM +, Chris Wilson wrote:
> On Fri, Jan 15, 2016 at 10:20:11AM +, Chris Wilson wrote:
> > Throughout the code base, we use u32 for offsets into the global GTT. If
> > we ever see any hardware with a larger GGTT, then we run the real risk
> > of silent corrupt
On Fri, Jan 15, 2016 at 11:06:42AM +0200, Marius Vlad wrote:
> lib/igt_kms: Briefly describe Intel-to-DRM mapping between pipes, encoders and
> connectors.
>
> Signed-off-by: Marius Vlad
> ---
> lib/igt_kms.c | 82
> +++
> 1 file changed,
On Fri, Jan 15, 2016 at 11:58:32AM +, Tvrtko Ursulin wrote:
>
> On 15/01/16 11:06, Chris Wilson wrote:
> >Tvrtko was looking through the execbuffer-ioctl and noticed that the
> >uABI was tightly coupled to our internal engine identifiers. Close
> >inspection also revealed that we leak those in
On Fri, Jan 15, 2016 at 12:12:15PM +, Dave Gordon wrote:
> On 11/01/16 09:17, Chris Wilson wrote:
> >The multiple levels of indirect do nothing but hinder the compiler and
> >the pointer chasing turns to be quite painful but painless to fix.
> >
> >Signed-off-by: Chris Wilson
> >---
> > drive
== Summary ==
Built on 615fbad7f4cea73b1a8eccdcc942c8ca1a708dab drm-intel-nightly:
2016y-01m-15d-09h-46m-32s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
pass -> DMESG-WARN (skl-i5k-2) UNSTABLE
dmesg-warn -> PASS (bdw-
On 11/01/16 09:17, Chris Wilson wrote:
The multiple levels of indirect do nothing but hinder the compiler and
the pointer chasing turns to be quite painful but painless to fix.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 13 ++---
drivers/gpu/drm/i915
On Thu, Jan 14, 2016 at 05:00:02PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 14, 2016 at 02:49:45PM -, Patchwork wrote:
> > == Summary ==
> >
> > Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly:
> > 2016y-01m-14d-13h-06m-44s UTC integration manifest
> >
> > Test gem_ctx_b
On 15/01/16 11:06, Chris Wilson wrote:
Tvrtko was looking through the execbuffer-ioctl and noticed that the
uABI was tightly coupled to our internal engine identifiers. Close
inspection also revealed that we leak those internal engine identifiers
through the busy-ioctl, and those internal identi
Since the removal of UMS, we have always had sole ownership of the GTTs.
We no longer have to track the subsection we are allowed to use (denoted
by start + total). vGPU does restrict the range of the global GTT we can
use (as it has to share it amongst all the clients on the host), but
that is ach
On Fri, Jan 15, 2016 at 11:25:38AM +, Dave Gordon wrote:
> On 15/01/16 10:20, Chris Wilson wrote:
> >Throughout the code base, we use u32 for offsets into the global GTT. If
> >we ever see any hardware with a larger GGTT, then we run the real risk
> >of silent corruption. So test for our assump
On Fri, Jan 15, 2016 at 09:53:46AM +, Tvrtko Ursulin wrote:
>
> On 14/01/16 13:34, Chris Wilson wrote:
> >On Thu, Jan 14, 2016 at 10:32:11AM +, Tvrtko Ursulin wrote:
> >>>diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
> >>>b/drivers/gpu/drm/i915/i915_gem_gtt.h
> >>>index b448ad8..5f8659
On Fri, Jan 15, 2016 at 10:29:05AM +, Tvrtko Ursulin wrote:
> >One question, how does this look if we move this section to its own
> >function:
> >
> >ring = eb_select_ring(dev_priv, file, args);
> >if (IS_ERR(ring))
> > return PTR_ERR(ring);
> >
> >Do you keep your code size reduction?
>
On Fri, Jan 15, 2016 at 10:20:11AM +, Chris Wilson wrote:
> Throughout the code base, we use u32 for offsets into the global GTT. If
> we ever see any hardware with a larger GGTT, then we run the real risk
> of silent corruption. So test for our assumption up front so that we
> have a nice remi
On 15/01/16 10:20, Chris Wilson wrote:
Throughout the code base, we use u32 for offsets into the global GTT. If
we ever see any hardware with a larger GGTT, then we run the real risk
of silent corruption. So test for our assumption up front so that we
have a nice reminder should the time come whe
== Summary ==
Built on 615fbad7f4cea73b1a8eccdcc942c8ca1a708dab drm-intel-nightly:
2016y-01m-15d-09h-46m-32s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
dmesg-warn -> PASS (bdw-nuci7)
pass -> DMESG-WARN (skl-i7k-2) UN
Tvrtko was looking through the execbuffer-ioctl and noticed that the
uABI was tightly coupled to our internal engine identifiers. Close
inspection also revealed that we leak those internal engine identifiers
through the busy-ioctl, and those internal identifiers already do not
match the user identi
On 14/01/2016 12:37, Nick Hoath wrote:
On 14/01/2016 12:31, Chris Wilson wrote:
On Thu, Jan 14, 2016 at 11:56:07AM +, Nick Hoath wrote:
On 14/01/2016 11:36, Chris Wilson wrote:
On Wed, Jan 13, 2016 at 04:19:45PM +, Nick Hoath wrote:
+ if (ctx->engine[ring->id].dirty) {
+
== Summary ==
Built on 615fbad7f4cea73b1a8eccdcc942c8ca1a708dab drm-intel-nightly:
2016y-01m-15d-09h-46m-32s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
dmesg-warn -> PASS (bdw-nuci7)
pass -> DMESG-WARN (bdw-ultra)
Te
On 14/01/16 22:09, Chris Wilson wrote:
On Thu, Jan 14, 2016 at 03:02:59PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
At the moment execbuf ring selection is fully coupled to
internal ring ids which is not a good thing on its own.
This dependency is also spread between two source files
Throughout the code base, we use u32 for offsets into the global GTT. If
we ever see any hardware with a larger GGTT, then we run the real risk
of silent corruption. So test for our assumption up front so that we
have a nice reminder should the time come when it fails.
Signed-off-by: Chris Wilson
On Thu, 2016-01-14 at 19:20 +0530, Shubhangi Shrivastava wrote:
>
> On Wednesday 13 January 2016 07:03 PM, Ander Conselvan De Oliveira wrote:
> > On Wed, 2016-01-13 at 13:20 +0200, Ander Conselvan De Oliveira wrote:
> > > On Tue, 2016-01-05 at 18:20 +0530, Shubhangi Shrivastava wrote:
> > > > inte
On Thu, Jan 14, 2016 at 10:36:53PM +, Chris Wilson wrote:
> On Thu, Jan 14, 2016 at 03:22:15PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Using 'unsigned long' for ggtt offsets doesn't make much sense. Use
> > 'u32' instead since we've not yet seen a >4GiB ggt
On 14/01/16 13:34, Chris Wilson wrote:
On Thu, Jan 14, 2016 at 10:32:11AM +, Tvrtko Ursulin wrote:
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index b448ad8..5f86596 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_
On Thu, 14 Jan 2016, Francisco Jerez wrote:
> Jani Nikula writes:
>
>> On Thu, 14 Jan 2016, Francisco Jerez wrote:
>>> We need to set the DC FLUSH PIPE_CONTROL bit on Gen7+ to guarantee
>>> that writes performed via the HDC are visible in memory. Fixes an
>>> intermittent failure in a Piglit te
On Thu, 14 Jan 2016, Ville Syrjälä wrote:
> On Thu, Jan 14, 2016 at 05:12:07PM +0200, Jani Nikula wrote:
>> Two errors in a single line. The size was read from the wrong offset,
>> and the end index didn't take the five bytes for sequence byte and size
>> of sequence into account. Fix it all, and
On Wed, 13 Jan 2016, Ville Syrjälä wrote:
> On Wed, Jan 13, 2016 at 04:35:20PM +0200, Jani Nikula wrote:
>> Per DP spec, the source device should fall back to 18 bpp, VESA range
>> RGB when the sink capability is unknown. Fix the color depth
>> clamping. 18 bpp color depth should ensure full color
Hi,
On 14/01/16 11:02, Chris Wilson wrote:
For softpinning, we do not require either userptr or extended ppgtt, so
remove those requirements and make the tests work universally. (Certain
ABI tests require large GTT, or per-process GTT.)
In the process, make the tests more extensive - validate
lib/igt_kms: Briefly describe Intel-to-DRM mapping between pipes, encoders and
connectors.
Signed-off-by: Marius Vlad
---
lib/igt_kms.c | 82 +++
1 file changed, 82 insertions(+)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index c7a0b77..ca
lib/igt_kms: Fix minor spelling/gtk-doc links. Style changes -- trimmed several
calls to asprintf(). Placed SECTION header at the beginning of the file. Add
documentation for remaining functions and macros.
v2: Initially, I wanted to aggregate the documentation in header file(s).
This version kee
So far, we had only COMMIT_UNIVERSAL and COMMIT_LEGACY, using
drmModeSetPlane()/drmSetCrtc(). This patch adds COMMIT_ATOMIC
to igt_display_commit2() that makes use of drmModeAtomicCommit().
Signed-off-by: Marius Vlad
---
lib/igt_kms.c | 190 +++
Fix typo on intel_bios_reader.c
Signed-off-by: Mika Kahola
---
tools/intel_bios_reader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index b31f648..5ca50ff 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_
== Summary ==
Built on 4efb7ea717f8478860c4cb829fc0956f195c0b50 drm-intel-nightly:
2016y-01m-15d-02h-35m-27s UTC integration manifest
Test gem_ctx_basic:
pass -> FAIL (bdw-ultra)
Test gem_storedw_loop:
Subgroup basic-render:
dmesg-warn -> PASS
Starting from Gen9 we can use IA-Coherent caches. Generally, coherency
can be programmed using RENDER_SURFACE_STATE or BTI 255, depending if
surface state model or stateless model is used. It is important to control
whether IA or GPU cache coherency should be used, especially for non-LLC
devices. H
91 matches
Mail list logo
