== Series Details ==
Series: drm/i915: Remove two sloppy inline functions from .h (rev2)
URL : https://patchwork.freedesktop.org/series/14931/
State : success
== Summary ==
Series 14931v2 drm/i915: Remove two sloppy inline functions from .h
https://patchwork.freedesktop.org/api/1.0/series/1493
On ma, 2016-11-07 at 13:59 +, Chris Wilson wrote:
> @@ -56,6 +61,24 @@ int i915_gem_timeline_init(struct drm_i915_private *i915,
> return 0;
> }
>
> +int i915_gem_timeline_init(struct drm_i915_private *i915,
> + struct i915_gem_timeline *timeline,
> +
Hi all,
New -testing cycle with cool stuff:
- gpu idling rework for s/r (Imre)
- vlv mappable scanout fix
- speed up probing in resume (Lyude)
- dp audio workarounds for gen9 (Dhinakaran)
- more conversion to using dev_priv internally (Ville)
- more gen9+ wm fixes and cleanups (Maarten)
- shrinker
Get rid of sloppy inline functions now that we don't have more users:
i915_gem_request_get_seqno
i915_gem_request_get_engine
v2:
- request->engine is always non-NULL (Chris)
Signed-off-by: Joonas Lahtinen
Cc: Chris Wilson
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c
On Mon, 2016-11-07 at 11:49 -0800, Robert Bragg wrote:
> In particular this tries to capture for posterity some of the early
> challenges we had with using the core perf infrastructure in case we
> ever want to revisit adapting perf for device metrics.
>
> Cc: Chris Wilson
> Signed-off-by: Robert
On Mon, 2016-11-07 at 11:49 -0800, Robert Bragg wrote:
> The maximum OA sampling frequency is now configurable via a
> dev.i915.oa_max_sample_rate sysctl parameter.
>
> Following the precedent set by perf's similar
> kernel.perf_event_max_sample_rate the default maximum rate is 10Hz
>
> Signe
On Mon, 2016-11-07 at 11:49 -0800, Robert Bragg wrote:
> Adds a static OA unit, MUX + B Counter configuration for basic render
> metrics on Haswell. This is auto generated from an XML
> description of metric sets, currently maintained in gputop, ref:
>
> https://github.com/rib/gputop
> > gputo
Hi all,
FIXME: Add owner of second tree to To:
Add author(s)/SOB of conflicting commits.
Today's linux-next merge of the tip tree got a conflict in:
drivers/gpu/drm/i915/i915_gem_shrinker.c
between commits:
1233e2db199d ("drm/i915: Move object backing storage manipulation to its own
== Series Details ==
Series: drm/i915/dp: Update connector status for DP MST hotplugs (rev3)
URL : https://patchwork.freedesktop.org/series/14821/
State : success
== Summary ==
Series 14821v3 drm/i915/dp: Update connector status for DP MST hotplugs
https://patchwork.freedesktop.org/api/1.0/ser
Hotplugging a monitor in DP MST configuration triggers short pulses.
Although the short pulse handling path ends up in the MST hotplug function,
we do not perform a detect before sending the hotplug uvent. This leads to
the connector status not being updated when the userspace calls
DRM_IOCTL_MODE_
Since we're going to be using lists for keeping track of EDIDs we've
allocated on the chamelium, add some generic list helpers from the
wayland project.
Signed-off-by: Lyude
---
lib/igt_aux.c | 27 +++
lib/igt_aux.h | 38 ++
2 files cha
For the purpose of testing things such as hotplugging and bad monitors,
the ChromeOS team ended up designing a neat little device known as the
Chamelium. More information on this can be found here:
https://www.chromium.org/chromium-os/testing/chamelium
This adds support for a couple of th
For a very long time, we've had basically no automated testing coverage of
hotplugging functionality mainly because the only way to test this sort of
thing was to manually plug and unplug the connectors yourself. As well, this
also means we could never automate testing of various DisplayPort quirks
The default autoresume delay is about 5 seconds. It's possible on a
system that's not very fast this might not be a long enough time, since
an asynchronous hotplug event we scheduled on the chamelium that was
intended to happen during suspend could happen before we actually manage
to suspend. So, a
Since all of the chamelium calls are blocking, we need to be able to
make suspend/resume tests with it multi-threaded. As such, it's not the
best idea to rely on igt_system_suspend_autoresume() for skipping tests
on systems without suspend/resume support since we could accidentally
leave the thread
On Mon, 2016-11-07 at 18:14 +0200, Ville Syrjälä wrote:
> On Thu, Nov 03, 2016 at 08:38:32PM -0700, Dhinakaran Pandiyan wrote:
> > Hotplugging a monitor in DP MST configuration triggers short pulses.
> > Although the short pulse handling path ends up in the MST hotplug function,
> > we do not perfo
== Series Details ==
Series: drm/dp: Make space for null terminator in the DP device ID char array
(rev2)
URL : https://patchwork.freedesktop.org/series/14865/
State : success
== Summary ==
Series 14865v2 drm/dp: Make space for null terminator in the DP device ID char
array
https://patchwork
The DP device identification string read from the DPCD registers is 6
characters long at max. and we store it in a char array of the same length
without space for the NULL terminator. Fix this by increasing the array
size to 7 and initialize it to an empty string.
v2: Use %*pE format specifier (Ja
Am Montag, 7. November 2016, 19:09:36 CET schrieb Jani Nikula:
> On Mon, 07 Nov 2016, Martin Steigerwald wrote:
> > It is also the same kind of corruptions as shown in
> >
> > [Bug 177701] warning in intel_dp_aux_transfer
> > https://bugzilla.kernel.org/show_bug.cgi?id=177701
> >
> > Just compar
The i915-perf series affects the command parser and itself includes new uapi
which these i-g-t changes try to cover.
This version splits up the gem_exec_parse.c changes
I also made some adjustments to the i915 perf tests to scale raw timestamps
in terms of a 1250Hz timestamp frequency constan
Signed-off-by: Robert Bragg
---
tests/Makefile.sources |1 +
tests/perf.c | 2220
2 files changed, 2221 insertions(+)
create mode 100644 tests/perf.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 6d081c3..7c6de2
This adapts the tests to account for the parser no longer reporting
privilege violations back to userspace as EINVAL errors (they are left
to the HW command parser to squash the commands to NOOPS).
The interface change isn't expected to affect userspace and in fact it
looks like the previous behav
No functional change, just moving hsw_load_regster_reg test code down
below the execbuf utilities in preparation for updating to use them.
Signed-off-by: Robert Bragg
---
tests/gem_exec_parse.c | 174 -
1 file changed, 87 insertions(+), 87 deletion
The command parser no longer whitelists or does anything special for the
OACONTROL register which is now considered owned by i915-perf.
As a follow up the plan is to at least check that attempting to write to
OACONTROL from userspace must not fail with an EINVAL error, otherwise
Mesa's graceful fa
This normalizes the execbuf utilities in this file to all use memset to
clear obj, reloc and execbuf structures and set them up in the same
order. As I was debugging some unpredictable test failures I was getting
unsure that all these structures were being fully initialized.
The same I915_GEM_DOMA
This generalises hsw_load_register_reg to loop through an array of
allowed and disallowed registers and to use the exec_batch[_patched]
utilities.
Signed-off-by: Robert Bragg
---
tests/gem_exec_parse.c | 132 -
1 file changed, 64 insertions(+), 68
On Mon, Nov 07, 2016 at 10:20:53PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Starting from commit b63a16f6cd89 ("drm/i915: Compute display surface
> offset in the plane check hook for SKL+") we've already rotated the src
> coordinates by 270 degrees by the time we chec
On Mon, Nov 07, 2016 at 10:20:57PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The code to determine the primary plane offset for gen2/3 looks
> different than the code for gen4+, but in fact it's doing the same
> thing. Let's make it uniform. Allows us to eliminate the
On Mon, Nov 07, 2016 at 10:20:55PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Use the passed in plane_state instead of plane->state in
> vlv_update_plane(). Currently the two are one and the same, but if we
> start queuing up multiple plane updates they might not be.
>
On Mon, Nov 07, 2016 at 10:20:56PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> intel_cursor_plane_create() and intel_sprite_plane_create() return
> an error pointer, so let's not mistakenly look for a NULL pointer.
>
> Cc: Chris Wilson
> Reported-by: Chris Wilson
> Re
On Mon, Nov 07, 2016 at 05:15:49PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Mark CPU cache as dirty when used for rendering (rev2)
> URL : https://patchwork.freedesktop.org/series/14930/
> State : success
An indication that we are missing some coverage. Pushed.
-Chr
== Series Details ==
Series: drm/i915: Assortment of plane fixes
URL : https://patchwork.freedesktop.org/series/14936/
State : success
== Summary ==
Series 14936v1 drm/i915: Assortment of plane fixes
https://patchwork.freedesktop.org/api/1.0/series/14936/revisions/1/mbox/
fi-bdw-5557u to
From: Ville Syrjälä
The code to determine the primary plane offset for gen2/3 looks
different than the code for gen4+, but in fact it's doing the same
thing. Let's make it uniform. Allows us to eliminate the 'obj' from
the list of local variables as well.
Signed-off-by: Ville Syrjälä
---
drive
From: Ville Syrjälä
When the plane is invisible we may have all sorts of bogus stuff
in the coordinates, which we must ignore or else we might fail the
plane update. This started to happen on SKL when I moved the plane
offset computation to happen in the check phase. Previously we
happily ignored
From: Ville Syrjälä
I found another breakage from my SKL plane check stuff when testing out Xv
on SKL, and we still have that 90/270 rotation fix which I already sent out
earlier. I also spotted a harmless bug in the VLV/CHV sprite code so I
figured I'd include the fix for that one as well. And C
From: Ville Syrjälä
Use the passed in plane_state instead of plane->state in
vlv_update_plane(). Currently the two are one and the same, but if we
start queuing up multiple plane updates they might not be.
Looks like this was rebase fail on my part.
Cc: Daniel Vetter
Fixes: 8d0deca8c6e0 ("drm/
From: Ville Syrjälä
Starting from commit b63a16f6cd89 ("drm/i915: Compute display surface
offset in the plane check hook for SKL+") we've already rotated the src
coordinates by 270 degrees by the time we check if a scaler is needed
or not, so we must not account for the rotation a second time.
Pr
From: Ville Syrjälä
intel_cursor_plane_create() and intel_sprite_plane_create() return
an error pointer, so let's not mistakenly look for a NULL pointer.
Cc: Chris Wilson
Reported-by: Chris Wilson
References:
https://lists.freedesktop.org/archives/intel-gfx/2016-November/110690.html
Fixes: b0
== Series Details ==
Series: Enable i915 perf stream for Haswell OA unit
URL : https://patchwork.freedesktop.org/series/14935/
State : failure
== Summary ==
Series 14935v1 Enable i915 perf stream for Haswell OA unit
https://patchwork.freedesktop.org/api/1.0/series/14935/revisions/1/mbox/
Test
In particular this tries to capture for posterity some of the early
challenges we had with using the core perf infrastructure in case we
ever want to revisit adapting perf for device metrics.
Cc: Chris Wilson
Signed-off-by: Robert Bragg
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_p
Consistent with the kernel.perf_event_paranoid sysctl option that can
allow non-root users to access system wide cpu metrics, this can
optionally allow non-root users to access system wide OA counter metrics
from Gen graphics hardware.
Signed-off-by: Robert Bragg
Reviewed-by: Matthew Auld
Review
This adds 'compute', 'compute extended', 'memory reads', 'memory writes'
and 'sampler balance' metric sets for Haswell.
The code is auto generated from an XML description of metric sets,
currently maintained in gputop, ref:
https://github.com/rib/gputop
> gputop-data/oa-*.xml
> scripts/i915-pe
Each metric set is given a sysfs entry like:
/sys/class/drm/card0/metrics//id
This allows userspace to enumerate the specific sets that are available
for the current system. The 'id' file contains an unsigned integer that
can be used to open the associated metric set via
DRM_IOCTL_I915_PERF_OPEN.
The maximum OA sampling frequency is now configurable via a
dev.i915.oa_max_sample_rate sysctl parameter.
Following the precedent set by perf's similar
kernel.perf_event_max_sample_rate the default maximum rate is 10Hz
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_perf.c | 61 ++
check_cmd() is checking whether a command adheres to certain
restrictions that ensure it's safe to execute within a privileged batch
buffer. Returning false implies a privilege problem, not that the
command is invalid.
The distinction makes the difference between allowing the buffer to be
executed
Gen graphics hardware can be set up to periodically write snapshots of
performance counters into a circular buffer via its Observation
Architecture and this patch exposes that capability to userspace via the
i915 perf interface.
v2:
Make sure to initialize ->specific_ctx_id when opening, withou
Adds a static OA unit, MUX + B Counter configuration for basic render
metrics on Haswell. This is auto generated from an XML
description of metric sets, currently maintained in gputop, ref:
https://github.com/rib/gputop
> gputop-data/oa-*.xml
> scripts/i915-perf-kernelgen.py
$ make -C gpu
Rebased and updated with more feedback from Sourab and Matt.
In particular the patch that added the oa_min_timer_exponent sysctl parameter
has now been replaced with one adding an oa_max_sample_rate parameter in Hz.
This way userspace policy won't need to be tailored to different systems when
gen
OACONTROL changes quite a bit for gen8, with some bits split out into a
per-context OACTXCONTROL register. Rename now before adding more gen7 OA
registers
Signed-off-by: Robert Bragg
Reviewed-by: Matthew Auld
Reviewed-by: Sourab Gupta
---
drivers/gpu/drm/i915/gvt/handlers.c| 2 +-
drivers/
Being able to program OACONTROL from a non-privileged batch buffer is
not sufficient to be able to configure the OA unit. This was originally
allowed to help enable Mesa to expose OA counters via the
INTEL_performance_query extension, but the current implementation based
on programming OACONTROL vi
Adds base i915 perf infrastructure for Gen performance metrics.
This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl()
Jani, could you please take a look at this patch?
I have addressed your comments on the previous revision.
The common_rates array can be moved into Intel dp
structure in a follow up patch since that would require changes
in a lot of places other than the link rate fallback implementation.
Regards
On Fri, 04 Nov 2016, Dhinakaran Pandiyan wrote:
> The DP device identification string read from the DPCD registers is 6
> characters long at max. and we store it in a char array of the same length
> without space for the NULL terminator. Fix this by increasing the array
> size to 7 and initialize
Mika,
Can you take a look at this?
-DK
On Fri, 2016-11-04 at 14:06 -0700, Dhinakaran Pandiyan wrote:
> The DP device identification string read from the DPCD registers is 6
> characters long at max. and we store it in a char array of the same length
> without space for the NULL terminator. Fix t
Thomas has already acked the earlier version, but in case you need
it for this one, too.
vmwgfx portion: Acked-by: Sinclair Yeh
On Mon, Nov 07, 2016 at 12:48:09AM +, Eric Engestrom wrote:
> Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
>
> drm: make drm_get_format_name thread-safe
>
On Mon, 07 Nov 2016, Eric Engestrom wrote:
> On Monday, 2016-11-07 10:10:13 +0200, Jani Nikula wrote:
>> On Mon, 07 Nov 2016, Eric Engestrom wrote:
>> > Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
>> >
>> > drm: make drm_get_format_name thread-safe
>> >
>> > Signed-off-by: Eric Engest
== Series Details ==
Series: drm/i915: Mark CPU cache as dirty when used for rendering (rev2)
URL : https://patchwork.freedesktop.org/series/14930/
State : success
== Summary ==
Series 14930v2 drm/i915: Mark CPU cache as dirty when used for rendering
https://patchwork.freedesktop.org/api/1.0/s
On Monday, 2016-11-07 10:10:13 +0200, Jani Nikula wrote:
> On Mon, 07 Nov 2016, Eric Engestrom wrote:
> > Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
> >
> > drm: make drm_get_format_name thread-safe
> >
> > Signed-off-by: Eric Engestrom
> > [danvet: Clarify that the returned poin
On Mon, 07 Nov 2016, Martin Steigerwald wrote:
> It is also the same kind of corruptions as shown in
>
> [Bug 177701] warning in intel_dp_aux_transfer
> https://bugzilla.kernel.org/show_bug.cgi?id=177701
>
> Just compare
>
> https://bugzilla.kernel.org/attachment.cgi?id=241801
>
> with
>
> https:
On LLC, or even snooped, machines rendering via the GPU ends up in the CPU
cache. This cacheline dirt also needs to be flushed to main memory when
moving to an incoherent domain, such as the display's scanout engine.
Mostly, this happens because either the object is marked as dirty from
its first u
== Series Details ==
Series: drm/i915: Remove two sloppy inline functions from .h
URL : https://patchwork.freedesktop.org/series/14931/
State : success
== Summary ==
Series 14931v1 drm/i915: Remove two sloppy inline functions from .h
https://patchwork.freedesktop.org/api/1.0/series/14931/revis
On Mon, Nov 07, 2016 at 03:46:28PM +, Chris Wilson wrote:
> On LLC, or even snooped, machines rendering via the GPU ends up in the CPU
> cache. This cacheline dirt also needs to be flushed to main memory when
> moving to an incoherent domain, such as the display's scanout engine.
> Mostly, this
On Mon, Nov 07, 2016 at 06:13:20PM +0200, Joonas Lahtinen wrote:
> Get rid of sloppy inline functions now that we don't have more users:
>
> i915_gem_request_get_seqno
> i915_gem_request_get_engine
>
> Cc: Chris Wilson
> Signed-off-by: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_debugfs.
On ma, 2016-11-07 at 12:10 +, Chris Wilson wrote:
> On Mon, Nov 07, 2016 at 02:01:46PM +0200, Joonas Lahtinen wrote:
> >
> > On su, 2016-11-06 at 12:59 +, Chris Wilson wrote:
> > >
> > > We always flush the chipset prior to executing with the GPU, so we can
> > > skip the flush during ord
== Series Details ==
Series: drm/i915: Mark CPU cache as dirty when used for rendering
URL : https://patchwork.freedesktop.org/series/14930/
State : success
== Summary ==
Series 14930v1 drm/i915: Mark CPU cache as dirty when used for rendering
https://patchwork.freedesktop.org/api/1.0/series/1
On Thu, Nov 03, 2016 at 08:38:32PM -0700, Dhinakaran Pandiyan wrote:
> Hotplugging a monitor in DP MST configuration triggers short pulses.
> Although the short pulse handling path ends up in the MST hotplug function,
> we do not perform a detect before sending the hotplug uvent. This leads to
> th
Get rid of sloppy inline functions now that we don't have more users:
i915_gem_request_get_seqno
i915_gem_request_get_engine
Cc: Chris Wilson
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/i915_gem_request.h | 12
drivers
On LLC, or even snooped, machines rendering via the GPU ends up in the CPU
cache. This cacheline dirt also needs to be flushed to main memory when
moving to an incoherent domain, such as the display's scanout engine.
Mostly, this happens because either the object is marked as dirty from
its first u
== Series Details ==
Series: series starting with [v2,01/11] drm/i915: Create distinct lockclasses
for execution vs user timelines
URL : https://patchwork.freedesktop.org/series/14926/
State : success
== Summary ==
Series 14926v1 Series without cover letter
https://patchwork.freedesktop.org/a
Thanks for the review.
On Mon, 2016-11-07 at 14:04 +0100, Maarten Lankhorst wrote:
> Op 02-11-16 om 10:32 schreef Mika Kahola:
> >
> > This is a testcase with multiple planes. The idea here is the
> > following
> >
> > - draw a uniform frame with blue color
> > - grab crc for reference
> > -
== Series Details ==
Series: series starting with [1/1] drm/i915: Don't take execlist spinlock when
setting wedged
URL : https://patchwork.freedesktop.org/series/14925/
State : success
== Summary ==
Series 14925v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/14
On Sun, Nov 6, 2016 at 7:48 PM, Eric Engestrom wrote:
> Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
>
> drm: make drm_get_format_name thread-safe
>
> Signed-off-by: Eric Engestrom
> [danvet: Clarify that the returned pointer must be freed with
> kfree().]
> Signed-off-by:
On Mon, 2016-11-07 at 03:10 -0800, Matthew Auld wrote:
> On 4 November 2016 at 09:30, wrote:
> > From: Sourab Gupta
> >
> > Add a compile time option for detecting the overflow condition of command
> > stream buffer, and not overwriting the old entries in such a case.
> > Also, set a status fla
Am Montag, 7. November 2016, 13:04:16 CET schrieb Jani Nikula:
> On Sun, 06 Nov 2016, Martin Steigerwald wrote:
> > Hi.
> >
> > Am Samstag, 5. November 2016, 16:46:33 CET schrieb Linus Torvalds:
> >> So it's once again a Saturday afternoon rather than Sunday, this time
> >> because I felt this rc
Userspace is faced with a dilemma. The kernel requires implicit fencing
to manage resource usage (we always must wait for the GPU to finish
before releasing its PTE) and for third parties. However, userspace may
wish to avoid this serialisation if it is either using explicit fencing
between parties
Now that the user can opt-out of implicit fencing, we need to give them
back control over the fencing. We employ sync_file to wrap our
drm_i915_gem_request and provide an fd that userspace can merge with
other sync_file fds and pass back to the kernel to wait upon before
future execution.
Testcase
The start of the scheduler, add a hook into request submission for the
scheduler to see the arrival of new requests and prepare its runqueues.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.c | 4
drivers/gpu/drm/i915/i915_gem_request.c |
Defer the transfer from the client's timeline onto the execution
timeline from the point of readiness to the point of actual submission.
For example, in execlists, a request is finally submitted to hardware
when the hardware is ready, and only put onto the hardware queue when
the request is ready.
The execlist_lock is now completely subsumed by the engine->timeline->lock,
and so we can remove the redundant layer of locking.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/i915_gem.c | 8 ++--
dr
This emulates execlists on top of the GuC in order to defer submission of
requests to the hardware. This deferral allows time for high priority
requests to gazump their way to the head of the queue, however it nerfs
the GuC by converting it back into a simple execlist (where the CPU has
to wake up
Boost the priority of any rendering required to show the next pageflip
as we want to avoid missing the vblank by being delayed by invisible
workload. We prioritise avoiding jank and jitter in the GUI over
starving background tasks.
v2: Descend dma_fence_array when boosting priorities.
Signed-off-
Use a priority stored in the context as the initial value when
submitting a request. This allows us to change the default priority on a
per-context basis, allowing different contexts to be favoured with GPU
time at the expense of lower importance work. The user can adjust the
context's priority via
In order to support deferred scheduling, we need to differentiate
between when the request is ready to run (i.e. the submit fence is
signaled) and when the request is actually run (a new execute fence).
This is typically split between the request itself wanting to wait upon
others (for which we use
The scheduler needs to know the dependencies of each request for the
lifetime of the request, as it may choose to reschedule the requests at
any time and must ensure the dependency tree is not broken. This is in
additional to using the fence to only allow execution after all
dependencies have been
In order to simplify the lockdep annotation, as they become more complex
in the future with deferred execution and multiple paths through the
same functions, create a separate lockclass for the user timeline and
the hardware execution timeline.
We should only ever be locking the user timeline and
Not much to report here. Biggest change is converting the recursive DFS
for PI into an iterative algorithm. The biggest challenge remains trying
to get a consistent set of names so we avoid confusing ourselves going
forwards into preemption. Biggest TODO task is check for perf regressions
from the
On 07/11/2016 13:39, Chris Wilson wrote:
On Mon, Nov 07, 2016 at 01:30:43PM +, Tvrtko Ursulin wrote:
On 07/11/2016 09:30, Chris Wilson wrote:
On Mon, Nov 07, 2016 at 09:12:57AM +, Tvrtko Ursulin wrote:
On 04/11/2016 15:11, Chris Wilson wrote:
On Fri, Nov 04, 2016 at 02:44:44PM +000
On Mon, Nov 07, 2016 at 01:30:43PM +, Tvrtko Ursulin wrote:
>
> On 07/11/2016 09:30, Chris Wilson wrote:
> >On Mon, Nov 07, 2016 at 09:12:57AM +, Tvrtko Ursulin wrote:
> >>
> >>On 04/11/2016 15:11, Chris Wilson wrote:
> >>>On Fri, Nov 04, 2016 at 02:44:44PM +, Tvrtko Ursulin wrote:
> >
On 07/11/2016 09:30, Chris Wilson wrote:
On Mon, Nov 07, 2016 at 09:12:57AM +, Tvrtko Ursulin wrote:
On 04/11/2016 15:11, Chris Wilson wrote:
On Fri, Nov 04, 2016 at 02:44:44PM +, Tvrtko Ursulin wrote:
On 03/11/2016 11:55, Chris Wilson wrote:
On Thu, Nov 03, 2016 at 11:03:47AM +000
Op 02-11-16 om 10:32 schreef Mika Kahola:
> This is a testcase with multiple planes. The idea here is the following
>
> - draw a uniform frame with blue color
> - grab crc for reference
> - put planes randomly on top with the same blue color
> - punch holes with black color into the primary fra
Chris Wilson writes:
> On Mon, Nov 07, 2016 at 02:35:38PM +0200, Mika Kuoppala wrote:
>> We do take execlist spinlock on thread context when
>> we declare gpu to be wedged. Avoid the need to change
>> the spinlock type just for the sake of wedging by
>> removing the spinlock. Keep irqs disabled d
On ma, 2016-11-07 at 10:15 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v5,1/4] drm/i915: Avoid early GPU idling due to
> already pending idle work
> URL : https://patchwork.freedesktop.org/series/14917/
> State : warning
>
> == Summary ==
>
> Series 14917v
On Mon, Nov 07, 2016 at 02:35:38PM +0200, Mika Kuoppala wrote:
> We do take execlist spinlock on thread context when
> we declare gpu to be wedged. Avoid the need to change
> the spinlock type just for the sake of wedging by
> removing the spinlock. Keep irqs disabled during reset
> phase and only
We do take execlist spinlock on thread context when
we declare gpu to be wedged. Avoid the need to change
the spinlock type just for the sake of wedging by
removing the spinlock. Keep irqs disabled during reset
phase and only enable on success path. Also add explicit
disable to setting wedged so th
Hi Jani,
this is sad and also bad news. Means that actually we don't have any
driver which makes the brightness keys on the Fujitsu LIFEBOOK E7x6
series work.
On the other hand I saw that recent patches to intel_opregion.c
introduced quirks based on the DMI strings for some machines. I consider
t
On Mon, Nov 07, 2016 at 01:36:03PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 07, 2016 at 11:01:28AM +, Chris Wilson wrote:
> > + /* Valleyview is definitely limited to scanning out the first
> > +* 512MiB respectively. Lets presume this behaviour was
>
On Mon, Nov 07, 2016 at 02:01:46PM +0200, Joonas Lahtinen wrote:
> On su, 2016-11-06 at 12:59 +, Chris Wilson wrote:
> > We always flush the chipset prior to executing with the GPU, so we can
> > skip the flush during ordinary domain management.
> >
> > Signed-off-by: Chris Wilson
>
> Maybe
On su, 2016-11-06 at 12:59 +, Chris Wilson wrote:
> We always flush the chipset prior to executing with the GPU, so we can
> skip the flush during ordinary domain management.
>
> Signed-off-by: Chris Wilson
Maybe even add?
Fixes: dcd79934b0dd ("drm/i915: Unconditionally flush any chipset bu
On Mon, Nov 07, 2016 at 11:15:40AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Round tile chunks up for constructing partial VMAs
> URL : https://patchwork.freedesktop.org/series/14922/
> State : failure
>
> == Summary ==
>
> Series 14922v1 drm/i915: Round tile chunks
On Fri, Nov 04, 2016 at 05:45:36PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Remove the vma from the object list upon close
> URL : https://patchwork.freedesktop.org/series/14850/
> State : failure
>
> == Summary ==
>
> Series 14850v1 drm/i915: Remove the vma from th
1 - 100 of 132 matches
Mail list logo
