Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index ddc4859..bf0195a 100644
---
This is prep work for some yet to be named stuff I'm trying out. I think
it ended up standing well on its own, so I decided to submit it for
consideration on it's own. Basically it just cleans up the special
allocation of the pipe control, as I intend to do a bit in that area.
Daniel, if you
mostly for convenience, this will help us clear up a bit of the code in
intel_ringbuffer.c
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 3 +++
2 files changed, 4 insertions(+)
diff --git
There is duplication here. Even more will be coming.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 94 +++--
1 file changed, 53 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
This is precursor to some work I'm doing, but I think it stands nicely
as its own refactor.
v2: skip teardown returning on success (BUG)
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem.c | 36
It's all redundant with the object now. Simply store that.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 58 -
1 file changed, 13 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
On Sat, Jun 30, 2012 at 08:50:10PM +0200, Olivier Galibert wrote:
This is the first part of the fixes I've done to make my gm45 work
correctly w.r.t clipping and interpolation. There's a fair chance
they work for everything gen 4/5, but I have no way to be sure.
So, not even one comment,
On Thu, 12 Jul 2012 23:16:13 -0700, Ben Widawsky b...@bwidawsk.net wrote:
mostly for convenience, this will help us clear up a bit of the code in
intel_ringbuffer.c
I don't think your couple of use-cases is a strong enough argument to
justify an extra pointer on thousands of objects.
If you
On Thu, Jul 12, 2012 at 09:07:52PM +0100, Chris Wilson wrote:
On Thu, 12 Jul 2012 21:37:16 +0200, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Jul 12, 2012 at 04:13:36PM +0100, Chris Wilson wrote:
obj-base.write_domain = 0;
- list_del_init(obj-gpu_write_list);
+
On Fri, 13 Jul 2012 10:34:43 +0200, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Jul 12, 2012 at 09:07:52PM +0100, Chris Wilson wrote:
On Thu, 12 Jul 2012 21:37:16 +0200, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Jul 12, 2012 at 04:13:36PM +0100, Chris Wilson wrote:
On Fri, 13 Jul 2012 09:49:48 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
No. Because by the time the previous breadcrumb has been seen we are
guarranteed to have flushed the gpu caches. So any wait in the future we
have flushed the caches before returning.
Egg on face time.
The issue
On Fri, Jul 13, 2012 at 09:53:33AM +0100, Chris Wilson wrote:
On Fri, 13 Jul 2012 09:49:48 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
No. Because by the time the previous breadcrumb has been seen we are
guarranteed to have flushed the gpu caches. So any wait in the future we
have
On Thu, Jul 12, 2012 at 04:13:35PM +0100, Chris Wilson wrote:
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
I'd like to keep the analysis of why things blow up on the BUG_ON(seqno ==
0) here in the commit message, i.e. the two patches that together caused
the regression (I think we need
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
Or going from tiled to untiled may break.
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/intel_sprite.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
This is turning into a dinq BUG_ON special. Have fun!
-chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
If we drop the breadcrumb request after a batch due to a signal for
example we aim to fix it up at the next opportunity. In this case we
emit a second batchbuffer with no waits upon the first and so no
opportunity to insert the missing request, so we need to emit the
missing flush for coherency.
This is now handled by a global flag to ensure we emit a flush before
the next serialisation point (if we failed to queue one previously).
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h|2 --
drivers/gpu/drm/i915/i915_gem.c|
Rely instead on the insertion of the implicit flush before the seqno
breadcrumb.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c | 34 --
1 file changed, 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c
By moving the function to intel_ringbuffer and currying the appropriate
parameter, hopefully we make the callsites easier to read and
understand.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h|3 ---
drivers/gpu/drm/i915/i915_gem.c
This moves the open-coded handling of the write seqno from the
execbuffer dispatch into the core logic alongside the read seqno
handling.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c|9 +
drivers/gpu/drm/i915/i915_gem_context.c
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_context.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
Now that we unconditionally flush and invalidate between every batch
buffer, we no longer need the complex logic to decide which domains
require flushing. Remove it and rejoice.
One side-effect is that this also removes the broken wait-on-pending-flip
logic.
Signed-off-by: Chris Wilson
As we guarantee to emit a flush before emitting the breadcrumb or
the next batchbuffer, there is no further need for the flushing list.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c |7
drivers/gpu/drm/i915/i915_drv.h | 19
As the flush is either performed explictly immediately after the
execbuffer dispatch, or before the serialisation of last_fenced_seqno we
can forgo the explict i915_gem_flush_ring().
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c | 16 ++--
Otherwise we end up trying to unpin a freed object and BUG.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_context.c | 82 +++
1 file changed, 30 insertions(+), 52 deletions(-)
diff --git
As we always flush the GPU cache prior to emitting the breadcrumb, we no
longer have to worry about the deferred flush causing the
pending_gpu_write to be delayed. So we can instead utilize the known
last_write_seqno to hopefully minimise the wait times.
Signed-off-by: Chris Wilson
Otherwise once we use the buffer with a BLT command on gen2/3, we will
always regard future command submissions as continuing the fenced
access. However, now that we flush/invalidate between every batch we can
drop this pessimism.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
Request preallocation was added to i915_add_request() in order to
support the overlay. However, not all users care and can quite happily
ignore the failure to allocate the request as they will simply repeat
the request in the future.
By pushing the allocation down into i915_add_request(), we can
On Fri, 13 Jul 2012 15:50:33 +0300, Ander Conselvan de Oliveira
conselv...@gmail.com wrote:
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
Or going from tiled to untiled may break.
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
On Fri, 13 Jul 2012 08:47:15 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Thu, 12 Jul 2012 23:16:13 -0700, Ben Widawsky b...@bwidawsk.net wrote:
mostly for convenience, this will help us clear up a bit of the code in
intel_ringbuffer.c
I don't think your couple of use-cases is a
On Fri, 13 Jul 2012 06:56:44 -0700, Ben Widawsky b...@bwidawsk.net wrote:
On Fri, 13 Jul 2012 08:47:15 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Thu, 12 Jul 2012 23:16:13 -0700, Ben Widawsky b...@bwidawsk.net wrote:
mostly for convenience, this will help us clear up a bit of
On Fri, Jul 13, 2012 at 02:26:54PM +0100, Chris Wilson wrote:
On Fri, 13 Jul 2012 15:50:33 +0300, Ander Conselvan de Oliveira
conselv...@gmail.com wrote:
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
Or going from tiled to untiled may break.
Signed-off-by:
On Fri, 13 Jul 2012 14:14:05 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
Otherwise we end up trying to unpin a freed object and BUG.
Just a quick excuse: originally do_switch was just a very low level
helper, and everything called i915_switch_context (including default
setup), so the
On Fri, 13 Jul 2012 14:14:04 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky b...@bwidawsk.net
I guess setting the read_domains is now superfluous.
Reviewed-by: Ben Widawsky b...@bwidawsk.net
---
On Fri, Jul 13, 2012 at 02:14:05PM +0100, Chris Wilson wrote:
Otherwise we end up trying to unpin a freed object and BUG.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky b...@bwidawsk.net
Afact this patch contains quite some code refactoring that does not
relate
On Fri, Jul 13, 2012 at 02:14:07PM +0100, Chris Wilson wrote:
As we always flush the GPU cache prior to emitting the breadcrumb, we no
longer have to worry about the deferred flush causing the
pending_gpu_write to be delayed. So we can instead utilize the known
last_write_seqno to hopefully
On Fri, Jul 13, 2012 at 02:14:08PM +0100, Chris Wilson wrote:
If we drop the breadcrumb request after a batch due to a signal for
example we aim to fix it up at the next opportunity. In this case we
emit a second batchbuffer with no waits upon the first and so no
opportunity to insert the
On Fri, Jul 13, 2012 at 02:14:04PM +0100, Chris Wilson wrote:
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_context.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git
On Fri, Jul 13, 2012 at 5:59 PM, Guo Tang guo.t...@sonoartis.com wrote:
Hi,
Greetings!
I have a system with GM 45 chip set. I want to have 3 displays: LVDS, VGA,
and TV output. There is no need for
them to show different contents. So only clone display is required. From GM
45 chip set spec,
Hi, Daniel,
Thanks for the prompt reply. From your reply looks like I still have a
little hope.
How about if I only run 1024x768@60Hz or 30Hz resolution? Will that address
the dotclock problem
between LVDS and TV?
Thanks,
Guo
On Fri, Jul 13, 2012 at 9:10 AM, Daniel Vetter dan...@ffwll.ch
On Fri, Jul 13, 2012 at 6:36 PM, Guo Tang guo.t...@sonoartis.com wrote:
Hi, Daniel,
Thanks for the prompt reply. From your reply looks like I still have a
little hope.
How about if I only run 1024x768@60Hz or 30Hz resolution? Will that address
the dotclock problem
between LVDS and TV?
As
Great! Thanks for the direction. We will give it a shoot!
- Guo
On Fri, Jul 13, 2012 at 9:38 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Fri, Jul 13, 2012 at 6:36 PM, Guo Tang guo.t...@sonoartis.com wrote:
Hi, Daniel,
Thanks for the prompt reply. From your reply looks like I still have a
Hi Dave,
New pull for -next. Highlights:
- rc6/turbo support for hsw (Eugeni)
- improve corner-case of the reset handling code - gpu reset handling
should be rock-solid now
- support for fb offset 4096 pixels on gen4+ (yeah, you need some fairly
big screens to hit that)
- the Flush Me Harder
On Thu, Jul 12, 2012 at 11:16:12PM -0700, Ben Widawsky wrote:
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
On 07/13/2012 12:20 AM, Olivier Galibert wrote:
On Sat, Jun 30, 2012 at 08:50:10PM +0200, Olivier Galibert wrote:
This is the first part of the fixes I've done to make my gm45 work
correctly w.r.t clipping and interpolation. There's a fair chance
they work for everything gen 4/5, but I have
I wouldn't ask here, except Bugzilla seems stuck on unreachable. Anyone know
when it should be back online? Anyone know the status of panning? For me,
mouse cannot move into the extended area, so only content can't go there, not
my eyes.
--
The wise are known for their understanding, and
46 matches
Mail list logo
