On Mon, Aug 26, 2013 at 02:51:53PM +0100, Chris Wilson wrote:
> When we switched to always using a timeout in conjunction with
> wait_seqno, we lost the ability to detect missed interrupts. Since, we
> have had issues with interrupts on a number of generations, and they are
> required to be deliver
Hi Paulo,
There are some changes in voltage swing levels for Haswell platform. In current
implementation, macro name are given after the swing values. But the values are
changed for Haswell. This comment is added to avoid the confusion during signal
level debug or other similar kind of activity.
Rinat Ibragimov writes:
> Понедельник, 26 августа 2013, 13:40 -07:00 от Eric Anholt :
>> Ибрагимов Ринат writes:
>>
>> > libvdpau uses second DRI driver name to determine which VDPAU driver
>> > to use. This patch will allow libvdpau choose libvdpau_i965.so on systems
>> > with Intel GPUs, libv
On Mon, Aug 26, 2013 at 07:51:08PM -0300, Rodrigo Vivi wrote:
> From: Chris Wilson
>
> If we encounter a situation where the CPU blocks waiting for results
> from the GPU, give the GPU a kick to boost its the frequency.
>
> This should work to reduce user interface stalls and to quickly promote
Full HSW GT3 power can only be achieved with all Execution Units turned on.
This patch enables all EUs present on HSW GT3 by enabling lower slice.
Credits-by: Yejun Guo
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 5 +
drivers/gpu
From: Chris Wilson
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
st
From: Chris Wilson
In order to time how long a seqno is executed by a ring, we need to
measure both its insertion and its completion. (Using the completion of
the previous seqno as an estimate for when the GPU starts, if busy.) In
order to get an exact completion timestamp, we need irqs. This is
From: Chris Wilson
A simple modeset, where we only wish to switch over to a new framebuffer
such as the transition from fbcon to X, takes around 30-60ms. This is
due to three factors:
1. We need to make sure the fb->obj is in the display domain, which
incurs a cache flush to ensure no dirt is le
From: Chris Wilson
It appears that Valleyview shares its VGA encoder with more recent
siblings and requires the same forced detection cycle after a hardware
reset before we can rely on hotplugging.
Reported-and-tested-by: kobeqin
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67733
Sign
From: Chris Wilson
For unfathomable reasons this alignment appears to be required for tiled
scanouts being read from stolen memory. I can find no reference in the
w/a db to support this requirement, but the evidence of my own eyes says
this prevents many headaches.
Note that I have not tricked a
From: Chris Wilson
We missed adding a few cleanup steps for recent additions.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_dma.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma
From: Chris Wilson
We only wish to know the value of seqno when emitting the tracepoint, so
move the query from a parameter to the macro to inside the conditional
macro body so that the query is only evaluated when required.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c |
From: Chris Wilson
It can be useful to compare at times the current vs requested frequency
of the GPU, so provide the contents of RPNSWREQ alonside CAGF.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff
From: Chris Wilson
A follow-on to the update of the LLC coherency logic is that we can rely
on the LLC being coherent with the CS for rewriting batchbuffers
irrespective of their cache domain. (This should have no effect
currently as all the batch buffers are expected to be I915_CACHE_LLC and
so
From: Jesse Barnes
Systems with Intel graphics controllers set aside memory exclusively for
gfx driver use. This memory is not always marked in the E820 as
reserved or as RAM, and so is subject to overlap from E820 manipulation
later in the boot process. On some systems, MMIO space is allocated
From: Jesse Barnes
For use by userspace (at some point in the future) and other kernel code.
v2: move PCI IDs to uabi (Chris)
move PCI IDs to drm/ (Dave)
v3: fixup Quanta detection - needs to come first (Daniel)
v4: fix up PCI match structure init for easier use by userspace (Chris)
Signed-
From: Chris Wilson
Upon resume we will do a complete restoration of the mode and so reset
all tasks, but during suspend (and unload) we need to make sure that no
workers run concurrently with our suspend code. Or worse just after.
The issue was first raised whilst tackling a suspend issue with T
From: Daniel Vetter
In truly crazy circumstances shmem might give us the wrong type of
page. So be a bit paranoid and double check this.
Cc: Rob Clark
References: http://lkml.org/lkml/2011/7/11/238
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 3 +++
1 file changed, 3 ins
From: Chris Wilson
As we attempt to kmalloc after calling get_pages, there is a possibility
that the shrinker may reap the pages we just acquired. To prevent this
we need to increment the pages_pin_count early, so rearrange the code
and error paths to make it so.
Signed-off-by: Chris Wilson
---
From: Chris Wilson
The comments were a little out-of-sequence with the code, forcing the
reader to jump around whilst reading. Whilst moving the comments around,
add one to explain the context reference.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 7 +--
1 file change
From: Chris Wilson
We use the request to ensure we hold a reference to the context for the
duration that it remains in use by the ring. Each request only holds a
reference to the current context, hence we emit a request after
switching contexts with the final reference to the old context. However
Hi all,
Let me introduce drm-intel-collector branch:
http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector
To describe drm-intel-collector I'll quote Daniel:
"The overall idea is to make sure that simple patches don't get lost.
Bigger patch series or feature work tends to not
Ben complained in his review of write RING_TAIL once per request that
intel_ring_advance() did nothing and was confusing with
__intel_ring_advance() doing the hard work. This patch drops the
intel_ring_advance(), and renames __intel_ring_advance() to
intel_ring_commit(). We go one step further and
Понедельник, 26 августа 2013, 13:40 -07:00 от Eric Anholt :
> Ибрагимов Ринат writes:
>
> > libvdpau uses second DRI driver name to determine which VDPAU driver
> > to use. This patch will allow libvdpau choose libvdpau_i965.so on systems
> > with Intel GPUs, libvdpau_nvidia.so on those with nVid
On Mon, Aug 26, 2013 at 01:43:25PM -0700, Stéphane Marchesin wrote:
>On Mon, Aug 26, 2013 at 1:42 PM, St�phane Marchesin
><[1]stephane.marche...@gmail.com> wrote:
>
> On Mon, Aug 26, 2013 at 12:58 PM, Chris Wilson
> <[2]ch...@chris-wilson.co.uk> wrote:
>
>RCS flips do wo
On Mon, Aug 26, 2013 at 1:42 PM, Stéphane Marchesin <
stephane.marche...@gmail.com> wrote:
>
>
>
> On Mon, Aug 26, 2013 at 12:58 PM, Chris Wilson
> wrote:
>
>> RCS flips do work on Iybridge+ so long as we can unmask the messages
>> through DERRMR. However, there are quite a few workarounds mentio
On Sat, Aug 10, 2013 at 10:16:32PM +0100, Chris Wilson wrote:
> Ignoring the legacy DRI1 code, and a couple of special cases (to be
> discussed later), all access to the ring is mediated through requests.
> The first write to a ring will grab a seqno and mark the ring as having
> an outstanding_laz
On Mon, Aug 26, 2013 at 12:58 PM, Chris Wilson wrote:
> RCS flips do work on Iybridge+ so long as we can unmask the messages
> through DERRMR. However, there are quite a few workarounds mentioned
> regarding unmasking more than one event or triggering more than one
> message through DERRMR. Those
Ибрагимов Ринат writes:
> libvdpau uses second DRI driver name to determine which VDPAU driver
> to use. This patch will allow libvdpau choose libvdpau_i965.so on systems
> with Intel GPUs, libvdpau_nvidia.so on those with nVidia ones, and so on.
> I'm experimenting now with generic vdpau driver
RCS flips do work on Iybridge+ so long as we can unmask the messages
through DERRMR. However, there are quite a few workarounds mentioned
regarding unmasking more than one event or triggering more than one
message through DERRMR. Those workarounds in principle prevent us from
performing pipelined f
We now have more devices using ring->private than not, and they all want
the same structure. Worse, I would like to use a scratch page from
outside of intel_ringbuffer.c and so for convenience would like to reuse
ring->private. Embed the object into the struct intel_ringbuffer so that
we can keep t
2013/8/26 Koushik Biswas :
> From: koushik
>
> WW43 2012 - DDI buffer translation corrections
> WW36 2012 - Added HDMI voltage swing (not implemented
> for HDMI)
>
> Added comments with voltage swing, pre-emphasis,
> transition and non-transition values in form of table
> for refer
On Mon, Aug 26, 2013 at 04:18:54PM +0100, Chris Wilson wrote:
> Valleyview has its own render power state implementation with different
> capability knobs - it has no RP0,RP1,RPn but rather RPe.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67734
> Signed-off-by: Chris Wilson
> Teste
On Mon, Aug 26, 2013 at 10:36:35AM +0100, Chris Wilson wrote:
> On Mon, Aug 26, 2013 at 11:23:47AM +0200, Daniel Vetter wrote:
> > The important bugfix here is that we must not unlink the vma when
> > we keep it around as a placeholder for the execbuf code. Since then we
> > won't find it again whe
On Mon, Aug 26, 2013 at 10:05:36AM -0600, Alex Williamson wrote:
> On Mon, 2013-08-26 at 15:23 +0300, Ville Syrjälä wrote:
> > On Sat, Aug 24, 2013 at 08:53:40AM -0600, Alex Williamson wrote:
> > > This is intended to add VGA arbiter support for Intel HD graphics on
> > > Core processors. The old
On Mon, Aug 26, 2013 at 04:05:11PM +0300, Michael S. Tsirkin wrote:
> On Wed, Aug 21, 2013 at 11:22:58AM +0200, Sedat Dilek wrote:
> > [ Re: [Intel-gfx] i915 producing warnings with kernel 3.11-rc5 ]
> >
> > Hi,
> >
> > saw your posting in [1]... can you try the patches below?
> > Not sure if the
On Mon, 2013-08-26 at 15:23 +0300, Ville Syrjälä wrote:
> On Sat, Aug 24, 2013 at 08:53:40AM -0600, Alex Williamson wrote:
> > This is intended to add VGA arbiter support for Intel HD graphics on
> > Core processors. The old GMCH registers no longer exist, so even
> > though it appears that i915 p
Valleyview has its own render power state implementation with different
capability knobs - it has no RP0,RP1,RPn but rather RPe.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67734
Signed-off-by: Chris Wilson
Tested-by: kobe@intel.com
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i9
When we switched to always using a timeout in conjunction with
wait_seqno, we lost the ability to detect missed interrupts. Since, we
have had issues with interrupts on a number of generations, and they are
required to be delivered in a timely fashion for a smooth UX, it is
important that we do log
Since we are waiting upon IO completion, inform the kernel through use
of the io_schedule() call rather than the regular schedule(). This
should allow the kernel to make better decisions regarding scheduling
and power management.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c |
Daniel is pushing for something like this upstream so that we can catch
missed interrupts again. This contains the compromise for Ben and Jesse,
and should work even better than before with absent interrupts.
I'm not thrilled by the test_/missed_irq debugfs interface, it is a little
racy, but I di
So that we can find the callers who introduce a ring stall. A single
ring stall is not too unwelcome, the right issue becomes when they start
to interlock and prevent any concurrent work. That, however, is a little
tricker to detect with a mere tracepoint!
v2: Rebrand it as a ring event, rather th
On Mon, Aug 26, 2013 at 04:20:06PM +0300, Ville Syrjälä wrote:
> On Mon, Aug 26, 2013 at 01:46:21PM +0100, Chris Wilson wrote:
> > So that we can find the callers who introduce a ring stall. A single
> > ring stall is not too unwelcome, the right issue becomes when they start
> > to interlock and p
On Mon, Aug 26, 2013 at 01:46:21PM +0100, Chris Wilson wrote:
> So that we can find the callers who introduce a ring stall. A single
> ring stall is not too unwelcome, the right issue becomes when they start
> to interlock and prevent any concurrent work. That, however, is a little
> tricker to det
On Mon, Aug 26, 2013 at 01:45:56PM +0100, Chris Wilson wrote:
> The RPS register writing routines use the current value of min/max to
> set certain limits and interrupt gating. If we set those afterwards, we
> risk setting up the hw incorrectly and losing power management events,
> and worse, trigg
On Wed, Aug 21, 2013 at 11:22:58AM +0200, Sedat Dilek wrote:
> [ Re: [Intel-gfx] i915 producing warnings with kernel 3.11-rc5 ]
>
> Hi,
>
> saw your posting in [1]... can you try the patches below?
> Not sure if they apply.
> Did you try v3.11-rc6(+)... or drm-intel-nightly?
>
> Regards,
> - Sed
Signed-off-by: Chris Wilson
---
tests/Makefile.am | 1 +
tests/ZZ_missed_irq | 70 +
2 files changed, 71 insertions(+)
create mode 100755 tests/ZZ_missed_irq
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 9878a25..e258b1f 100644
-
So that we can find the callers who introduce a ring stall. A single
ring stall is not too unwelcome, the right issue becomes when they start
to interlock and prevent any concurrent work. That, however, is a little
tricker to detect with a mere tracepoint!
Signed-off-by: Chris Wilson
---
drivers
Obtaining the forcwake requires expensive and time consuming
serialisation. And we often try to obtain the forcewake multiple times
in very quick succession. We can reduce the overhead of these sequences
by delaying the forcewake release, and so not hammer the hw quite so
hard.
I was hoping this w
The RPS register writing routines use the current value of min/max to
set certain limits and interrupt gating. If we set those afterwards, we
risk setting up the hw incorrectly and losing power management events,
and worse, trigger some internal assertions.
Reorder the calling sequences to be corr
On Sat, Aug 24, 2013 at 08:53:40AM -0600, Alex Williamson wrote:
> This is intended to add VGA arbiter support for Intel HD graphics on
> Core processors. The old GMCH registers no longer exist, so even
> though it appears that i915 participates in VGA arbitration, it doesn't
> work. On Intel HD
On Mon, Aug 26, 2013 at 12:06:43PM +0100, Chris Wilson wrote:
> Obtaining the forcwake requires expensive and time consuming
> serialisation. And we often try to obtain the forcewake multiple times
> in very quick succession. We can reduce the overhead of these sequences
> by delaying the forcewake
Obtaining the forcwake requires expensive and time consuming
serialisation. And we often try to obtain the forcewake multiple times
in very quick succession. We can reduce the overhead of these sequences
by delaying the forcewake release, and so not hammer the hw quite so
hard.
I was hoping this w
On Mon, Aug 26, 2013 at 11:16:40AM +0300, Ville Syrjälä wrote:
> On Sun, Aug 25, 2013 at 04:35:52AM +, Kannan, Vandana wrote:
> > Hi,
> >
> > For sprite performance improvement, instead of the patch
> > "drm/i915: Don't wait for vblank for sprite plane flips", we made use of
> >
From: Mengdong Lin
This patch exposes is_haswell() to python, to be used by device auto-detection.
Signed-off-by: Mengdong Lin
diff --git a/tools/quick_dump/chipset.i b/tools/quick_dump/chipset.i
index 69dc8df..4b13487 100644
--- a/tools/quick_dump/chipset.i
+++ b/tools/quick_dump/chipset.i
@@
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do n
After applying wait-boost we often find ourselves stuck at higher clocks
than required. The current threshold value requires the GPU to be
continuously and completely idle for 313ms before it is dropped by one
bin. Conversely, we require the GPU to be busy for an average of 90% over
a 84ms period b
On Sun, Aug 25, 2013 at 08:45:34PM +0100, Chris Wilson wrote:
> Obtaining the forcwake requires expensive and time consuming
> serialisation. And we often try to obtain the forcewake multiple times
> in very quick succession. We can reduce the overhead of these sequences
> by delaying the forcewake
Hi all, I'm using haswell with linux-3.8.13.4:
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=commitdiff;h=d1baa1360260b5a01938674fc518109a4e5a148d
and I find the CAGF showed by i915_cur_delayinfo is always twice as
gt_cur_freq_mhz, e.g., when the system is idle, I can get the below log:
-
On Mon, Aug 26, 2013 at 11:23:47AM +0200, Daniel Vetter wrote:
> The important bugfix here is that we must not unlink the vma when
> we keep it around as a placeholder for the execbuf code. Since then we
> won't find it again when execbuf gets interrupt and restarted and
> create a 2nd vma. And sin
On Mon, Aug 26, 2013 at 11:23:47AM +0200, Daniel Vetter wrote:
> The important bugfix here is that we must not unlink the vma when
> we keep it around as a placeholder for the execbuf code. Since then we
> won't find it again when execbuf gets interrupt and restarted and
> create a 2nd vma. And sin
The important bugfix here is that we must not unlink the vma when
we keep it around as a placeholder for the execbuf code. Since then we
won't find it again when execbuf gets interrupt and restarted and
create a 2nd vma. And since the code as-is isn't fit yet to deal with
more than one vma, hilarit
On Mon, Aug 26, 2013 at 9:43 AM, Ville Syrjälä
wrote:
> My quick and dirty idea for runtime PM would be something like this:
> - for ioctls just slap rpm_get_sync/put() around drm_ioctl,
> not optimal but it's very easy for getting started
> - all sysfs/debugfs stuff would need to be handled ind
On Mon, Aug 26, 2013 at 10:16 AM, Ville Syrjälä
wrote:
> Maybe someone should just start pulling in the drm_flip_helper and
> associated code from the atomic code to make this feasible. The new
> event type I added there would also be suitable for this purpose as
> it carries the plane id and info
On Sun, Aug 25, 2013 at 04:35:52AM +, Kannan, Vandana wrote:
> Hi,
>
> For sprite performance improvement, instead of the patch
> "drm/i915: Don't wait for vblank for sprite plane flips", we made use of
> Chris Wilson's patches from "RFC asynchronous vblank tasks" and verified th
On Fri, Aug 23, 2013 at 05:14:00PM -0300, Paulo Zanoni wrote:
> 2013/8/23 Ville Syrjälä :
> > On Fri, Aug 23, 2013 at 04:41:57PM -0300, Paulo Zanoni wrote:
> >> 2013/8/23 Kristen Carlson Accardi :
> >> > On Fri, 23 Aug 2013 13:44:17 -0300
> >> > Paulo Zanoni wrote:
> >> >
> >> >> 2013/8/23 Jani Ni
On Fri, Aug 23, 2013 at 04:52:30PM +0300, Mika Kuoppala wrote:
> In reset we try to restore the forcewake state to
> pre reset state, using forcewake_count. The reset
> doesn't seem to clear the forcewake bits so we
> get warn on forcewake ack register not clearing.
>
> Use same mechanism as intel
Ping.
Пятница, 16 августа 2013, 14:31 +04:00 от Ибрагимов
Ринат:
> libvdpau uses second DRI driver name to determine which VDPAU driver
> to use. This patch will allow libvdpau choose libvdpau_i965.so on systems
> with Intel GPUs, libvdpau_nvidia.so on those with nVidia ones, and so on.
> I'm ex
On Fri, Aug 23, 2013 at 02:08:11AM +0200, Daniel Vetter wrote:
> The important bugfix here is that we must not unlink the vma when
> we keep it around as a placeholder for the execbuf code. Since then we
> won't find it again when execbuf gets interrupt and restarted and
> create a 2nd vma. And sin
69 matches
Mail list logo
