On Sun, 7 Oct 2012 08:51:07 -0700, Kenneth Graunke
wrote:
> A previous patch, namely:
>
> commit bf97b276ca04cee9ab65ffd378fa8e6aedd71ff6
> Author: Daniel Vetter
> Date: Wed Apr 11 20:42:41 2012 +0200
>
> drm/i915: implement w/a for incorrect guarband clipping
>
> accidentally set bit
With a fence, we only need to insert a memory barrier around the actual
fence alteration for CPU accesses through the GTT. Performing the
barrier in flush-fence was inserting unnecessary and expensive barriers
for never fenced objects.
Note removing the barriers from flush-fence, which was effecti
On Tue, Oct 09, 2012 at 10:43:10AM +0300, Mika Kuoppala wrote:
> On Sun, 7 Oct 2012 08:51:07 -0700, Kenneth Graunke
> wrote:
> > A previous patch, namely:
> >
> > commit bf97b276ca04cee9ab65ffd378fa8e6aedd71ff6
> > Author: Daniel Vetter
> > Date: Wed Apr 11 20:42:41 2012 +0200
> >
> > d
During execbuffer emission we assert that we do not wrap around the
seqno used for semaphore breadcrumbs. However:
:kernel BUG at drivers/gpu/drm/i915/i915_gem_execbuffer.c:1239!
:invalid opcode: [#1] SMP
:CPU 0
:Modules linked in: usb_storage usblp bnep lockd sunrpc bluetooth rfkill
vboxpci
During execbuffer emission we assert that we do not wrap around the
seqno used for semaphore breadcrumbs. However:
:kernel BUG at drivers/gpu/drm/i915/i915_gem_execbuffer.c:1239!
:invalid opcode: [#1] SMP
:CPU 0
:Modules linked in: usb_storage usblp bnep lockd sunrpc bluetooth rfkill
vboxpci
On Tue, Oct 09, 2012 at 09:38:58AM +0100, Chris Wilson wrote:
> With a fence, we only need to insert a memory barrier around the actual
> fence alteration for CPU accesses through the GTT. Performing the
> barrier in flush-fence was inserting unnecessary and expensive barriers
> for never fenced ob
While looking at barriers, I think we could be a bit more paranoid with
the barrier in intel_read_status_page and up it to a full mb() and move it
into the !lazy_coherency conditional of the various get_seqno functions.
-Daniel
On Tue, Oct 09, 2012 at 11:54:12AM +0200, Daniel Vetter wrote:
> On Tu
On Fri, 2012-10-05 at 12:14 -0400, Kristian Høgsberg wrote:
> On Fri, Oct 5, 2012 at 9:36 AM, Imre Deak wrote:
> > Needed by the upcoming DRM raw monotonic timestamp support.
>
> I just had a quick look at driver/input/evdev.c, since evdev devices
> did a similar change recently to allow evdev ti
On Tue, 9 Oct 2012 11:54:12 +0200, Daniel Vetter wrote:
> On Tue, Oct 09, 2012 at 09:38:58AM +0100, Chris Wilson wrote:
> > @@ -3244,6 +3254,9 @@ i915_gem_object_set_to_gtt_domain(struct
> > drm_i915_gem_object *obj, bool write)
> >
> > i915_gem_object_flush_cpu_write_domain(obj);
> >
> >
On Tue, Oct 9, 2012 at 1:03 PM, Chris Wilson wrote:
> In fact, not only is that the wmb() the easiest to micro-optimise, it
> is the only one that can be - I think. Around manipulating the fence, we
> need a read/write barrier in case we have any pending accesses through
> the fenced region, since
From: Damien Lespiau
As we parse the string given on the command line one char at a time, it
seems that we do want a break at every case.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_modes.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_m
On Tue, 9 Oct 2012 13:14:09 +0200, Daniel Vetter wrote:
> One thing I wonder is whether we miss any barrier between the wc
> writes to the ringbuffer and the tail update. If that's the case I
> wonder where all the bug reports are ...
Ditto. I've often wondered how we get away without a wmb() the
As a precaution against the driver fouling up and missing a hang leaving
the caller in an indefinite wait, manually inspect for a GPU hang if we
timeout whilst waiting for a seqno.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c |3 +++
1 file changed, 3 insertions(+)
diff -
I have a display that is, e.g., 2560x1600 on an ivybridge. I'd like to
set it up so that the software sees a display with half that
resolution, i.e. the software that draws into the frame buffer (this
is a bios) can draw into what it sees as a 1280x800 display.
I've tried a few things but I'm real
Although default case is a bug, being conservative on the initialization helps
to shut up coverity scan.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers
On Tue, 9 Oct 2012 14:49:06 -0300, Rodrigo Vivi wrote:
> Although default case is a bug, being conservative on the initialization
> helps to shut up coverity scan.
>
So many more issues would be resolved if you taught coverity that BUG()
was noreturn. :-p
-Chris
--
Chris Wilson, Intel Open So
With a fence, we only need to insert a memory barrier around the actual
fence alteration for CPU accesses through the GTT. Performing the
barrier in flush-fence was inserting unnecessary and expensive barriers
for never fenced objects.
Note removing the barriers from flush-fence, which was effecti
Now that we seem to have brought order to the GTT barriers, the last one
to review is the terminal barrier before we unbind the buffer from the
GTT. This needs to only be performed if the buffer still resides in the
GTT domain, and so we can skip some needless barriers otherwise.
Signed-off-by: Ch
We need to treat the GPU core as a distinct processor and so apply the
same SMP memory barriers. In this case, in addition to flushing the
chipset cache, which is a no-op on LLC platforms, apply a write barrier
beforehand. And then when we invalidate the CPU cache, make sure the
memory is coherent
Hopefully this will reduce a few of the missed IRQ warnings.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c |8 +++-
drivers/gpu/drm/i915/intel_ringbuffer.h |2 --
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringb
On Tue, Oct 09, 2012 at 10:40:26AM -0700, ron minnich wrote:
> I have a display that is, e.g., 2560x1600 on an ivybridge. I'd like to
> set it up so that the software sees a display with half that
> resolution, i.e. the software that draws into the frame buffer (this
> is a bios) can draw into what
The obj->pages to obj->pages->sgl rework introduced this helper, but
it doesn't actually work for n % SG_MAX_SINGLE_ALLOC == 0.
This is exercised by the improved hangman tests and the gem_exec_big
test in i-g-t.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file cha
2012/10/9 ron minnich :
> I have a display that is, e.g., 2560x1600 on an ivybridge. I'd like to
> set it up so that the software sees a display with half that
> resolution, i.e. the software that draws into the frame buffer (this
> is a bios) can draw into what it sees as a 1280x800 display.
>
> I
On my new MBA with danvet's drm-intel-next-queued, I'm not getting
working RPS. vblank_mode=0 glxgears never ups the frequency, and
vblank_mode=0 openarena only makes it up to 500mhz. Reverting
1ee9ae3244c4789f3184c5123f3b2d7e405b3f4c gets the machine to responsive
RPS: fully on while the GPU is
On Tue, 9 Oct 2012 19:59:02 +0200, Daniel Vetter
wrote:
> The obj->pages to obj->pages->sgl rework introduced this helper, but
> it doesn't actually work for n % SG_MAX_SINGLE_ALLOC == 0.
>
> This is exercised by the improved hangman tests and the gem_exec_big
> test in i-g-t.
>
> Signed-off-b
On Tue, Oct 9, 2012 at 12:35 PM, Paulo Zanoni wrote:
> Take a look at this tool:
> http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/tools/intel_panel_fitter.c
very interesting!
i note that tool sets WIN_POS and WIN_SZ, but not the HSCALE and
VSCALE ... is there something I'm not unders
The obj->pages to obj->pages->sgl rework introduced this helper, but
it doesn't actually work for n >= SG_MAX_SINGLE_ALLOC.
For simplicity (and since right now I seem to be too stupid to see
the bug), let's just grab the right page with a for_each_sg loop.
This is exercised by the improved hangma
On Tue, 9 Oct 2012 22:50:48 +0200, Daniel Vetter
wrote:
> The obj->pages to obj->pages->sgl rework introduced this helper, but
> it doesn't actually work for n >= SG_MAX_SINGLE_ALLOC.
>
> For simplicity (and since right now I seem to be too stupid to see
> the bug), let's just grab the right pa
28 matches
Mail list logo
