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 pleas
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
On Thu, Jul 12, 2012 at 11:16:12PM -0700, Ben Widawsky wrote:
> Signed-off-by: Ben Widawsky
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
Intel-gfx@lists.fre
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 Harde
Great! Thanks for the direction. We will give it a shoot!
- Guo
On Fri, Jul 13, 2012 at 9:38 AM, Daniel Vetter wrote:
> On Fri, Jul 13, 2012 at 6:36 PM, Guo Tang wrote:
> > Hi, Daniel,
> >
> > Thanks for the prompt reply. From your reply looks like I still have a
> > little hope.
> >
> > How a
On Fri, Jul 13, 2012 at 6:36 PM, Guo Tang 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 I've said, care
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 wrote:
> On Fri, Jul
On Fri, Jul 13, 2012 at 5:59 PM, Guo Tang 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, looks like only
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, looks like only 2
display ports can be active at the same time. Is it pos
On Fri, Jul 13, 2012 at 02:14:04PM +0100, Chris Wilson wrote:
> Signed-off-by: Chris Wilson
> Cc: Ben Widawsky
> ---
> 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
> b/dr
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 m
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:05PM +0100, Chris Wilson wrote:
> Otherwise we end up trying to unpin a freed object and BUG.
>
> Signed-off-by: Chris Wilson
> Cc: Ben Widawsky
Afact this patch contains quite some code refactoring that does not
relate directly to the fix (or if it does, I fail to
On Fri, 13 Jul 2012 14:14:04 +0100
Chris Wilson wrote:
> Signed-off-by: Chris Wilson
> Cc: Ben Widawsky
I guess setting the read_domains is now superfluous.
Reviewed-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 d
On Fri, 13 Jul 2012 14:14:05 +0100
Chris Wilson 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 bug likely didn't exist
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
> wrote:
> > From: Ander Conselvan de Oliveira
> >
> > Or going from tiled to untiled may break.
> >
> > Signed-off-by: Ander Conselvan de Oliveira
> >
> Reviewed-b
On Fri, 13 Jul 2012 06:56:44 -0700, Ben Widawsky wrote:
> On Fri, 13 Jul 2012 08:47:15 +0100
> Chris Wilson wrote:
>
> > On Thu, 12 Jul 2012 23:16:13 -0700, Ben Widawsky wrote:
> > > mostly for convenience, this will help us clear up a bit of the code in
> > > intel_ringbuffer.c
> >
> > I don'
On Fri, 13 Jul 2012 08:47:15 +0100
Chris Wilson wrote:
> On Thu, 12 Jul 2012 23:16:13 -0700, Ben Widawsky 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
On Fri, 13 Jul 2012 15:50:33 +0300, Ander Conselvan de Oliveira
wrote:
> From: Ander Conselvan de Oliveira
>
> Or going from tiled to untiled may break.
>
> Signed-off-by: Ander Conselvan de Oliveira
>
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_
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 t
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
---
drivers/gpu/drm/i915/i915_gem_exe
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
---
drivers/g
Otherwise we end up trying to unpin a freed object and BUG.
Signed-off-by: Chris Wilson
Cc: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_context.c | 82 +++
1 file changed, 30 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b
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
---
drivers/gpu/drm/i915/i915_gem.c | 16 ++--
1 file changed, 2 insert
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
---
drivers/gpu/drm/i915/i915_debugfs.c |7
drivers/gpu/drm/i915/i915_drv.h | 19 +++
drivers/gpu/drm/i91
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
---
driv
Signed-off-by: Chris Wilson
Cc: Ben Widawsky
---
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
b/drivers/gpu/drm/i915/i915_gem_context.c
index 9ae3f2c..90857f8 100644
--- a/driv
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
---
drivers/gpu/drm/i915/i915_gem.c|9 +
drivers/gpu/drm/i915/i915_gem_context.c|1 -
drivers/gpu
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
---
drivers/gpu/drm/i915/i915_drv.h|3 ---
drivers/gpu/drm/i915/i915_gem.c| 29 +++--
Rely instead on the insertion of the implicit flush before the seqno
breadcrumb.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 34 --
1 file changed, 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_ge
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
---
drivers/gpu/drm/i915/i915_drv.h|2 --
drivers/gpu/drm/i915/i915_gem.c| 53 +
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. (N
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
From: Ander Conselvan de Oliveira
Or going from tiled to untiled may break.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_sprite.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/i
On Thu, Jul 12, 2012 at 04:13:35PM +0100, Chris Wilson wrote:
> Signed-off-by: Chris Wilson
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 both the flushing list pr
On Fri, Jul 13, 2012 at 09:53:33AM +0100, Chris Wilson wrote:
> On Fri, 13 Jul 2012 09:49:48 +0100, Chris Wilson
> 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 cach
On Fri, 13 Jul 2012 09:49:48 +0100, Chris Wilson
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 is on the waiter side
On Fri, 13 Jul 2012 10:34:43 +0200, Daniel Vetter 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 wrote:
> > > On Thu, Jul 12, 2012 at 04:13:36PM +0100, Chris Wilson wrote:
> > > > obj->base.write_domain
On Thu, Jul 12, 2012 at 09:07:52PM +0100, Chris Wilson wrote:
> On Thu, 12 Jul 2012 21:37:16 +0200, Daniel Vetter 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 Thu, 12 Jul 2012 23:16:13 -0700, Ben Widawsky 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 wanted, you could
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, no
It's all redundant with the object now. Simply store that.
Signed-off-by: Ben Widawsky
---
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
b/drivers/gpu/drm/i9
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
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem.c | 36 +-
drivers/gpu/drm/i915/intel_rin
43 matches
Mail list logo
