On Mon, 05 Dec 2011 14:23:55 -0800, Eric Anholt wrote:
> On Mon, 5 Dec 2011 02:31:58 -0800 (PST), ic...@kemper.freedesktop.org (Chris
> Wilson) wrote:
> > configure.ac |2 +-
> > intel/intel_bufmgr_gem.c | 27 +--
> > 2 file
ex numbers
modetest: Do no flip twice to a current front buffer
Chris Wilson (7):
intel: Export CONSTANT_BUFFER addressing mode
intel: Fallback to old exec if no mrb_exec is available
intel: compile fix for previous commit after rebasing
intel: Set the public handle after
ed this to my -fixes queue.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their data
On Fri, 02 Jul 2010 11:54:44 -0400, Keith Packard wrote:
> On Fri, 02 Jul 2010 09:24:07 +0100, Chris Wilson
> wrote:
>
> > This looks like the responsibility of miCloseScreen(). Are we failing to
> > chain up properly?
>
> I don't think miCloseScreen (or fbCl
-> PictureCloseScreen -> fbCloseScreen
and fbCloseScreen supersedes miCloseScreen. So should it not be
fbCloseScreen that calls miCloseScreen, since fb has taken over the
management of the mi interface?
--
Chris Wilson, Intel Open Source Technology Centre
--
rsor image interleaved with the new cursor
> image on a row-by-row basis. Some kind of cache flush issue?
Exactly; a missing move-to-GTT-domain causing the cursor data to remain in
the CPU cache.
https://bugs.freedesktop.org/show_bug.cgi?id=28335
--
Chris Wilso
n off what may be a useful aid in desktop systems.
Also is TRACER the right name, that would seem to confuse the option with
a standalone tracer as opposed to simply enabling tracepoints.
-ickle
--
Chris Wilson, Intel Open Source Technology C
e 2ddd476af89a60fa ]---
Signed-off-by: Chris Wilson
Cc: Dave Airlie
---
drivers/gpu/drm/drm_fops.c | 16 +---
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 08d14df..4804872 100644
--- a/drivers/gpu/drm/drm_fo
bug #15248
Signed-off-by: Jesse Barnes
Cc: sta...@kernel.org
Signed-off-by: Eric Anholt
The Sony has a GMA 900, so does indeed need the quirk.
-ickle
--
Chris Wilson, Intel Open Source Technology Centre
--
> Intel had it installed.
My bad, change it to noinst_HEADERS please.
--
Chris Wilson, Intel Open Source Technology Centre
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling,
er 1073741824 (gen4 WM state): Bad file descriptor .\n",
> > 117) = 117
> > 1265267921.569039 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
This SEGV is just lazy error handling in the userspace driver; the
impossible just happened.
-ickle
--
Chris Wilson, Intel Open Source Tec
> [ 8505.847430] [drm:i915_gem_execbuffer] *ERROR*
> i915_gem_do_execbuffer returns -512
Apologies, this is not an error. It is an interrupted system call with an
overzealous DRM_ERROR() -- we will hopefully remove this printk promptly.
-ickle
--
Chris Wilson, Intel Open S
1.4, so
understandably tries to dereference a NULL function pointer when calling
glGenBuffers. However if the application truly wishes to be cross-device,
it can check for ARB_vertex_buffer_object and use the glGenBuffersARB
[and friends] extension points instead.
Hope this
ght the only reason why pin() took an alignment parameter was so
that we could specify a minimum alignment of 64k for untiled scan out
buffers. Are we confident that this is not the case?
-ickle
--
Chris Wilson, Intel Open Source Technology Centre
-
Implement support for purgeable objects by using the GEM madvise ioctl.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/intel/intel_buffer_objects.c | 134 -
src/mesa/drivers/dri/intel/intel_extensions.c |2 +
2 files changed, 135 insertions(+), 1 deletions
Signed-off-by: Chris Wilson
---
src/mesa/glapi/APPLE_object_purgeable.xml | 37 +
src/mesa/glapi/Makefile |1 +
src/mesa/glapi/gl_API.xml |1 +
3 files changed, 39 insertions(+), 0 deletions(-)
create mode 100644 src/mesa
Signed-off-by: Chris Wilson
---
src/mesa/main/api_exec.c |6 +
src/mesa/main/bufferobj.c | 350
src/mesa/main/bufferobj.h | 11 ++
src/mesa/main/dd.h | 15 ++
src/mesa/main/dlist.c |6 +
src/mesa/main/extensions.c |4
Large correction after Ian pointed out the fundamental flaw that the
various objects are separate structures and so require independent
interfaces.
Please review.
-ickle
--
Let Crystal Reports handle the reporting - Free
Signed-off-by: Chris Wilson
---
src/mesa/glapi/APPLE_object_purgeable.xml | 37 +
src/mesa/glapi/Makefile |1 +
src/mesa/glapi/gl_API.xml |1 +
3 files changed, 39 insertions(+), 0 deletions(-)
create mode 100644 src/mesa
Thank you Ian and Brian for your review, hopefully I've interpreted your
comments correctly and updated the patches appropriately.
-ickle
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
tri
Signed-off-by: Chris Wilson
---
src/mesa/main/api_exec.c |6 ++
src/mesa/main/bufferobj.c | 161
src/mesa/main/bufferobj.h | 11 +++
src/mesa/main/dd.h | 10 +++
src/mesa/main/extensions.c |4 +
src/mesa/main/mfeatures.h
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/intel/intel_buffer_objects.c | 43 +
src/mesa/drivers/dri/intel/intel_extensions.c |2 +
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_buffer_objects.c
b/src
Excerpts from Ian Romanick's message of Wed Nov 11 20:18:58 + 2009:
> Chris Wilson wrote:
> > +#if FEATURE_APPLE_object_purgeable
> > +static GLenum
> > +intel_bufferobj_purgeable(GLcontext * ctx,
> > + struct gl_buffer_object *obj,
ing 3 commits (XML, regeneration, real code) is
> probably even better.
Yes, this makes a lot of sense when trying to review these paths.
> Substantive comments are below.
>
> > Signed-off-by: Chris Wilson
> > ---
> > src/mesa/glapi/APPLE_object_purgea
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/intel/intel_buffer_objects.c | 43 +
src/mesa/drivers/dri/intel/intel_context.c|1 +
2 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_buffer_objects.c
b/src
atively simple, use the atomic variants of kmap() that
avoid the potential sleep.
Signed-off-by: Chris Wilson
Cc: Miles Lane
---
drivers/gpu/drm/i915/i915_debugfs.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/driver
connectors are brought online.
Signed-off-by: Chris Wilson
Cc: Dave Airlie
---
drivers/gpu/drm/drm_crtc_helper.c | 16 +++-
1 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 1fe4e1d..54e2706 100644
owing patch prevents the glitch for me:
>From aa017e6056cf2faf6be7eeaa71d2fded4a9f6295 Mon Sep 17 00:00:00 2001
From: Chris Wilson
Date: Tue, 30 Jun 2009 18:21:54 +0100
Subject: [PATCH 1/3] drm: delay unpinning the current fb til after the flip is
complete
---
drivers/gpu/drm/drm_crtc.
Revised patch, unmap_mapping_range() on unbind and clear register.
>From 8f13b6389ee0c8a39a2073279928a3a228bd27dc Mon Sep 17 00:00:00 2001
From: Chris Wilson
Date: Mon, 29 Jun 2009 08:45:31 +0100
Subject: [PATCH] drm/i915: Remove mappings on clearing fence register
As the fence register is
nge on clear - which could also cause
tiling errors if textures were being written via a GTT mmap.
So please can you try this patch:
>From 20b7c9322914213bb589035afbbc03faf1ae3bf0 Mon Sep 17 00:00:00 2001
From: Chris Wilson
Date: Mon, 29 Jun 2009 08:45:31 +0100
Subject: [PATCH] drm/i915: Remo
On Sun, 2009-06-21 at 17:47 +0300, Maxim Levitsky wrote:
> > 52dc7d32b88156248167864f77a9026abe27b432 is first bad commit
> > commit 52dc7d32b88156248167864f77a9026abe27b432
> > Author: Chris Wilson
> > Date: Sat Jun 6 09:46:01 2009 +0100
The error here seems to be my p
Dave,
this is an old patch that seems to have slip through the net, without
it my i915 runs out of GTT space within seconds during firefox replays.
>From e2cf2574d43f12934a20d2672d47fec082db7c5a Mon Sep 17 00:00:00 2001
From: Chris Wilson
Date: Fri, 22 May 2009 13:52:03 +0100
Subject: [PA
If the block needs an alignment but otherwise fits exactly into the tail,
then the split-off block from the start would remain marked as non-free.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 20 +---
1 files changed, 9 insertions(+), 11 deletions(-)
diff --git
7568b1eab18a33dd9edc3579ce5 Mon Sep 17 00:00:00 2001
From: Chris Wilson
Date: Wed, 11 Feb 2009 10:45:16 +
Subject: [PATCH] drm/i915: Clear fence register on tiling stride change.
The fence register value also depends upon the stride of the object, so
we
need to clear the fence if that is chan
On Thu, 2009-02-26 at 14:35 -0800, Jesse Barnes wrote:
> On Thursday, February 26, 2009 1:56:52 pm Chris Wilson wrote:
> > On Thu, 2009-02-26 at 13:28 -0800, Jesse Barnes wrote:
> > > Add a new page flip ioctl to the i915 driver. The new ioctl takes the
> > > new drm_i9
I've hit the occasional oops inside i915_wait_ring() with an indication of
a NULL derefence of dev->primary->master. Adding a NULL check is
consistent with the other potential users of dev->primary->master.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_dma.c |
On Thu, 2009-02-26 at 14:35 -0800, Jesse Barnes wrote:
> > > + ret = i915_gem_object_pin(obj, 0);
> > > + if (ret) {
> > > + DRM_ERROR("failed to pin object for flip\n");
> > > + ret = -EBUSY;
> >
> > What's the rationale for changing the reported err
On Thu, 2009-02-26 at 13:28 -0800, Jesse Barnes wrote:
> Add a new page flip ioctl to the i915 driver. The new ioctl takes the new
> drm_i915_gem_page_flip arg, which contains a buffer object target for the
> flip, an offset into that buffer, and other buffer parameters to be used for
> the flip.
The object is dereferenced before the NULL check. Oops.
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=20235
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b
Hello all,
I'm seeing a bizarre problem whilst running wayland/cairo-drm/i915 under
KMS. Occasionally after pressing a key (which is handled by wayland
through the input layer) the dark regions (I'm estimating where the
value is less than ~4) become garbage. I've managed to capture a
screenshot be
On Fri, 2009-02-20 at 13:46 +0800, Zou, Nanhai wrote:
> >+struct drm_i915_gem_page_flip {
> >+/** Handle of new front buffer */
>
> Should this be handle of new front buffer or handle of the execbuf?
I can't see how this can be an execbuf here. Do you mind elaborating?
Anyway this remin
On Thu, 2009-02-19 at 16:43 -0800, Jesse Barnes wrote:
> On Thursday 19 February 2009 11:37:01 Chris Wilson wrote:
> > With a few additional suggestions by Jesse, I've managed to get
> > tear-free compositing working on i915. Here's the diff on top of the
> > origin
With a few additional suggestions by Jesse, I've managed to get
tear-free compositing working on i915. Here's the diff on top of the
original patch (though obviously this is just a suggestion, still need
to prevent multiple pending flips to the same plane and ensure that the
old buffer is eventuall
On Mon, 2009-02-16 at 10:55 -0800, Jesse Barnes wrote:
> On Sunday, February 15, 2009 4:02 pm Chris Wilson wrote:
> > On my i915, the flip never occurs and we wait forever on the the vblank.
> > So I presume the command we sent the chip is invalid, or we miss the
> > irq? (
On Thu, 2009-02-12 at 16:52 -0800, Jesse Barnes wrote:
> This adds a new ioctl for queueing a page flip with GEM objects. There's a
> completion per private object, that we use at execbuf time to wait for any
> pending flips; it's cleared at vblank interrupt time when the flip occurs.
> The kernel
On Thu, 2009-02-12 at 14:37 -0500, Kristian Høgsberg wrote:
> Avoids leaking fbs and associated buffers on release.
>
> Signed-off-by: Kristian Høgsberg
Tested-by: Chris Wilson
--
Open Source Business Confere
I tried it, it's not too happy. My only concern is that this now relies
on userspace to correctly call SW_FINISH (and not unmap after mmapping
the GTT_MMAP) or otherwise the object is leaked? Patch comments inline.
On Fri, 2009-02-06 at 14:24 -0800, Jesse Barnes wrote:
> This one should cover the
On Tue, 2009-02-03 at 22:33 -0800, Eric Anholt wrote:
> The basic problem was
> mmap_sem (do_mmap()) -> struct_mutex (drm_gem_mmap())
> struct_mutex (i915_gem_execbuffer()) -> mmap_sem (copy_from/to_user())
>
> We have plenty of places where we want to hold device state the same
> (struct_mutex) w
48 matches
Mail list logo
