On Sun, 7 Oct 2012 08:51:07 -0700, Kenneth Graunke kenn...@whitecape.org
wrote:
A previous patch, namely:
commit bf97b276ca04cee9ab65ffd378fa8e6aedd71ff6
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Wed Apr 11 20:42:41 2012 +0200
drm/i915: implement w/a for incorrect
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
On Tue, Oct 09, 2012 at 10:43:10AM +0300, Mika Kuoppala wrote:
On Sun, 7 Oct 2012 08:51:07 -0700, Kenneth Graunke kenn...@whitecape.org
wrote:
A previous patch, namely:
commit bf97b276ca04cee9ab65ffd378fa8e6aedd71ff6
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Wed Apr 11
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
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
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
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
On Fri, 2012-10-05 at 12:14 -0400, Kristian Høgsberg wrote:
On Fri, Oct 5, 2012 at 9:36 AM, Imre Deak imre.d...@intel.com 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
On Tue, 9 Oct 2012 11:54:12 +0200, Daniel Vetter dan...@ffwll.ch 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 ch...@chris-wilson.co.uk 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
From: Damien Lespiau damien.lesp...@intel.com
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 damien.lesp...@intel.com
---
drivers/gpu/drm/drm_modes.c |1 +
1 files changed, 1 insertions(+), 0
On Tue, 9 Oct 2012 13:14:09 +0200, Daniel Vetter dan...@ffwll.ch 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
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 ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c |3 +++
1 file
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
Although default case is a bug, being conservative on the initialization helps
to shut up coverity scan.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Tue, 9 Oct 2012 14:49:06 -0300, Rodrigo Vivi rodrigo.v...@gmail.com 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
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
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:
Hopefully this will reduce a few of the missed IRQ warnings.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
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
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 it
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 daniel.vet...@ffwll.ch
---
2012/10/9 ron minnich rminn...@gmail.com:
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
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 daniel.vet...@ffwll.ch
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.
On Tue, Oct 9, 2012 at 12:35 PM, Paulo Zanoni przan...@gmail.com 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
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 hangman
On Tue, 9 Oct 2012 22:50:48 +0200, Daniel Vetter daniel.vet...@ffwll.ch
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
27 matches
Mail list logo
