Re: drm: Branch 'master' - 2 commits
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 files changed, 22 insertions(+), 7 deletions(-) > > > > New commits: > > commit e73161a02b604742e3da3bca8f13cff81276de43 > > Author: Chris Wilson > > Date: Mon Dec 5 10:30:52 2011 + > > > > configure: Bump version to 2.4.28 > > > > So that we can pull a couple of Intel bug fixes into xf86-video-intel. > > > > Signed-off-by: Chris Wilson > > Performance before: > [ 0] glfirefox-talos-gfx 17.866 17.915 0.14%4/4 > after: > [ 0] glfirefox-talos-gfx 22.173 22.251 0.20%4/4 > > There's a pretty obvious opportunity to keep the performance win of the > userspace caching that you've broken here, but you gave none of us a > chance to review it before you pushed the patch *and shipped a release > with it*. This is not acceptable. Please revert and bump the release, > and fix it correctly. No, what was unacceptable was a vma leak impacting a critical system application, and for the library API to be broken by design. The onus is to improve performance without regressing system stability, not the other way around. -Chris -- Chris Wilson, Intel Open Source Technology Centre -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[ANNOUNCE] libdrm 2.4.24
In order to satisfy a dependency upon a new kernel parameter for mesa, it is time for a new release of libdrm. The usual bug fixes are a nice bonus. -Chris Ben Skeggs (3): nouveau: nvc0 drm has no concept of "notifier block" nouveau: split pushbuf macros specific to nv04-nv50 out, and add nvc0 nouveau: fix up reloc_emit() to accept NULL target buffer Benjamin Franzke (5): configure.ac: ac_define HAVE_RADEON modetest: Create buffers using libkms tests/modeprint: Remove needless dependency on drm_intel tests/modeprint: Output masks as hex 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 opening by name intel: Remember named bo intel: Add I915_PARAM_HAS_RELAXED_DELTA configure: Bump version to 2.4.24 Daniel Vetter (2): intel: fix relaxed tiling on gen2 intel: Fixup for the fix for relaxed tiling on gen2 nobled (1): libkms/radeon: Add backend git tag: 2.4.24 http://dri.freedesktop.org/libdrm/libdrm-2.4.24.tar.bz2 MD5: 8d802bf3b368f9fac0d7d17516a9436f libdrm-2.4.24.tar.bz2 SHA1: 7555a46a05c91c5d89a1efcb372fa7095a38d210 libdrm-2.4.24.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.24.tar.gz MD5: b52c4a28db725b639a4984a57e9ed144 libdrm-2.4.24.tar.gz SHA1: 03be8720b62ecb05747c6461010aa3fd735e0631 libdrm-2.4.24.tar.gz -- Chris Wilson, Intel Open Source Technology Centre -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Regression] [PATCH] intel_crt_detect_ddc() seems to be broken for DVI-I
On Thu, 06 Jan 2011 12:11:38 +0100, "David Müller (ELSOFT AG)" wrote: > The patch below adds an additional check to make sure that there is > really an analog device attached (similar to the "Mac mini hack" in > intel_sdvo.c) Nice patch, thanks. I've applied 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 database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] Destroy screen pixmap on screen close.
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 fbCloseScreen) can do this -- before > we're called, rendering may not have been finished, after we're called, > the acceleration code is shut down and pixmaps cannot be freed. That sounds true, and deserves a comment in the code. It doesn't explain why fbCloseScreen() calls free(screen->devPrivate) instead of miCloseScreen() and causing the leak in the first place... :) -- Chris Wilson, Intel Open Source Technology Centre -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] Destroy screen pixmap on screen close.
On Thu, 1 Jul 2010 09:56:40 -0400, Keith Packard wrote: > This avoids a memory leak on server reset. > > Signed-off-by: Keith Packard > --- > uxa/uxa.c |6 -- > 1 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/uxa/uxa.c b/uxa/uxa.c > index a9a705c..dcfaaa9 100644 > --- a/uxa/uxa.c > +++ b/uxa/uxa.c > @@ -1,7 +1,7 @@ > /* > - * Copyright © 2001 Keith Packard > + * Copyright © 2001 Keith Packard > * > - * Partly based on code that is Copyright © The XFree86 Project Inc. > + * Partly based on code that is Copyright © The XFree86 Project Inc. > * > * Permission to use, copy, modify, distribute, and sell this software and > its > * documentation for any purpose is hereby granted without fee, provided that > @@ -381,6 +381,8 @@ static Bool uxa_close_screen(int i, ScreenPtr pScreen) > > uxa_glyphs_fini(pScreen); > > + (void) (*pScreen->DestroyPixmap) (pScreen->devPrivate); > + pScreen->devPrivate = NULL; This looks like the responsibility of miCloseScreen(). Are we failing to chain up properly? Currently we have uxa_close_screen -> 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 -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [2.6.35-rc regression] i915: cursor corruption on Arrandale caused by 9b8c4a0b215e
On Sat, 5 Jun 2010 19:21:15 -0700, Andy Isaacson wrote: > My x201s (Core i7 L640 according to /proc/cpuinfo) running -rc1 exhibits > cursor corruption when changing the cursor image (such as when moving > out of xterm onto the desktop). Bisection pointed to 9b8c4a0b215e and > reverting that on top of 03cd373981 fixed the problem. I'm running > fvwm2 with xterm as my primary X client; the driver is > > xserver-xorg-video-intel 2:2.9.1-4 > > The corruption generally goes away within a second or two, and seems to > consist of the previous cursor 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 Wilson, Intel Open Source Technology Centre -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 11/18] i915: Provide config option for enabling tracepoints
Out of curiosity what motivated this patch? When adding the tracepoints, I found the overhead of compiling in but not enabling them to be insignificant, i.e. nearly unmeasurable in throughput benchmarks, so didn't believe it warranted a config option. Especially one that advises people to turn 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 Centre -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: Return ENODEV if the inode mapping changes
Replace a BUG_ON with an error code in the event that the inode mapping
changes between calls to drm_open. This may happen for instance if udev
is loaded subsequent to the original opening of the device:
[ 644.291870] kernel BUG at drivers/gpu/drm/drm_fops.c:146!
[ 644.291876] invalid opcode: [#1] SMP
[ 644.291882] last sysfs file: /sys/kernel/uevent_seqnum
[ 644.291888]
[ 644.291895] Pid: 7276, comm: lt-cairo-test-s Not tainted 2.6.34-rc1 #2
N150/N210/N220 /N150/N210/N220
[ 644.291903] EIP: 0060:[] EFLAGS: 00210283 CPU: 0
[ 644.291912] EIP is at drm_open+0x4b1/0x4e2
[ 644.291918] EAX: f72d8d18 EBX: f790a400 ECX: f73176b8 EDX:
[ 644.291923] ESI: f790a414 EDI: f790a414 EBP: f647ae20 ESP: f647adfc
[ 644.291929] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 644.291937] Process lt-cairo-test-s (pid: 7276, ti=f647a000 task=f73f5c80
task.ti=f647a000)
[ 644.291941] Stack:
[ 644.291945] f7bb7400 0080 f6451100 f73176b8 f6479214 f6451100
f73176b8
[ 644.291957] <0> c1297ce0 f647ae34 c11c6c04 f73176b8 f7949800
f647ae54 c1080ac5
[ 644.291969] <0> f7949800 f6451100 f6451100 f73176b8 f6452780
f647ae70 c107d1e6
[ 644.291982] Call Trace:
[ 644.291991] [] ? drm_stub_open+0x8a/0xb8
[ 644.292000] [] ? chrdev_open+0xef/0x106
[ 644.292008] [] ? __dentry_open+0xd4/0x1a6
[ 644.292015] [] ? nameidata_to_filp+0x31/0x45
[ 644.292022] [] ? chrdev_open+0x0/0x106
[ 644.292030] [] ? do_last+0x346/0x423
[ 644.292037] [] ? do_filp_open+0x190/0x415
[ 644.292046] [] ? handle_mm_fault+0x214/0x710
[ 644.292053] [] ? do_sys_open+0x4d/0xe9
[ 644.292061] [] ? do_page_fault+0x211/0x23f
[ 644.292068] [] ? sys_open+0x23/0x2b
[ 644.292075] [] ? sysenter_do_call+0x12/0x26
[ 644.292079] Code: 89 f0 89 55 dc e8 8d 96 0a 00 8b 45 e0 8b 55 dc 83 78 04
01 75 28 8b 83 18 02 00 00 85 c0 74 0f 8b 4d ec 3b 81 ac 00 00 00 74 13 <0f> 0b
eb fe 8b 4d ec 8b 81 ac 00 00 00 89 83 18 02 00 00 89 f0
[ 644.292143] EIP: [] drm_open+0x4b1/0x4e2 SS:ESP 0068:f647adfc
[ 644.292175] ---[ end trace 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_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -140,14 +140,16 @@ int drm_open(struct inode *inode, struct file *filp)
spin_unlock(&dev->count_lock);
}
out:
- mutex_lock(&dev->struct_mutex);
- if (minor->type == DRM_MINOR_LEGACY) {
- BUG_ON((dev->dev_mapping != NULL) &&
- (dev->dev_mapping != inode->i_mapping));
- if (dev->dev_mapping == NULL)
- dev->dev_mapping = inode->i_mapping;
+ if (!retcode) {
+ mutex_lock(&dev->struct_mutex);
+ if (minor->type == DRM_MINOR_LEGACY) {
+ if (dev->dev_mapping == NULL)
+ dev->dev_mapping = inode->i_mapping;
+ else if (dev->dev_mapping != inode->i_mapping)
+ retcode = -ENODEV;
+ }
+ mutex_unlock(&dev->struct_mutex);
}
- mutex_unlock(&dev->struct_mutex);
return retcode;
}
--
1.7.0
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 3/3] drm/i915: blacklist lid status: Sony VGN-BX196VP, Dell Inspiron 700m
On Thu, 11 Mar 2010 14:01:40 -0800, a...@linux-foundation.org wrote:
> + {
> + .ident = "Dell Inspiron 700m",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc"),
> + DMI_MATCH(DMI_BOARD_NAME, "Inspiron 700m"),
> + },
> + },
The Inspiron 700m has a 855GME part, so is caught by (which is heading
upstream, if not already been pulled into Linus' tree):
commit 7b9c5abee98c54f85bcc04bd4d7ec8d5094c73f4
Author: Jesse Barnes
Date: Fri Feb 12 09:30:00 2010 -0800
drm/i915: give up on 8xx lid status
These old machines more often than not lie about their lid state. So
don't use it to detect LVDS presence, but leave the event handler to
deal with lid open/close, when we might need to reset the mode.
Fixes kernel 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
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/2] libdrm: Move intel_atomic.h to libdrm core for sharing.
On Thu, 11 Mar 2010 00:21:13 +0200, Pauli Nieminen wrote: > On Wed, Mar 10, 2010 at 10:44 PM, Julien Cristau wrote: > > Should this really get installed? I'm not sure this should be public > > libdrm interface. > > > > Cheers, > > Julien > > > > 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, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [2.6.33-rc6-git regression] idr fix breaks Xorg
On Thu, 04 Feb 2010 17:16:56 +0900, Tejun Heo wrote:
> Hello,
>
> On 02/04/2010 04:56 PM, Andy Isaacson wrote:
> > 1265267921.568269 ioctl(8, 0xc020645e, 0x7fffe2196980) = -1 EBADF (Bad file
> > descriptor)
>
> Hmm... -EBADF? I suppose it doesn't mean that the fd is invalid in
> this case but that the mapped object can't be found for some reason?
> Can anyone more familiar with the subsystem explain what's going on?
Correct, in this case we pass in an 'fd' via the ioctl that we wish to
mmap. idr is then used to translate that handle back to one of our buffer
objects, which is then prepared for mapping.
In this context, it is the immediate lookup of the handle following
allocation that is failing. The critical bit of code lives in
drivers/gpu/drm/drm_gem.c:
int
drm_gem_handle_create(struct drm_file *file_priv,
struct drm_gem_object *obj,
u32 *handlep)
{
int ret;
/*
* Get the user-visible handle using idr.
*/
again:
/* ensure there is space available to allocate a handle */
if (idr_pre_get(&file_priv->object_idr, GFP_KERNEL) == 0)
return -ENOMEM;
/* do the allocation under our spinlock */
spin_lock(&file_priv->table_lock);
ret = idr_get_new_above(&file_priv->object_idr, obj, 1, (int
*)handlep);
spin_unlock(&file_priv->table_lock);
if (ret == -EAGAIN)
goto again;
if (ret != 0)
return ret;
drm_gem_object_handle_reference(obj);
return 0;
}
struct drm_gem_object *
drm_gem_object_lookup(struct drm_device *dev, struct drm_file *filp,
u32 handle)
{
struct drm_gem_object *obj;
spin_lock(&filp->table_lock);
/* Check if we currently have a reference on the object */
obj = idr_find(&filp->object_idr, handle);
if (obj == NULL) {
spin_unlock(&filp->table_lock);
return NULL;
}
drm_gem_object_reference(obj);
spin_unlock(&filp->table_lock);
return obj;
}
Can you see any problems here?
>
> > 1265267921.568649 write(2, "../../../libdrm/intel/intel_bufmgr_gem.c:637:
> > Error mapping buffer 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 Technology Centre
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.33-rc4-git1 -- [drm:i915_gem_execbuffer] *ERROR* i915_gem_do_execbuffer returns -512
On Thu, 14 Jan 2010 23:18:14 -0500, Miles Lane wrote: > I just hit this with 2.6.33-rc4-git1 and DRI modesetting enabled. I > don't know what event triggered the error. I had resumed from suspend > a long time before the error appeared in my dmesg output: > > [ 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 Source Technology Centre -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 945GM crash
On Wed, 02 Dec 2009 00:17:06 +, Svilen wrote: > Hi guys, > > A bug reported initially here (Fedora 12) > https://bugzilla.redhat.com/show_bug.cgi?id=541879 > > You can see from the bug reports that it involves "Mesa DRI Intel(R) 945GM > GEM 20090712 2009Q2 RC3" driver. > > The application uses glew library. After calling the glewInit(), the first > call to the openGL function which is glGenBuffers is causing the application > to crash. > > It's a cross platform application which works on other graphic > platforms/drivers on Linux as well as on Windows. Is there something I'm > missing in the initialization sequence? Or there is a problem with the driver? > Shall I raise a bug? This is an application bug. It is using OpenGL 2.0 features on a driver restricted by the capabilities of its hardware to OpenGL 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 helps, -ickle -- Chris Wilson, Intel Open Source Technology Centre -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: let pin routine figure out appropriate alignment
Excerpts from Jesse Barnes's message of Wed Nov 18 17:58:42 + 2009: > From 8adb52b4529e777d4df0356bc2c8ef5453c2322e Mon Sep 17 00:00:00 2001 > From: Jesse Barnes > Date: Wed, 18 Nov 2009 09:56:25 -0800 > Subject: [PATCH] drm/i915: let pin routine figure out appropriate alignment > > When this code got moved out of intel_pipe_set_base, it grew a forced > alignment of 256k, which wasn't always correct. Remove that and let the > pin routine figure out the correct alignment for the object (it should > do this in just about every case). I thought 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 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 4/4] APPLE_object_purgeable: intel
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(-)
diff --git a/src/mesa/drivers/dri/intel/intel_buffer_objects.c
b/src/mesa/drivers/dri/intel/intel_buffer_objects.c
index 669becd..069a204 100644
--- a/src/mesa/drivers/dri/intel/intel_buffer_objects.c
+++ b/src/mesa/drivers/dri/intel/intel_buffer_objects.c
@@ -31,10 +31,12 @@
#include "main/macros.h"
#include "main/bufferobj.h"
-#include "intel_context.h"
#include "intel_blit.h"
#include "intel_buffer_objects.h"
#include "intel_batchbuffer.h"
+#include "intel_context.h"
+#include "intel_fbo.h"
+#include "intel_mipmap_tree.h"
#include "intel_regions.h"
static GLboolean
@@ -586,6 +588,126 @@ intel_bufferobj_copy_subdata(GLcontext *ctx,
intel_batchbuffer_emit_mi_flush(intel->batch);
}
+#if FEATURE_APPLE_object_purgeable
+static GLenum
+intel_buffer_purgeable(GLcontext * ctx,
+ drm_intel_bo *buffer,
+ GLenum option)
+{
+ int retained = 0;
+
+ if (buffer != NULL)
+ retained = drm_intel_bo_madvise (buffer, I915_MADV_DONTNEED);
+
+ return retained ? GL_VOLATILE_APPLE : GL_RELEASED_APPLE;
+}
+
+static GLenum
+intel_buffer_object_purgeable(GLcontext * ctx,
+ struct gl_buffer_object *obj,
+ GLenum option)
+{
+ struct intel_buffer_object *intel;
+
+ intel = intel_buffer_object (obj);
+ if (intel->buffer != NULL)
+ return intel_buffer_purgeable (ctx, intel->buffer, option);
+
+ if (option == GL_RELEASED_APPLE) {
+ if (intel->sys_buffer != NULL) {
+ _mesa_free(intel->sys_buffer);
+ intel->sys_buffer = NULL;
+ }
+
+ return GL_RELEASED_APPLE;
+ } else {
+ /* XXX Create the buffer and madvise(MADV_DONTNEED)? */
+ return intel_buffer_purgeable (ctx,
+ intel_bufferobj_buffer(intel_context(ctx),
+intel, INTEL_READ),
+ option);
+ }
+}
+
+static GLenum
+intel_texture_object_purgeable(GLcontext * ctx,
+ struct gl_texture_object *obj,
+ GLenum option)
+{
+ struct intel_texture_object *intel;
+
+ intel = intel_texture_object(obj);
+ if (intel->mt == NULL || intel->mt->region == NULL)
+ return GL_RELEASED_APPLE;
+
+ return intel_buffer_purgeable (ctx, intel->mt->region->buffer, option);
+}
+
+static GLenum
+intel_render_object_purgeable(GLcontext * ctx,
+ struct gl_renderbuffer *obj,
+ GLenum option)
+{
+ struct intel_renderbuffer *intel;
+
+ intel = intel_renderbuffer(obj);
+ if (intel->region == NULL)
+ return GL_RELEASED_APPLE;
+
+ return intel_buffer_purgeable (ctx, intel->region->buffer, option);
+}
+
+static GLenum
+intel_buffer_unpurgeable(GLcontext * ctx,
+ drm_intel_bo *buffer,
+ GLenum option)
+{
+ int retained;
+
+ retained = 0;
+ if (buffer != NULL)
+ retained = drm_intel_bo_madvise (buffer, I915_MADV_WILLNEED);
+
+ return retained ? GL_RETAINED_APPLE : GL_UNDEFINED_APPLE;
+}
+
+static GLenum
+intel_buffer_object_unpurgeable(GLcontext * ctx,
+struct gl_buffer_object *obj,
+GLenum option)
+{
+ return intel_buffer_unpurgeable (ctx, intel_buffer_object (obj)->buffer,
option);
+}
+
+static GLenum
+intel_texture_object_unpurgeable(GLcontext * ctx,
+ struct gl_texture_object *obj,
+ GLenum option)
+{
+ struct intel_texture_object *intel;
+
+ intel = intel_texture_object(obj);
+ if (intel->mt == NULL || intel->mt->region == NULL)
+ return GL_UNDEFINED_APPLE;
+
+ return intel_buffer_unpurgeable (ctx, intel->mt->region->buffer, option);
+}
+
+static GLenum
+intel_render_object_unpurgeable(GLcontext * ctx,
+struct gl_renderbuffer *obj,
+GLenum option)
+{
+ struct intel_renderbuffer *intel;
+
+ intel = intel_renderbuffer(obj);
+ if (intel->region == NULL)
+ return GL_UNDEFINED_APPLE;
+
+ return intel_buffer_unpurgeable (ctx, intel->region->buffer, option);
+}
+#endif
+
void
intelInitBufferObjectFuncs(struct dd_function_table *functions)
{
@@ -599,4 +721,14 @@ intelInitBufferObjectFuncs(struct dd_function_table
*functions)
functions->FlushMappedBufferRange = intel_bufferobj_flush_mapped_range;
functions->Un
[PATCH 1/4] APPLE_object_purgeable: xml
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/glapi/APPLE_object_purgeable.xml diff --git a/src/mesa/glapi/APPLE_object_purgeable.xml b/src/mesa/glapi/APPLE_object_purgeable.xml new file mode 100644 index 000..62fa64a --- /dev/null +++ b/src/mesa/glapi/APPLE_object_purgeable.xml @@ -0,0 +1,37 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/src/mesa/glapi/Makefile b/src/mesa/glapi/Makefile index 71bef68..ce7c4c5 100644 --- a/src/mesa/glapi/Makefile +++ b/src/mesa/glapi/Makefile @@ -56,6 +56,7 @@ API_XML = gl_API.xml \ ARB_sync.xml \ ARB_vertex_array_object.xml \ APPLE_vertex_array_object.xml \ + APPLE_object_purgeable.xml \ EXT_framebuffer_object.xml \ EXT_packed_depth_stencil.xml \ EXT_provoking_vertex.xml \ diff --git a/src/mesa/glapi/gl_API.xml b/src/mesa/glapi/gl_API.xml index 34c7746..7ff61b3 100644 --- a/src/mesa/glapi/gl_API.xml +++ b/src/mesa/glapi/gl_API.xml @@ -11974,6 +11974,7 @@ http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -- 1.6.5.2 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 3/4] APPLE_object_purgeable: core
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 +
src/mesa/main/mfeatures.h |1 +
src/mesa/main/mtypes.h |4 +
8 files changed, 397 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/api_exec.c b/src/mesa/main/api_exec.c
index 1559984..953dcd9 100644
--- a/src/mesa/main/api_exec.c
+++ b/src/mesa/main/api_exec.c
@@ -746,4 +746,10 @@ _mesa_init_exec_table(struct _glapi_table *exec)
/* GL_ARB_vertex_array_object */
SET_BindVertexArray(exec, _mesa_BindVertexArray);
SET_GenVertexArrays(exec, _mesa_GenVertexArrays);
+
+#if FEATURE_APPLE_object_purgeable
+ SET_ObjectPurgeableAPPLE(exec, _mesa_ObjectPurgeableAPPLE);
+ SET_ObjectUnpurgeableAPPLE(exec, _mesa_ObjectUnpurgeableAPPLE);
+ SET_GetObjectParameterivAPPLE(exec, _mesa_GetObjectParameterivAPPLE);
+#endif
}
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 52c4995..08633a9 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -37,6 +37,8 @@
#include "image.h"
#include "context.h"
#include "bufferobj.h"
+#include "fbobject.h"
+#include "texobj.h"
/* Debug flags */
@@ -1655,3 +1657,351 @@ _mesa_FlushMappedBufferRange(GLenum target, GLintptr
offset, GLsizeiptr length)
if (ctx->Driver.FlushMappedBufferRange)
ctx->Driver.FlushMappedBufferRange(ctx, target, offset, length, bufObj);
}
+
+#if FEATURE_APPLE_object_purgeable
+static GLenum
+_mesa_RenderObjectPurgeable(GLcontext *ctx, GLuint name, GLenum option)
+{
+ struct gl_renderbuffer *bufObj;
+ GLenum retval;
+
+ bufObj = _mesa_lookup_renderbuffer(ctx, name);
+ if (!bufObj) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ "glObjectUnpurgeable(name = 0x%x)", name);
+ return 0;
+ }
+
+ if (bufObj->Purgeable) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "glObjectPurgeable(name = 0x%x) is already purgeable", name);
+ return GL_VOLATILE_APPLE;
+ }
+
+ bufObj->Purgeable = GL_TRUE;
+
+ retval = GL_VOLATILE_APPLE;
+ if (ctx->Driver.ObjectPurgeable_RenderObject)
+ retval = ctx->Driver.ObjectPurgeable_RenderObject(ctx, bufObj, option);
+
+ return retval;
+}
+
+static GLenum
+_mesa_TextureObjectPurgeable(GLcontext *ctx, GLuint name, GLenum option)
+{
+ struct gl_texture_object *bufObj;
+ GLenum retval;
+
+ bufObj = _mesa_lookup_texture(ctx, name);
+ if (!bufObj) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ "glObjectPurgeable(name = 0x%x)", name);
+ return 0;
+ }
+
+ if (bufObj->Purgeable) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "glObjectPurgeable(name = 0x%x) is already purgeable", name);
+ return GL_VOLATILE_APPLE;
+ }
+
+ bufObj->Purgeable = GL_TRUE;
+
+ retval = GL_VOLATILE_APPLE;
+ if (ctx->Driver.ObjectPurgeable_TextureObject)
+ retval = ctx->Driver.ObjectPurgeable_TextureObject(ctx, bufObj, option);
+
+ return retval;
+}
+
+static GLenum
+_mesa_BufferObjectPurgeable(GLcontext *ctx, GLuint name, GLenum option)
+{
+ struct gl_buffer_object *bufObj;
+ GLenum retval;
+
+ bufObj = get_buffer(ctx, name);
+ if (!bufObj) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ "glObjectPurgeable(name = 0x%x)", name);
+ return 0;
+ }
+
+ if (bufObj->Purgeable) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "glObjectPurgeable(name = 0x%x) is already purgeable", name);
+ return GL_VOLATILE_APPLE;
+ }
+
+ bufObj->Purgeable = GL_TRUE;
+
+ retval = GL_VOLATILE_APPLE;
+ if (ctx->Driver.ObjectPurgeable_BufferObject)
+ retval = ctx->Driver.ObjectPurgeable_BufferObject(ctx, bufObj, option);
+
+ return retval;
+}
+
+GLenum GLAPIENTRY
+_mesa_ObjectPurgeableAPPLE(GLenum objectType, GLuint name, GLenum option)
+{
+ GET_CURRENT_CONTEXT(ctx);
+
+ if (name == 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ "glObjectPurgeable(name = 0x%x)", name);
+ return 0;
+ }
+
+ switch (option) {
+ case GL_VOLATILE_APPLE:
+ case GL_RELEASED_APPLE:
+ break;
+
+ default:
+ _mesa_error(ctx, GL_INVALID_ENUM,
+ "glObjectPurgeable(name = 0x%x) invalid option: %d", name,
option);
+ return 0;
+ }
+
+ switch (objectType) {
+ case GL_TEXTURE:
+ return _mesa_TextureObjectPurgeable (ctx, name, option);
+ case GL_RENDERBUFFER_EXT:
+ return _mesa_RenderObjectPurgeable (ctx, name, option);
+ case GL_BUFFER_OBJECT_APPLE:
+ return _mesa_BufferObjectPurgeable (ctx, name, option);
+
+ default:
+ _mesa_error(ctx, GL_INVALID_ENUM,
+
APPLE_object_purgeable [v3]
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 Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/4] APPLE_object_purgeable: xml
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/glapi/APPLE_object_purgeable.xml diff --git a/src/mesa/glapi/APPLE_object_purgeable.xml b/src/mesa/glapi/APPLE_object_purgeable.xml new file mode 100644 index 000..62fa64a --- /dev/null +++ b/src/mesa/glapi/APPLE_object_purgeable.xml @@ -0,0 +1,37 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/src/mesa/glapi/Makefile b/src/mesa/glapi/Makefile index fb6be1a..de55c76 100644 --- a/src/mesa/glapi/Makefile +++ b/src/mesa/glapi/Makefile @@ -56,6 +56,7 @@ API_XML = gl_API.xml \ ARB_sync.xml \ ARB_vertex_array_object.xml \ APPLE_vertex_array_object.xml \ + APPLE_object_purgeable.xml \ EXT_provoking_vertex.xml COMMON = gl_XML.py glX_XML.py license.py $(API_XML) typeexpr.py diff --git a/src/mesa/glapi/gl_API.xml b/src/mesa/glapi/gl_API.xml index da4be14..60bcdb3 100644 --- a/src/mesa/glapi/gl_API.xml +++ b/src/mesa/glapi/gl_API.xml @@ -11974,6 +11974,7 @@ http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -- 1.6.5.2 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
APPLE_object_purgeable [v2]
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 trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 3/4] APPLE_object_purgeable: core
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 |1 +
src/mesa/main/mtypes.h |2 +
7 files changed, 195 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/api_exec.c b/src/mesa/main/api_exec.c
index 1559984..953dcd9 100644
--- a/src/mesa/main/api_exec.c
+++ b/src/mesa/main/api_exec.c
@@ -746,4 +746,10 @@ _mesa_init_exec_table(struct _glapi_table *exec)
/* GL_ARB_vertex_array_object */
SET_BindVertexArray(exec, _mesa_BindVertexArray);
SET_GenVertexArrays(exec, _mesa_GenVertexArrays);
+
+#if FEATURE_APPLE_object_purgeable
+ SET_ObjectPurgeableAPPLE(exec, _mesa_ObjectPurgeableAPPLE);
+ SET_ObjectUnpurgeableAPPLE(exec, _mesa_ObjectUnpurgeableAPPLE);
+ SET_GetObjectParameterivAPPLE(exec, _mesa_GetObjectParameterivAPPLE);
+#endif
}
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 52c4995..56df150 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -1655,3 +1655,164 @@ _mesa_FlushMappedBufferRange(GLenum target, GLintptr
offset, GLsizeiptr length)
if (ctx->Driver.FlushMappedBufferRange)
ctx->Driver.FlushMappedBufferRange(ctx, target, offset, length, bufObj);
}
+
+#if FEATURE_APPLE_object_purgeable
+GLenum GLAPIENTRY
+_mesa_ObjectPurgeableAPPLE(GLenum objectType, GLuint name, GLenum option)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ struct gl_buffer_object *bufObj;
+ GLenum retval;
+
+ switch (objectType) {
+ case GL_TEXTURE:
+ case GL_BUFFER_OBJECT_APPLE:
+ case GL_RENDERBUFFER_EXT:
+ break;
+
+ default:
+ _mesa_error(ctx, GL_INVALID_ENUM,
+ "glObjectPurgeable(name = 0x%x) invalid type: %d", name,
objectType);
+ return 0;
+ }
+
+ if (name == 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ "glObjectPurgeable(name = 0x%x)", name);
+ return 0;
+ }
+
+ switch (option) {
+ case GL_VOLATILE_APPLE:
+ case GL_RELEASED_APPLE:
+ break;
+
+ default:
+ _mesa_error(ctx, GL_INVALID_ENUM,
+ "glObjectPurgeable(name = 0x%x) invalid option: %d", name,
option);
+ return 0;
+ }
+
+ bufObj = get_buffer(ctx, name);
+ if (!bufObj) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ "glObjectPurgeable(name = 0x%x)", name);
+ return 0;
+ }
+
+ if (bufObj->Purgeable) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "glObjectPurgeable(name = 0x%x) is already purgeable", name);
+ return GL_VOLATILE_APPLE;
+ }
+
+ bufObj->Purgeable = GL_TRUE;
+
+ retval = GL_VOLATILE_APPLE;
+ if (ctx->Driver.ObjectPurgeable)
+ retval = ctx->Driver.ObjectPurgeable(ctx, bufObj, option);
+
+ return retval;
+}
+
+GLenum GLAPIENTRY
+_mesa_ObjectUnpurgeableAPPLE(GLenum objectType, GLuint name, GLenum option)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ struct gl_buffer_object *bufObj;
+ GLenum retval;
+
+ switch (objectType) {
+ case GL_TEXTURE:
+ case GL_BUFFER_OBJECT_APPLE:
+ case GL_RENDERBUFFER_EXT:
+ break;
+
+ default:
+ _mesa_error(ctx, GL_INVALID_ENUM,
+ "glObjectUnpurgeable(name = 0x%x) invalid type: %d", name,
objectType);
+ return 0;
+ }
+
+ if (name == 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ "glObjectUnpurgeable(name = 0x%x)", name);
+ return 0;
+ }
+
+ switch (option) {
+ case GL_RETAINED_APPLE:
+ case GL_UNDEFINED_APPLE:
+ break;
+
+ default:
+ _mesa_error(ctx, GL_INVALID_ENUM,
+ "glObjectUnpurgeable(name = 0x%x) invalid option: %d", name,
option);
+ return 0;
+ }
+
+ bufObj = get_buffer(ctx, name);
+ if (!bufObj) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ "glObjectUnpurgeable(name = 0x%x)", name);
+ return 0;
+ }
+
+ if (! bufObj->Purgeable) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "glObjectUnpurgeable(name = 0x%x) object is already
\"unpurged\"", name);
+ return 0;
+ }
+
+ bufObj->Purgeable = GL_FALSE;
+
+ retval = GL_RETAINED_APPLE;
+ if (ctx->Driver.ObjectUnpurgeable)
+ retval = ctx->Driver.ObjectUnpurgeable(ctx, bufObj, option);
+
+ return retval;
+}
+
+void GLAPIENTRY
+_mesa_GetObjectParameterivAPPLE(GLenum objectType, GLuint name, GLenum pname,
GLint* params)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ struct gl_buffer_object *bufObj;
+
+ switch (objectType) {
+ case GL_TEXTURE:
+ case GL_BUFFER_OBJECT_APPLE:
+ case GL_RENDERBUFFER_EXT:
+ break;
+
+ default:
+ _mesa_error(ctx, GL_INVALID_ENUM,
+ "glGetObjectParameteriv(name = 0x%x) invalid type: %d",
name, obj
[PATCH 4/4] APPLE_object_purgeable: intel
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/mesa/drivers/dri/intel/intel_buffer_objects.c
index ea9d5a6..856d71a 100644
--- a/src/mesa/drivers/dri/intel/intel_buffer_objects.c
+++ b/src/mesa/drivers/dri/intel/intel_buffer_objects.c
@@ -573,6 +573,44 @@ intel_bufferobj_copy_subdata(GLcontext *ctx,
intel_batchbuffer_emit_mi_flush(intel->batch);
}
+#if FEATURE_APPLE_object_purgeable
+static GLenum
+intel_bufferobj_purgeable(GLcontext * ctx,
+ struct gl_buffer_object *obj,
+ GLenum option)
+{
+ struct intel_buffer_object *intel_obj = intel_buffer_object(obj);
+ int retained;
+
+ if (intel_obj->buffer != NULL) {
+ retained = drm_intel_bo_madvise (intel_obj->buffer, I915_MADV_DONTNEED);
+ } else {
+ if (intel_obj->sys_buffer != NULL) {
+ _mesa_free(intel_obj->sys_buffer);
+ intel_obj->sys_buffer = NULL;
+ }
+ retained = 0;
+ }
+
+ return retained ? GL_VOLATILE_APPLE : GL_RELEASED_APPLE;
+}
+
+static GLenum
+intel_bufferobj_unpurgeable(GLcontext * ctx,
+ struct gl_buffer_object *obj,
+ GLenum option)
+{
+ struct intel_buffer_object *intel_obj = intel_buffer_object(obj);
+ int retained;
+
+ retained = 1;
+ if (intel_obj->buffer != NULL)
+ retained = drm_intel_bo_madvise (intel_obj->buffer, I915_MADV_WILLNEED);
+
+ return retained ? GL_RETAINED_APPLE : GL_UNDEFINED_APPLE;
+}
+#endif
+
void
intelInitBufferObjectFuncs(struct dd_function_table *functions)
{
@@ -586,4 +624,9 @@ intelInitBufferObjectFuncs(struct dd_function_table
*functions)
functions->FlushMappedBufferRange = intel_bufferobj_flush_mapped_range;
functions->UnmapBuffer = intel_bufferobj_unmap;
functions->CopyBufferSubData = intel_bufferobj_copy_subdata;
+
+#if FEATURE_APPLE_object_purgeable
+ functions->ObjectPurgeable = intel_bufferobj_purgeable;
+ functions->ObjectUnpurgeable = intel_bufferobj_unpurgeable;
+#endif
}
diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c
b/src/mesa/drivers/dri/intel/intel_extensions.c
index b6754c9..fe691b9 100644
--- a/src/mesa/drivers/dri/intel/intel_extensions.c
+++ b/src/mesa/drivers/dri/intel/intel_extensions.c
@@ -57,6 +57,7 @@
#define need_GL_EXT_secondary_color
#define need_GL_EXT_stencil_two_side
#define need_GL_APPLE_vertex_array_object
+#define need_GL_APPLE_object_purgeable
#define need_GL_ATI_separate_stencil
#define need_GL_ATI_envmap_bumpmap
#define need_GL_NV_point_sprite
@@ -181,6 +182,7 @@ static const struct dri_extension ttm_extensions[] = {
{ "GL_ARB_pixel_buffer_object", NULL },
{ "GL_EXT_framebuffer_blit", GL_EXT_framebuffer_blit_functions },
{ "GL_EXT_framebuffer_object", GL_EXT_framebuffer_object_functions },
+ { "GL_APPLE_object_purgeable", GL_APPLE_object_purgeable_functions },
{ NULL, NULL }
};
--
1.6.5.2
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 2/2] intel: APPLE_object_purgeable
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,
> > + GLenum option)
> > +{
> > + struct intel_buffer_object *intel_obj = intel_buffer_object(obj);
> > + int retained;
> > +
> > + if (intel_obj->buffer != NULL) {
> > + retained = drm_intel_bo_madvise (intel_obj->buffer,
> > I915_MADV_DONTNEED);
> > + } else {
> > + if (intel_obj->sys_buffer != NULL) {
> > + _mesa_free(intel_obj->sys_buffer);
>
> I don't think we want to free the buffer here. This case really only
> happens on i915 for vertex buffers. I don't expect these types of
> buffers to be marked purgeable very often. Can we do
> madvise(MADV_WONTNEED) instead? This isn't quite the same (it doesn't
> release the contents during memory pressure), but it seems close enough.
The only reason we do something different here is that we have yet to
allocate the buffer so there was nothing to mark as advisory. The
alternative would be to create the buffer and transfer the data from
system to 'video' and then mark the buffer as advisory...
A compromise: only free the system buffer if the hint is RELEASED?
> > + _mesa_enable_extension(ctx, "GL_APPLE_object_purgeable");
>
> No! Add this to the ttm_extensions table in intel_extensions.c.
Ok, I'm looking at how to do so now. Just when I thought I understood one
level of complexity, you reveal a whole new chasm. ;-)
-ickle
--
Chris Wilson, Intel Open Source Technology Centre
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/2] APPLE_object_purgeable
Ian, thanks for your detailed comments! The patch was just guess work
from looking at similar extensions - I couldn't see a step-by-step guide
on how to add an extension to Mesa.
Excerpts from Ian Romanick's message of Wed Nov 11 20:06:04 + 2009:
> Eric's suggestion of doing 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_purgeable.xml | 35 +
> > src/mesa/glapi/Makefile |1 +
> > src/mesa/glapi/gl_API.xml |1 +
> > src/mesa/glapi/glapidispatch.h| 33 +-
> > src/mesa/glapi/glapioffsets.h | 18 +-
> > src/mesa/glapi/glapitable.h | 13 +-
> > src/mesa/glapi/glapitemp.h| 44 +-
> > src/mesa/glapi/glprocs.h | 634 ++--
> > src/mesa/main/api_exec.c |6 +
> > src/mesa/main/bufferobj.c | 151 +
> > src/mesa/main/bufferobj.h | 11 +
> > src/mesa/main/dd.h| 10 +
> > src/mesa/main/enums.c | 6054
> > +++--
> > src/mesa/main/extensions.c|1 +
> > src/mesa/main/mfeatures.h |1 +
> > src/mesa/main/mtypes.h|2 +
> > src/mesa/main/remap_helper.h | 2992 +++---
> > src/mesa/sparc/glapi_sparc.S | 19 +-
> > src/mesa/x86-64/glapi_x86-64.S| 181 +-
> > src/mesa/x86/glapi_x86.S | 23 +-
>
> Are there any hooks needed in dlist.c?
I didn't think so. The specification didn't mention display lists and it
made no sense to me as you need to check the status of a purgeable
texture before use (and potentially replace/reload the texture) so
storing such textures inside a display list would be incorrect.
> > 20 files changed, 5334 insertions(+), 4896 deletions(-)
> > create mode 100644 src/mesa/glapi/APPLE_object_purgeable.xml
> >
> > diff --git a/src/mesa/glapi/APPLE_object_purgeable.xml
> > b/src/mesa/glapi/APPLE_object_purgeable.xml
> > new file mode 100644
> > index 000..ba70e87
> > --- /dev/null
> > +++ b/src/mesa/glapi/APPLE_object_purgeable.xml
> > @@ -0,0 +1,35 @@
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
>
> Do any of these enums have associated Gets?
So if the enum can be used a pname, the associated function should be
included in a node?
> > + if (bufObj->purgeable) {
> > + _mesa_error(ctx, GL_INVALID_OPERATION,
> > + "glObjectPurgeable(name = 0x%x) is already purgeable",
> > name);
> > + return bufObj->purgeable;
> > + }
> > +
> > + bufObj->purgeable = option;
>
> This is wrong. ObjectPurgableAPPLE always sets the purgeable flag to
> true.
Yes. I was just using TRUE in the general non-zero sense, so just used the
hint. However, using a simple boolean avoids the temptation of storing
the returned status from the driver functions...
> The 'option' parameter gives the GL a hint as to how the
> application intends to use the object in the future. VOLATILE means the
> application doesn't know whether it will use the buffer again (i.e.,
> only release it under memory pressure), and RELEASED means that it knows
> it's done with it (maybe release it now).
> On the flip side, the option to ObjectUnpurgable is really a hint of
> what to do when the buffer object has been paged out of VRAM on a
> discrete graphics card. We don't have to worry about this at all on UMA
> systems.
Indeed, as you can see from the implementation for Intel, we only use
the hint to release the texture if it falls out of the aperture. We
could try a more subtle approach that uses the hint to only discard the
texture if we would be forced to swap. I'm not sure if the kernel has
the appropriate level of granularity for that though.
> > + if (ctx->Driver.ObjectPurgeable)
> > + bufObj->purgeable = ctx->Driver.ObjectPurgeable(ctx, bufObj, option);
>
> This is weird. Usually driver functions don't return a value to set in
> the object's state. The driver function just sets that state.
Done, we only need to report the current status hint as reported by the
driver to the user.
> > + retval = bufObj->purgeable = 0;
> > + if (ctx->Driver.ObjectUnpurgeable)
> &g
[PATCH 2/2] intel: APPLE_object_purgeable
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/mesa/drivers/dri/intel/intel_buffer_objects.c
index ea9d5a6..856d71a 100644
--- a/src/mesa/drivers/dri/intel/intel_buffer_objects.c
+++ b/src/mesa/drivers/dri/intel/intel_buffer_objects.c
@@ -573,6 +573,44 @@ intel_bufferobj_copy_subdata(GLcontext *ctx,
intel_batchbuffer_emit_mi_flush(intel->batch);
}
+#if FEATURE_APPLE_object_purgeable
+static GLenum
+intel_bufferobj_purgeable(GLcontext * ctx,
+ struct gl_buffer_object *obj,
+ GLenum option)
+{
+ struct intel_buffer_object *intel_obj = intel_buffer_object(obj);
+ int retained;
+
+ if (intel_obj->buffer != NULL) {
+ retained = drm_intel_bo_madvise (intel_obj->buffer, I915_MADV_DONTNEED);
+ } else {
+ if (intel_obj->sys_buffer != NULL) {
+ _mesa_free(intel_obj->sys_buffer);
+ intel_obj->sys_buffer = NULL;
+ }
+ retained = 0;
+ }
+
+ return retained ? GL_VOLATILE_APPLE : GL_RELEASED_APPLE;
+}
+
+static GLenum
+intel_bufferobj_unpurgeable(GLcontext * ctx,
+ struct gl_buffer_object *obj,
+ GLenum option)
+{
+ struct intel_buffer_object *intel_obj = intel_buffer_object(obj);
+ int retained;
+
+ retained = 1;
+ if (intel_obj->buffer != NULL)
+ retained = drm_intel_bo_madvise (intel_obj->buffer, I915_MADV_WILLNEED);
+
+ return retained ? GL_RETAINED_APPLE : GL_UNDEFINED_APPLE;
+}
+#endif
+
void
intelInitBufferObjectFuncs(struct dd_function_table *functions)
{
@@ -586,4 +624,9 @@ intelInitBufferObjectFuncs(struct dd_function_table
*functions)
functions->FlushMappedBufferRange = intel_bufferobj_flush_mapped_range;
functions->UnmapBuffer = intel_bufferobj_unmap;
functions->CopyBufferSubData = intel_bufferobj_copy_subdata;
+
+#if FEATURE_APPLE_object_purgeable
+ functions->ObjectPurgeable = intel_bufferobj_purgeable;
+ functions->ObjectUnpurgeable = intel_bufferobj_unpurgeable;
+#endif
}
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index e0022ad..cfdb867 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -758,6 +758,7 @@ intelInitContext(struct intel_context *intel,
intel_fbo_init(intel);
+ _mesa_enable_extension(ctx, "GL_APPLE_object_purgeable");
if (intel->ctx.Mesa_DXTn) {
_mesa_enable_extension(ctx, "GL_EXT_texture_compression_s3tc");
_mesa_enable_extension(ctx, "GL_S3_s3tc");
--
1.6.5.2
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: Avoid potential sleep whilst holding spinlock
Miles Lane reported the following error:
2 locks held by cat/4179:
#0: (&p->lock){+.+.+.}, at: [] seq_read+0x25/0x315
#1: (&dev_priv->mm.active_list_lock){+.+...}, at: []
i915_batchbuffer_info+0x2b/0x124
Pid: 4179, comm: cat Not tainted 2.6.32-rc5-git1 #2
Call Trace:
[] ? __debug_show_held_locks+0x1e/0x20
[] __might_sleep+0xf0/0xf7
[] kmap+0x17/0x58
[] i915_batchbuffer_info+0xad/0x124
[] seq_read+0x160/0x315
[] ? rw_verify_area+0x98/0xbb
[] ? seq_read+0x0/0x315
[] vfs_read+0x75/0xa9
[] sys_read+0x3b/0x5d
[] sysenter_do_call+0x12/0x36
The fix is relatively 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/drivers/gpu/drm/i915/i915_debugfs.c
index 2ace8b7..9087c4c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -268,10 +268,10 @@ static void i915_dump_pages(struct seq_file *m, struct
page **pages, int page_co
uint32_t *mem;
for (page = 0; page < page_count; page++) {
- mem = kmap(pages[page]);
+ mem = kmap_atomic(pages[page], KM_USER0);
for (i = 0; i < PAGE_SIZE; i += 4)
seq_printf(m, "%08x : %08x\n", i, mem[i / 4]);
- kunmap(pages[page]);
+ kunmap_atomic(pages[page], KM_USER0);
}
}
--
1.6.5
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: Silence the warning for headless machines
[ 379.173003] WARNING: at drivers/gpu/drm/drm_crtc_helper.c:1031
drm_helper_initial_config+0x41/0x5c [drm_kms_helper]()
[ 379.173005] Hardware name:
[ 379.173007] No connectors reported connected with modes
[ 379.173008] Modules linked in: i915(+) drm_kms_helper drm i2c_algo_bit nfs
lockd fscache nfs_acl auth_rpcgss sunrpc loop firewire_sbp2
snd_hda_codec_intelhdmi snd_hda_codec_idt snd_hda_intel i2c_i801 i2c_core
snd_hda_codec snd_hwdep snd_pcm snd_timer snd soundcore snd_page_alloc
processor evdev pcspkr psmouse serio_raw ext4 mbcache jbd2 crc16 sg sr_mod
sd_mod crc_t10dif cdrom ata_generic ata_piix libata uhci_hcd scsi_mod video
output button ide_pci_generic intel_agp firewire_ohci firewire_core crc_itu_t
ehci_hcd ide_core e1000e thermal fan thermal_sys [last unloaded: scsi_wait_scan]
[ 379.173049] Pid: 1670, comm: modprobe Not tainted 2.6.32-rc3 #3
[ 379.173051] Call Trace:
[ 379.173055] [] ? drm_helper_initial_config+0x41/0x5c
[drm_kms_helper]
[ 379.173061] [] warn_slowpath_common+0x77/0xa4
[ 379.173064] [] warn_slowpath_fmt+0x64/0x66
[ 379.173068] [] ?
drm_helper_probe_connector_modes+0x3f/0x75 [drm_kms_helper]
[ 379.173071] [] drm_helper_initial_config+0x41/0x5c
[drm_kms_helper]
[ 379.173083] [] i915_driver_load+0xe96/0xf65 [i915]
[ 379.173093] [] ? drm_get_minor+0x22d/0x27b [drm]
[ 379.173101] [] drm_get_dev+0x381/0x470 [drm]
[ 379.173113] [] i915_pci_probe+0x10/0xd0 [i915]
[ 379.173117] [] local_pci_probe+0x12/0x16
[ 379.173120] [] pci_device_probe+0xc6/0xf0
[ 379.173124] [] ? driver_sysfs_add+0x4c/0x72
[ 379.173127] [] driver_probe_device+0xb0/0x162
[ 379.173130] [] __driver_attach+0x58/0x7b
[ 379.173133] [] ? __driver_attach+0x0/0x7b
[ 379.173135] [] bus_for_each_dev+0x54/0x8a
[ 379.173138] [] driver_attach+0x1c/0x1e
[ 379.173141] [] bus_add_driver+0xbb/0x207
[ 379.173144] [] driver_register+0xb6/0x124
[ 379.173153] [] ? i915_init+0x0/0x52 [i915]
[ 379.173156] [] __pci_register_driver+0x61/0xcc
[ 379.173166] [] ? i915_init+0x0/0x52 [i915]
[ 379.173173] [] drm_init+0x6b/0xd1 [drm]
[ 379.173182] [] ? i915_init+0x0/0x52 [i915]
[ 379.173191] [] i915_init+0x50/0x52 [i915]
[ 379.173195] [] do_one_initcall+0x6e/0x186
[ 379.173199] [] sys_init_module+0xd2/0x22f
[ 379.173202] [] system_call_fastpath+0x16/0x1b
An unhelpful warning, especially if we anticipate hotplug events as
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
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -1017,7 +1017,7 @@ bool drm_helper_plugged_event(struct drm_device *dev)
*/
bool drm_helper_initial_config(struct drm_device *dev)
{
- int count = 0;
+ int count;
drm_fb_helper_parse_command_line(dev);
@@ -1025,15 +1025,13 @@ bool drm_helper_initial_config(struct drm_device *dev)
dev->mode_config.max_width,
dev->mode_config.max_height);
- /*
-* we shouldn't end up with no modes here.
-*/
- WARN(!count, "No connectors reported connected with modes\n");
-
- drm_setup_crtcs(dev);
+ /* If we are headless, we can expect to find no valid modes. */
+ if (count) {
+ drm_setup_crtcs(dev);
- /* alert the driver fb layer */
- dev->mode_config.funcs->fb_changed(dev);
+ /* alert the driver fb layer */
+ dev->mode_config.funcs->fb_changed(dev);
+ }
return 0;
}
--
1.6.4.3
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] Add modesetting pageflip ioctl and corresponding drm event
I've just got around to playing with the modesetting page-flip ioctl and
found a nasty rendering glitch where the flip occurred before the
rendering was flushed. This appears to be because the finish of the
pending_flip is queued at the same time as the async set_base().
Applying the following 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.c | 45 +++
drivers/gpu/drm/drm_irq.c |7 +++--
include/drm/drm_crtc.h |4 ++-
3 files changed, 43 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6a5a779..32212e6 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -344,20 +344,30 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
EXPORT_SYMBOL(drm_framebuffer_cleanup);
/**
- * drm_crtc_async_work - do a set_base call from a work queue
+ * drm_crtc_async_flip - do a set_base call from a work queue
* @work: work struct
*
* Called when a set_base call is queued by the page flip code. This
* allows the flip ioctl itself to return immediately and allow userspace
* to continue working.
*/
-static void drm_crtc_async_work(struct work_struct *work)
+static void drm_crtc_async_flip(struct work_struct *work)
{
- struct drm_crtc *crtc = container_of(work, struct drm_crtc, async_work);
+ struct drm_crtc *crtc = container_of(work, struct drm_crtc, async_flip);
struct drm_device *dev = crtc->dev;
+ struct drm_pending_flip *pending;
+
+ BUG_ON(crtc->pending_flip == NULL);
mutex_lock(&dev->struct_mutex);
crtc->funcs->set_base(crtc, 0, 0, NULL);
+
+ pending = crtc->pending_flip;
+ crtc->pending_flip = NULL;
+
+ pending->frame = drm_vblank_count(dev, crtc->pipe);
+ list_add_tail(&pending->link, &dev->flip_list);
+
mutex_unlock(&dev->struct_mutex);
}
@@ -384,7 +394,7 @@ void drm_crtc_init(struct drm_device *dev, struct drm_crtc
*crtc, int pipe,
list_add_tail(&crtc->head, &dev->mode_config.crtc_list);
dev->mode_config.num_crtc++;
- INIT_WORK(&crtc->async_work, drm_crtc_async_work);
+ INIT_WORK(&crtc->async_flip, drm_crtc_async_flip);
mutex_unlock(&dev->mode_config.mutex);
}
EXPORT_SYMBOL(drm_crtc_init);
@@ -404,7 +414,7 @@ void drm_crtc_cleanup(struct drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
mutex_lock(&dev->mode_config.mutex);
- flush_work(&crtc->async_work);
+ flush_work(&crtc->async_flip);
if (crtc->gamma_store) {
kfree(crtc->gamma_store);
@@ -2569,9 +2579,6 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev, void
*data,
goto out_unlock;
}
- pending->frame = drm_vblank_count(dev, crtc->pipe);
- list_add_tail(&pending->link, &dev->flip_list);
-
/*
* The set_base call will change the domain on the new fb,
* which will force the rendering to finish and block the
@@ -2580,7 +2587,27 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
void *data,
*/
crtc->fb = obj_to_fb(fb_obj);
- schedule_work(&crtc->async_work);
+ if (crtc->pending_flip != NULL) {
+ struct drm_pending_flip *old_flip;
+
+ /* We have an outstanding flip request for this crtc/pipe.
+* In order to satisfy the user we can either queue the requests
+* and apply them on sequential vblanks, or we can drop old
+* requests.
+*
+* Here we choose to discard the previous request for
+* simplicity. Note that since we have not yet applied the
+* previous flip, we need to preserve the original (i.e. still
+* current) fb.
+*/
+
+ old_flip = crtc->pending_flip;
+ pending->old_fb = old_flip->old_fb;
+ old_flip->old_fb = NULL;
+ drm_finish_pending_flip (dev, old_flip, 0);
+ } else
+ schedule_work(&crtc->async_flip);
+ crtc->pending_flip = pending;
mutex_unlock(&dev->struct_mutex);
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 8b4d0c8..c7a17f6 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -72,7 +72,7 @@ int drm_irq_by_busid(struct drm_device *dev, void *data,
return 0;
}
-#define vblank_after(a,b) ((long)(b) - (long)(a) < 0)
+#define vblank_passed(a,b) ((long)(a - b) > 0)
void drm_finish_pending_flip(struct drm_device *dev,
Re: [git pull] drm: previous pull req + 1.
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 not locked whilst the user has mmaped the buffer
through the GTT, in order for the buffer to reacquire a fence register we
need to cause a fresh page-fault on the next user access. In order to
cause the page fault, we zap the current mapping on clearing the register.
We also ensure that all potential outstanding access via the fence
register is flushed before release as well.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 35 +++
1 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 685a876..7fb636b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1946,8 +1946,7 @@ i915_gem_object_unbind(struct drm_gem_object *obj)
obj_priv->agp_mem = NULL;
}
-
- /* blow away mappings if mapped through GTT */
+ /* Force the next mmap access to trigger a fault and rebind */
if (obj_priv->mmap_offset && dev->dev_mapping)
unmap_mapping_range(dev->dev_mapping,
obj_priv->mmap_offset, obj->size, 1);
@@ -2350,8 +2349,7 @@ try_again:
if (old_obj_priv->pin_count)
continue;
- /* i915 uses fences for GPU access to tiled buffers */
- if (IS_I965G(dev) || !old_obj_priv->active)
+ if (!old_obj_priv->active)
break;
/* find the seqno of the first available fence */
@@ -2440,6 +2438,8 @@ i915_gem_clear_fence_reg(struct drm_gem_object *obj)
obj_priv->gtt_offset, obj->size);
#endif
+ BUG_ON(obj_priv->active);
+
if (IS_I965G(dev))
I915_WRITE64(FENCE_REG_965_0 + (obj_priv->fence_reg * 8), 0);
else {
@@ -2471,25 +2471,28 @@ i915_gem_object_put_fence_reg(struct drm_gem_object
*obj)
{
struct drm_device *dev = obj->dev;
struct drm_i915_gem_object *obj_priv = obj->driver_private;
+ int ret;
if (obj_priv->fence_reg == I915_FENCE_REG_NONE)
return 0;
- /* On the i915, GPU access to tiled buffers is via a fence,
-* therefore we must wait for any outstanding access to complete
-* before clearing the fence.
+ /* If there is outstanding activity on the buffer whilst it holds
+* a fence register we must assume that it requires that fence for
+* correct operation. Therefore we must wait for any outstanding
+* access to complete before clearing the fence.
*/
- if (!IS_I965G(dev)) {
- int ret;
+ i915_gem_object_flush_gpu_write_domain(obj);
+ i915_gem_object_flush_gtt_write_domain(obj);
+ ret = i915_gem_object_wait_rendering(obj);
+ if (ret != 0)
+ return ret;
- i915_gem_object_flush_gpu_write_domain(obj);
- i915_gem_object_flush_gtt_write_domain(obj);
- ret = i915_gem_object_wait_rendering(obj);
- if (ret != 0)
- return ret;
- }
+ i915_gem_clear_fence_reg(obj);
- i915_gem_clear_fence_reg (obj);
+ /* Reacquire fence register on next mmap access (via page fault) */
+ if (obj_priv->mmap_offset)
+ unmap_mapping_range(dev->dev_mapping,
+ obj_priv->mmap_offset, obj->size, 1);
return 0;
}
--
1.6.3.3
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm: previous pull req + 1.
On Mon, 2009-06-22 at 21:09 +0300, Maxim Levitsky wrote:
> Nope, same thing.
>
> I use commit 87ef92092fd092936535ba057ee19b97bb6a709a + this patch
> Note that GE doesn't hang the system when maximizing it.
>
> It is for sure tiled textures accessed incorrectly, same behavior
> observed in many games (they still run though)
Sorry for the delay, I was travelling last week and was sure I had
nailed the problem. Aside from the missing flush on i965 when a batch
buffer might be using fenced commands, the only other issue I found was
that we did not zap the mapping range 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: Remove mappings on clearing fence register
As the fence register is not locked whilst the user has mmaped the buffer
through the GTT, in order for the buffer to reacquire a fence register we
need to cause a fresh page-fault on the next user access. In order to
cause the page fault, we zap the current mapping on clearing the register.
We also ensure that all potential outstanding access via the fence
register is flushed before release as well.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 41 ++
1 files changed, 19 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 685a876..6dc74c8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1946,12 +1946,6 @@ i915_gem_object_unbind(struct drm_gem_object *obj)
obj_priv->agp_mem = NULL;
}
-
- /* blow away mappings if mapped through GTT */
- if (obj_priv->mmap_offset && dev->dev_mapping)
- unmap_mapping_range(dev->dev_mapping,
- obj_priv->mmap_offset, obj->size, 1);
-
i915_gem_object_put_pages(obj);
BUG_ON(obj_priv->pages);
@@ -2350,8 +2344,7 @@ try_again:
if (old_obj_priv->pin_count)
continue;
- /* i915 uses fences for GPU access to tiled buffers */
- if (IS_I965G(dev) || !old_obj_priv->active)
+ if (!old_obj_priv->active)
break;
/* find the seqno of the first available fence */
@@ -2440,6 +2433,8 @@ i915_gem_clear_fence_reg(struct drm_gem_object *obj)
obj_priv->gtt_offset, obj->size);
#endif
+ BUG_ON(obj_priv->active);
+
if (IS_I965G(dev))
I915_WRITE64(FENCE_REG_965_0 + (obj_priv->fence_reg * 8), 0);
else {
@@ -2456,6 +2451,11 @@ i915_gem_clear_fence_reg(struct drm_gem_object *obj)
dev_priv->fence_regs[obj_priv->fence_reg].obj = NULL;
obj_priv->fence_reg = I915_FENCE_REG_NONE;
+
+ /* blow away mappings if mapped through GTT */
+ if (obj_priv->mmap_offset && dev->dev_mapping)
+ unmap_mapping_range(dev->dev_mapping,
+ obj_priv->mmap_offset, obj->size, 1);
}
/**
@@ -2469,27 +2469,24 @@ i915_gem_clear_fence_reg(struct drm_gem_object *obj)
int
i915_gem_object_put_fence_reg(struct drm_gem_object *obj)
{
- struct drm_device *dev = obj->dev;
struct drm_i915_gem_object *obj_priv = obj->driver_private;
+ int ret;
if (obj_priv->fence_reg == I915_FENCE_REG_NONE)
return 0;
- /* On the i915, GPU access to tiled buffers is via a fence,
-* therefore we must wait for any outstanding access to complete
-* before clearing the fence.
+ /* If there is outstanding activity on the buffer whilst it holds
+* a fence register we must assume that it requires that fence for
+* correct operation. Therefore we must wait for any outstanding
+* access to complete before clearing the fence.
*/
- if (!IS_I965G(dev)) {
- int ret;
-
- i915_gem_object_flush_gpu_write_domain(obj);
- i915_gem_object_flush_gtt_write_domain(obj);
- ret = i915_gem_object_wait_rendering(obj);
- if (ret != 0)
- return ret;
- }
+ i915_gem_object_flush_gpu_write_domain(obj);
+ i915_gem_object_flush_gtt_write_domain(obj);
+ ret = i915_gem_object_wait_rendering(obj);
+ if (ret != 0)
+ return ret;
- i915_gem_clear_fence_reg (obj);
+ i915_gem_clear_fence_reg(obj);
return 0;
}
--
1.6.3.1
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm: previous pull req + 1.
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 presumption that only the i915 was using
fences for GPU access. (In hindsight, it seems obvious that we do not
know why the fence was allocated for the object and so if it has
outstanding rendering, we must assume that it is using a fence for a
rendering op.)
To confirm, please can you try:
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index fd2b8bd..0735518 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2347,7 +2347,7 @@ i915_gem_object_put_fence_reg(struct
drm_gem_object *obj)
* therefore we must wait for any outstanding access to complete
* before clearing the fence.
*/
- if (!IS_I965G(dev)) {
+ if (1) {
int ret;
i915_gem_object_flush_gpu_write_domain(obj);
(I'm travelling tomorrow, so if this does turn out to be the fault, I'd
appreciate it if someone wrote it up as a complete patch.)
> However I can't reproduce the situation I have earlier, maybe I have changed
> some settings, don't know.
> Now, the bad behavior (and I reproduced it many times, is that GE shows
> incorrect textures
> (like they are divided in tiny interlaced rows, one row ok, other contain
> image from other part of world), only few textures are such
> it seems logical that this is related to tiling.
What you describe is exactly the artefact you would see when you access
a tiled texture using linear addressing. Pretty conclusive evidence that
we do need to flush outstanding GPU access.
> Also, if I maximize it, it hangs. This seems to be a separate bug introduced
> by these series.
It does seem like a separate bug. Hopefully, we can get a better handle
on it after we fix this obnoxious tiling issue.
-ickle
--
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm v2.6.31 merge (part 1)
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: [PATCH 08/10] drm: Memory fragmentation from lost alignment blocks
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 a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 367c590..68e1b06 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -138,36 +138,34 @@ static struct drm_mm_node *drm_mm_split_at_start(struct
drm_mm_node *parent,
}
-
-struct drm_mm_node *drm_mm_get_block(struct drm_mm_node * parent,
+struct drm_mm_node *drm_mm_get_block(struct drm_mm_node * node,
unsigned long size, unsigned alignment)
{
struct drm_mm_node *align_splitoff = NULL;
- struct drm_mm_node *child;
unsigned tmp = 0;
if (alignment)
- tmp = parent->start % alignment;
+ tmp = node->start % alignment;
if (tmp) {
- align_splitoff = drm_mm_split_at_start(parent, alignment - tmp);
+ align_splitoff = drm_mm_split_at_start(node, alignment - tmp);
if (!align_splitoff)
return NULL;
+
}
- if (parent->size == size) {
- list_del_init(&parent->fl_entry);
- parent->free = 0;
- return parent;
+ if (node->size == size) {
+ list_del_init(&node->fl_entry);
+ node->free = 0;
} else {
- child = drm_mm_split_at_start(parent, size);
+ node = drm_mm_split_at_start(node, size);
}
if (align_splitoff)
drm_mm_put_block(align_splitoff);
- return child;
+ return node;
}
EXPORT_SYMBOL(drm_mm_get_block);
--
1.6.3.1
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: Memory fragmentation from lost alignment blocks
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 a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 367c590..68e1b06 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -138,36 +138,34 @@ static struct drm_mm_node *drm_mm_split_at_start(struct
drm_mm_node *parent,
}
-
-struct drm_mm_node *drm_mm_get_block(struct drm_mm_node * parent,
+struct drm_mm_node *drm_mm_get_block(struct drm_mm_node * node,
unsigned long size, unsigned alignment)
{
struct drm_mm_node *align_splitoff = NULL;
- struct drm_mm_node *child;
unsigned tmp = 0;
if (alignment)
- tmp = parent->start % alignment;
+ tmp = node->start % alignment;
if (tmp) {
- align_splitoff = drm_mm_split_at_start(parent, alignment - tmp);
+ align_splitoff = drm_mm_split_at_start(node, alignment - tmp);
if (!align_splitoff)
return NULL;
+
}
- if (parent->size == size) {
- list_del_init(&parent->fl_entry);
- parent->free = 0;
- return parent;
+ if (node->size == size) {
+ list_del_init(&node->fl_entry);
+ node->free = 0;
} else {
- child = drm_mm_split_at_start(parent, size);
+ node = drm_mm_split_at_start(node, size);
}
if (align_splitoff)
drm_mm_put_block(align_splitoff);
- return child;
+ return node;
}
EXPORT_SYMBOL(drm_mm_get_block);
--
1.6.3.1
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: A17 tiling series V2
On Wed, 2009-04-08 at 11:05 -0700, Eric Anholt wrote:
> Here's the pair of patches I've got to make A17-afflicted machines do tiling.
> I've created regression tests for swapping tiled objects and for pread on
> tiled objects, and I'm at 1/10 failures in intel-gpu-tools, or 0/10 if I
> disable BO reuse (appears to be a bug in fencing on objects getting reused
> as tiled after being linear). 3D performance is back to normal on my
> affected 945GM, and no_rast=true glxgears looks good.
Sounds like this patch should do the trick...
>From 1c5d1156f0f467568b1eab18a33dd9edc3579ce5 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 changed as well.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h|1 +
drivers/gpu/drm/i915/i915_gem.c| 37 +-
drivers/gpu/drm/i915/i915_gem_tiling.c | 54
++-
3 files changed, 75 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 3784cfc..833ad26 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -628,6 +628,7 @@ void i915_gem_object_unpin(struct drm_gem_object
*obj);
int i915_gem_object_unbind(struct drm_gem_object *obj);
void i915_gem_lastclose(struct drm_device *dev);
uint32_t i915_get_gem_seqno(struct drm_device *dev);
+int i915_gem_object_put_fence_reg(struct drm_gem_object *obj);
void i915_gem_retire_requests(struct drm_device *dev);
void i915_gem_retire_work_handler(struct work_struct *work);
void i915_gem_clflush_object(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index 5848c1d..43c71de 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2019,7 +2019,6 @@ static void i830_write_fence_reg(struct
drm_i915_fence_reg *reg)
val |= I830_FENCE_REG_VALID;
I915_WRITE(FENCE_REG_830_0 + (regnum * 4), val);
-
}
/**
@@ -2211,6 +2210,42 @@ i915_gem_clear_fence_reg(struct drm_gem_object
*obj)
}
/**
+ * i915_gem_object_put_fence_reg - waits on outstanding fenced access
+ * to the buffer to finish, and then resets the fence register.
+ * @obj: tiled object holding a fence register.
+ *
+ * Zeroes out the fence register itself and clears out the associated
+ * data structures in dev_priv and obj_priv.
+ */
+int
+i915_gem_object_put_fence_reg(struct drm_gem_object *obj)
+{
+ struct drm_device *dev = obj->dev;
+ struct drm_i915_gem_object *obj_priv = obj->driver_private;
+
+ if (obj_priv->fence_reg == I915_FENCE_REG_NONE)
+ return 0;
+
+ /* On the i915, GPU access to tiled buffers is via a fence,
+* therefore we must wait for any outstanding access to complete
+* before clearing the fence.
+*/
+ if (!IS_I965G(dev)) {
+ int ret;
+
+ i915_gem_object_flush_gpu_write_domain(obj);
+ i915_gem_object_flush_gtt_write_domain(obj);
+ ret = i915_gem_object_wait_rendering(obj);
+ if (ret != 0)
+ return ret;
+ }
+
+ i915_gem_clear_fence_reg (obj);
+
+ return 0;
+}
+
+/**
* Finds free space in the GTT aperture and binds the object there.
*/
static int
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index 6be3f92..373e457 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -255,6 +255,21 @@ i915_tiling_ok(struct drm_device *dev, int stride,
int size, int tiling_mode)
return true;
}
+static bool
+i915_gem_object_tiling_ok (struct drm_gem_object *obj, int tiling_mode)
+{
+ struct drm_i915_gem_object *obj_priv = obj->driver_private;
+
+ if (obj_priv->gtt_space == NULL)
+ return true;
+
+ if (tiling_mode == I915_TILING_NONE)
+ return true;
+
+ return (obj_priv->gtt_offset & ~I915_FENCE_START_MASK) == 0 &&
+ (obj_priv->gtt_offset & (obj->size - 1)) == 0;
+}
+
/**
* Sets the tiling mode of an object, returning the required swizzling
of
* bit 6 of addresses in the object.
@@ -267,6 +282,7 @@ i915_gem_set_tiling(struct drm_device *dev, void
*data,
drm_i915_private_t *dev_priv = dev->dev_private;
struct drm_gem_object *obj;
struct drm_i915_gem_object *obj_priv;
+ int ret = 0;
obj = drm_gem_object_lookup(dev, file_priv, args->handle);
if (obj == NULL)
@@ -274,15 +290,15 @@ i915_gem_set_tiling(struct drm_device *dev, void
*data,
obj_priv = obj->driver_private;
if (!i915_tiling_ok(dev, ar
Re: [Intel-gfx] [PATCH] i915: support page flipping
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_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. > > > > > > If a flip is already pending on the object in question, the ioctl waits > > > for it to finish first, then queues the flip. An optional wait flag > > > causes the ioctl to wait for the flip to complete before the it returns. > > > > > > If an execbuffer containing an object with a pending flip comes in, it > > > will stall until the flip completes, to preserve glXSwapBuffers > > > semantics. > > > > > > Signed-off-by: Jesse Barnes Hmm, I finally got around to trying this updated variant of the page-flipping patch having hit a situation whereby the lack of unpinning of the new scanout buffer was consuming all the fence registers. The downside of this version, which unpins after vblank, is that this leaves the fence register covering the scanout buffer on the i915 available for reuse. [This also confirms that the scanout memory is vulnerable to an unbind().] The bo must remain pinned until it is no longer the scanout target -- the flickering (as the scanout rapidly switches between tiled and untiled) on my i915 is unbearable :( -ickle -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: Check for dev->primary->master before dereference.
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 |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 2f2d34c..a4b3edc 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -41,7 +41,6 @@
int i915_wait_ring(struct drm_device * dev, int n, const char *caller)
{
drm_i915_private_t *dev_priv = dev->dev_private;
- struct drm_i915_master_private *master_priv =
dev->primary->master->driver_priv;
drm_i915_ring_buffer_t *ring = &(dev_priv->ring);
u32 acthd_reg = IS_I965G(dev) ? ACTHD_I965 : ACTHD;
u32 last_acthd = I915_READ(acthd_reg);
@@ -58,8 +57,12 @@ int i915_wait_ring(struct drm_device * dev, int n, const
char *caller)
if (ring->space >= n)
return 0;
- if (master_priv->sarea_priv)
- master_priv->sarea_priv->perf_boxes |= I915_BOX_WAIT;
+ if (dev->primary->master) {
+ struct drm_i915_master_private *master_priv =
dev->primary->master->driver_priv;
+ if (master_priv->sarea_priv)
+ master_priv->sarea_priv->perf_boxes |=
I915_BOX_WAIT;
+ }
+
if (ring->head != last_head)
i = 0;
--
1.6.0.4
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] i915: support page flipping
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 error here? (And it might
> > be helpful to printk the original error value.)
>
> Oh I'm not sure what's going on there; I've changed it to just return the pin
> failure.
>
> > > + * Put the object in the GTT domain before the flip,
> > > + * since there may be outstanding rendering
> > > + */
> > > + i915_gem_object_set_to_gtt_domain(obj, 0);
> >
> > Need to check, report and handle errors here. And yes, these do occur in
> > the wild for some as of yet unknown reason.
>
> Fixed. Though Mesa is now flushing before calling the server so it should
> happen less often.
I found the source of the errors - ERESTARTSYS, so presumably we need to
add
if (ret == -ERESTARTSYS) ret = -EINTR;
handling here (after pining and flushing)?
-ickle
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] i915: support page flipping
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.
>
> If a flip is already pending on the object in question, the ioctl waits for
> it to finish first, then queues the flip. An optional wait flag causes the
> ioctl to wait for the flip to complete before the it returns.
>
> If an execbuffer containing an object with a pending flip comes in, it will
> stall until the flip completes, to preserve glXSwapBuffers semantics.
>
> Signed-off-by: Jesse Barnes
Didn't do too bad in spotting the missing checks... ;-)
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 2d797ff..0d6a6d3 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -829,6 +829,175 @@ static int i915_set_status_page(struct drm_device *dev,
> void *data,
> return 0;
> }
>
> +static int i915_pipe_to_plane(struct drm_device *dev, int pipe)
> +{
> + drm_i915_private_t *dev_priv = dev->dev_private;
> + u32 reg, pipe_mask;
> +
> + if (pipe == 0)
> + pipe_mask = DISPPLANE_SEL_PIPE_A;
> + else
> + pipe_mask = DISPPLANE_SEL_PIPE_B;
> +
> + pipe_mask |= DISPLAY_PLANE_ENABLE;
> +
> + reg = I915_READ(DSPACNTR);
> + if ((reg & (DISPLAY_PLANE_ENABLE | DISPPLANE_SEL_PIPE_MASK)) ==
> + pipe_mask)
> + return 0;
> +
> + reg = I915_READ(DSPBCNTR);
> + if ((reg & (DISPLAY_PLANE_ENABLE | DISPPLANE_SEL_PIPE_MASK)) ==
> + pipe_mask)
> + return 1;
> +
> + return -1;
> +}
> +
> +bool
> +i915_gem_flip_pending(struct drm_gem_object *obj)
> +{
> + struct drm_device *dev = obj->dev;
> + drm_i915_private_t *dev_priv = dev->dev_private;
> + struct drm_i915_gem_object *obj_priv = obj->driver_private;
> + unsigned long flags;
> + bool pending = false;
> +
> + spin_lock_irqsave(&dev_priv->vblank_lock, flags);
> + if (!list_empty(&obj_priv->vblank_head))
> + pending = true;
This has annoyed me every time (but I'm running out of things I can
complain about ;-), can we just say
pending = !list_empty();
and be done with the conditional.
> + spin_unlock_irqrestore(&dev_priv->vblank_lock, flags);
> +
> + return pending;
> +}
> +
> +static int i915_gem_page_flip(struct drm_device *dev, void *data,
> + struct drm_file *file_priv)
> +{
> + struct drm_i915_gem_page_flip *flip_data = data;
> + drm_i915_private_t *dev_priv = dev->dev_private;
> + struct drm_gem_object *obj;
> + struct drm_i915_gem_object *obj_priv;
> + unsigned long flags;
> + uint32_t offset;
> + unsigned int pitch, pipe, plane, tiled;
> + int ret = 0, vblank_ref_err = 0, reqno;
> + RING_LOCALS;
> +
> + if (!(dev->driver->driver_features & DRIVER_GEM))
> + return -ENODEV;
Guess I'll just have to comment this out to continue testing this
feature. :-)
> +
> + /*
> + * Reject unknown flags so future userspace knows what we (don't)
> + * support
> + */
> + if (flip_data->flags & (~I915_PAGE_FLIP_WAIT)) {
> + DRM_ERROR("bad page flip flags\n");
> + return -EINVAL;
> + }
> +
> + if ((pipe = flip_data->pipe) > 1) {
> + DRM_ERROR("bad pipe\n");
> + return -EINVAL;
> + }
> +
> + plane = i915_pipe_to_plane(dev, pipe);
> + if (plane < 0) {
> + DRM_ERROR("bad pipe (no planes enabled?)\n");
> + return -EINVAL;
> + }
> +
> + obj = drm_gem_object_lookup(dev, file_priv, flip_data->handle);
> + if (obj == NULL)
> + return -EBADF;
> +
> + /*
> + * Make sure the new buffer is in bounds
> + * FIXME: should probably check against current mode as well
> + */
> + if (flip_data->offset >= obj->size) {
> + DRM_ERROR("bad flip offset\n");
> + ret = -EINVAL;
> + goto out_unref_prelock;
> + }
> +
> + obj_priv = obj->driver_private;
Need to check obj_priv->stride&7 == 0. Hmm, that may be impossible
anyway.
> +
> + if (i915_gem_flip_pending(obj))
> + wait_for_completion(&obj_priv->vblank);
> +
> + mutex_lock(&dev->struct_mutex);
> + if (obj_priv->tiling_mode != I915_TILING_NONE &&
> + obj_priv->tiling_mode != I915_TILING_X) {
> + DRM_ERROR("can only flip non-tiled or X tiled pages\n");
> + ret = -EINVAL;
> + goto out_unref;
> + }
> +
> + vblank_ref_err = drm_vblank_get(dev, pipe);
> + if (!vblank_ref_err) {
Ok, this seems like a reasonable fallback. If vblank is not enabled then
you just queue the flip without waiting.
> + ret = i915_gem_object_pin(obj, 0);
> + if (ret) {
> +
[PATCH] drm/i915: Fix regression in 95ca9d
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/drivers/gpu/drm/i915/i915_gem.c
index a1c0950..1a1220d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3282,16 +3282,20 @@ static void
i915_gem_cleanup_hws(struct drm_device *dev)
{
drm_i915_private_t *dev_priv = dev->dev_private;
- struct drm_gem_object *obj = dev_priv->hws_obj;
- struct drm_i915_gem_object *obj_priv = obj->driver_private;
+ struct drm_gem_object *obj;
+ struct drm_i915_gem_object *obj_priv;
if (dev_priv->hws_obj == NULL)
return;
+ obj = dev_priv->hws_obj;
+ obj_priv = obj->driver_private;
+
kunmap(obj_priv->page_list[0]);
i915_gem_object_unpin(obj);
drm_gem_object_unreference(obj);
dev_priv->hws_obj = NULL;
+
memset(&dev_priv->hws_map, 0, sizeof(dev_priv->hws_map));
dev_priv->hw_status_page = NULL;
--
1.6.0.4
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Acid-like effect in dark regions on key press
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 before and afterwards (which implies that the scan-out buffer was read back through the GTT and remained as the scan-out buffer with the effect still apparent) - only the read back image is perfect and shows no artefact. After a while (with no interaction and I think no execution of batch buffers), the display magically returns to normal. I'm open to suggestions as how to diagnose this problem and track down the cause. Thanks. -ickle -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] i915: add page flipping ioctl
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 reminded me that we want a buffer offset along with the
handle.
> >+uint32_t handle;
> >+
> >+/**
> >+ * page flip flags (wait on flip only for now)
> >+ */
> >+uint32_t flags;
> >+
> >+/**
> >+ * pipe to flip
> >+ */
> >+uint32_t pipe;
> >+
> >+/**
> >+ * screen dimensions for flip
> >+ */
> >+uint32_t x;
> >+uint32_t y;
> >+};
> >+
> > #endif /* _I915_DRM_H_ */
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] i915: add page flipping ioctl
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 > > 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 eventually unpinned, and you might choose to drop the > > mutex around the wait_for_vblank ;-): > > Yeah, looks pretty reasonable. Here's what I've been working with. It adds > a > couple of more changes (and slightly different cleanups) over your version: > - added a seqno to wait for > - wait for flip before queuing another > but it's missing thew 915 changes you added (btw did I get the pitch wrong? > or are you submitting a different value for your objects?). No, you wrote "pitch = (stride / 8) * 8", I was halfway through converting that into an -EINVAL guard as opposed to rounding down an invalid stride. > I added a new seqno since it's possible (even likely) that the next vblank > won't actually reflect the flip, if the GPU is busy processing a large > batchbuffer when the ring command goes in for example. Yes, that might explain the rare tearing glitch I see. > Also it might be a good idea to wait for any previous flip before queuing a > new one. Anyway still tracking down some issues with the X side, but it > seems > like it's approaching readiness. Give or take not checking for errors and not holding the mutex for long enough. ;-) -ickle -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] i915: add page flipping ioctl
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 eventually unpinned, and you might choose to drop the
mutex around the wait_for_vblank ;-):
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index bc440ff..b4d347c 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -835,19 +835,18 @@ static int i915_pipe_to_plane(struct drm_device *dev, int
pipe)
u32 reg, pipe_mask;
if (pipe == 0)
- pipe_mask = DISPPLANE_SEL_PIPE_A;
+ pipe_mask = DISPPLANE_SEL_PIPE_A | DISPLAY_PLANE_ENABLE;
else
- pipe_mask = DISPPLANE_SEL_PIPE_B;
+ pipe_mask = DISPPLANE_SEL_PIPE_B | DISPLAY_PLANE_ENABLE;
+#define DISPPLANE_ENABLED_PIPE_MASK (DISPLAY_PLANE_ENABLE |
DISPPLANE_SEL_PIPE_MASK)
reg = I915_READ(DSPACNTR);
- if ((reg & DISPLAY_PLANE_ENABLE) &&
- ((reg & DISPPLANE_SEL_PIPE_MASK) == pipe_mask))
- return 0;
+ if ((reg & DISPPLANE_ENABLED_PIPE_MASK) == pipe_mask)
+ return 0;
reg = I915_READ(DSPBCNTR);
- if ((reg & DISPLAY_PLANE_ENABLE) &&
- ((reg & DISPPLANE_SEL_PIPE_MASK) == pipe_mask))
- return 1;
+ if ((reg & DISPPLANE_ENABLED_PIPE_MASK) == pipe_mask)
+ return 1;
return -1;
}
@@ -893,6 +892,8 @@ static int i915_gem_page_flip(struct drm_device *dev, void
*data,
return -EBADF;
obj_priv = obj->driver_private;
+
+ mutex_lock(&dev->struct_mutex);
if (obj_priv->tiling_mode != I915_TILING_NONE &&
obj_priv->tiling_mode != I915_TILING_X) {
DRM_ERROR("can only flip non-tiled or X tiled pages\n");
@@ -903,13 +904,18 @@ static int i915_gem_page_flip(struct drm_device *dev,
void *data,
ret = i915_gem_object_pin(obj, 0);
if (ret) {
DRM_ERROR("failed to pin object for flip\n");
- ret = -EBUSY;
+ goto out_unref;
+ }
+
+ ret = i915_gem_object_set_to_gtt_domain(obj, 0);
+ if (ret) {
+ DRM_ERROR("failed to set object to gtt domain for flip\n");
goto out_unref;
}
offset = obj_priv->gtt_offset;
pitch = obj_priv->stride;
- tiled = !!(obj_priv->tiling_mode == I915_TILING_X);
+ tiled = obj_priv->tiling_mode == I915_TILING_X;
/*
* Queue the flip with the lock held in case the flip happens
@@ -919,21 +925,27 @@ static int i915_gem_page_flip(struct drm_device *dev,
void *data,
BEGIN_LP_RING(4);
OUT_RING(CMD_OP_DISPLAYBUFFER_INFO | (plane << 20));
- OUT_RING((pitch / 8) << 3); /* flip queue and/or pitch */
- OUT_RING(offset | tiled);
- OUT_RING(((flip_data->x - 1) << 16) | (flip_data->y - 1));
+ OUT_RING(pitch);
+ if (IS_I965G(dev)) {
+ OUT_RING(offset | tiled);
+ OUT_RING(((flip_data->x - 1) << 16) | (flip_data->y - 1));
+ } else {
+ OUT_RING(offset);
+ OUT_RING(0);
+ }
ADVANCE_LP_RING();
- list_add_tail(&obj_priv->vblank_head, &dev_priv->mm.vblank_list[pipe]);
- drm_vblank_get(dev, pipe);
+ ret = drm_vblank_get(dev, pipe);
+ if (ret == 0)
+ list_add_tail(&obj_priv->vblank_head,
+ &dev_priv->mm.vblank_list[pipe]);
spin_unlock_irqrestore(&dev_priv->vblank_lock, flags);
- if (flip_data->flags & I915_PAGE_FLIP_WAIT)
+ if (ret == 0 && flip_data->flags & I915_PAGE_FLIP_WAIT)
wait_for_completion(&obj_priv->vblank);
out_unref:
- mutex_lock(&dev->struct_mutex);
drm_gem_object_unreference(obj);
mutex_unlock(&dev->struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8f2dc72..28e8177 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2467,6 +2467,25 @@ i915_gem_ring_throttle(struct drm_device *dev, struct
drm_file *file_priv)
return ret;
}
+static void
+i915_gem_object_wait_for_vblank(struct drm_device *dev,
+ struct drm_gem_object *obj)
+{
+ drm_i915_private_t *dev_priv = dev->dev_private;
+ struct drm_i915_gem_object *obj_priv;
+ unsigned long irqflags;
+ int wait_for_vblank;
+
+ obj_priv = obj->driver_private;
+
+ spin_lock_irqsave(&dev_priv->vblank_lock, irqflags);
+ wait_for_vblank = !list_empty(&obj_priv->vblank_head);
+ spin_unlock_irqrestore(&dev_priv->vblank_lock, irqflags);
+
+ if (wait_for_vblank)
+ wait_for_completion(&obj_priv->vblank);
+}
+
int
i915_gem_execbuffer(str
Re: [PATCH] i915: add page flipping ioctl
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? (I double-checked with lockdep in case I had missed an obvious
> > dead-lock.) Comments on the patch itself inline.
>
> Thanks a lot for looking at this and testing.
>
> Hm, maybe you're not getting vblank interrupts at all? Do you see the count
> increasing? Is the IRQ registered?
Apparently, the vblank is never being enabled... Adding a BUG_ON() to
drm_vblank_put() soon identified the unbalanced culprit. So it appears
that drm_vblank_pre_modeset() can fail to enable vblank, obviously
because at that point we have never enabled vblank in pipeconf - but we
unconditionally decrement the vblank reference counter afterwards. Ok,
so now I see lots of vblank interrupts but the display is still snafu.
The following patch is a crude fix.
>From 1c4fa54654a604e0ea604553b983dca737a76e99 Mon Sep 17 00:00:00 2001
From: Chris Wilson
Date: Thu, 19 Feb 2009 14:48:22 +
Subject: [PATCH] drm: Correct unbalanced drm_vblank_put() during mode
setting.
The first time we install a mode, the vblank will be disabled for a pipe
and so drm_vblank_get() in drm_vblank_pre_modeset() will fail. As we
unconditionally call drm_vblank_put() afterwards, the vblank reference
counter becomes unbalanced.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_irq.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 3795dbc..93e677a 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -435,6 +435,8 @@ EXPORT_SYMBOL(drm_vblank_get);
*/
void drm_vblank_put(struct drm_device *dev, int crtc)
{
+ BUG_ON (atomic_read (&dev->vblank_refcount[crtc]) == 0);
+
/* Last user schedules interrupt disable */
if (atomic_dec_and_test(&dev->vblank_refcount[crtc]))
mod_timer(&dev->vblank_disable_timer, jiffies + 5*DRM_HZ);
@@ -460,8 +462,9 @@ void drm_vblank_pre_modeset(struct drm_device *dev,
int crtc)
* so that interrupts remain enabled in the interim.
*/
if (!dev->vblank_inmodeset[crtc]) {
- dev->vblank_inmodeset[crtc] = 1;
- drm_vblank_get(dev, crtc);
+ dev->vblank_inmodeset[crtc] = 0x1;
+ if (drm_vblank_get(dev, crtc) == 0)
+ dev->vblank_inmodeset[crtc] |= 0x2;
}
}
EXPORT_SYMBOL(drm_vblank_pre_modeset);
@@ -473,9 +476,12 @@ void drm_vblank_post_modeset(struct drm_device
*dev, int crtc)
if (dev->vblank_inmodeset[crtc]) {
spin_lock_irqsave(&dev->vbl_lock, irqflags);
dev->vblank_disable_allowed = 1;
- dev->vblank_inmodeset[crtc] = 0;
spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
- drm_vblank_put(dev, crtc);
+
+ if (dev->vblank_inmodeset[crtc] & 0x2)
+ drm_vblank_put(dev, crtc);
+
+ dev->vblank_inmodeset[crtc] = 0;
}
}
EXPORT_SYMBOL(drm_vblank_post_modeset);
--
1.6.0.4
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] i915: add page flipping ioctl
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 will figure out the pitch of the new frontbuffer automatically,
> but the caller has to pass in dimensions and pipe information.
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? (I double-checked with lockdep in case I had missed an obvious
dead-lock.) Comments on the patch itself inline.
> Signed-off-by: Jesse Barnes
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index cbb8224..2518ebd 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -829,6 +829,117 @@ static int i915_set_status_page(struct drm_device *dev,
> void *data,
> return 0;
> }
>
> +static int i915_pipe_to_plane(struct drm_device *dev, int pipe)
> +{
> + drm_i915_private_t *dev_priv = dev->dev_private;
> + u32 reg, pipe_mask;
> +
> + if (pipe == 0)
> + pipe_mask = DISPPLANE_SEL_PIPE_A;
> + else
> + pipe_mask = DISPPLANE_SEL_PIPE_B;
> +
> + reg = I915_READ(DSPACNTR);
> + if ((reg & DISPLAY_PLANE_ENABLE) &&
> + ((reg & DISPPLANE_SEL_PIPE_MASK) == pipe_mask))
> + return 0;
Would this be easier to read as:
pipe_mask |= DISPLAY_PLANE_ENABLE;
reg = I915_READ(DSPACNTR);
if ((reg & (DISPLAY_PLANE_ENABLE | DISPPLANE_SEL_PIPE_MASK)) == pipe_mask)
return 0;
reg = I915_READ(DSPBCNTR);
if ((reg & (DISPLAY_PLANE_ENABLE | DISPPLANE_SEL_PIPE_MASK)) == pipe_mask)
return 1;
> +
> + reg = I915_READ(DSPBCNTR);
> + if ((reg & DISPLAY_PLANE_ENABLE) &&
> + ((reg & DISPPLANE_SEL_PIPE_MASK) == pipe_mask))
> + return 1;
> +
> + return -1;
> +}
> +
> +static int i915_gem_page_flip(struct drm_device *dev, void *data,
> + struct drm_file *file_priv)
> +{
> + struct drm_i915_gem_page_flip *flip_data = data;
> + drm_i915_private_t *dev_priv = dev->dev_private;
> + struct drm_gem_object *obj;
> + struct drm_i915_gem_object *obj_priv;
> + unsigned long flags;
> + uint32_t offset;
> + int pitch, pipe, plane, tiled;
> + int ret = 0;
> + RING_LOCALS;
> +
> + if (!(dev->driver->driver_features & DRIVER_GEM))
> + return -ENODEV;
> +
> + /*
> + * Reject unknown flags so future userspace knows what we (don't)
> + * support
> + */
> + if (flip_data->flags & (~I915_PAGE_FLIP_WAIT)) {
> + DRM_ERROR("bad page flip flags\n");
> + return -EINVAL;
> + }
> +
> + if ((pipe = flip_data->pipe) > 1) {
> + DRM_ERROR("bad pipe\n");
> + return -EINVAL;
> + }
> +
> + plane = i915_pipe_to_plane(dev, pipe);
> + if (plane < 0) {
> + DRM_ERROR("bad pipe (no planes enabled?)\n");
> + return -EINVAL;
> + }
> +
> + obj = drm_gem_object_lookup(dev, file_priv, flip_data->handle);
> + if (obj == NULL)
> + return -EBADF;
> +
> + obj_priv = obj->driver_private;
Need to take the dev->struct_mutex here whilst reading the tiling
parameters and pinning.
> + if (obj_priv->tiling_mode != I915_TILING_NONE &&
> + obj_priv->tiling_mode != I915_TILING_X) {
> + DRM_ERROR("can only flip non-tiled or X tiled pages\n");
> + ret = -EINVAL;
> + goto out_unref;
> + }
> +
> + ret = i915_gem_object_pin(obj, 0);
Since we do not appear to explicitly track and unpin the old scan-out
buffer, presumably we are just reliant on user space destroying the old
buffers in a timely manner in order to recover their gtt space (and the
precious fence register)?
> + if (ret) {
> + DRM_ERROR("failed to pin object for flip\n");
> + ret = -EBUSY;
> + goto out_unref;
> + }
> +
> + offset = obj_priv->gtt_offset;
> + pitch = obj_priv->stride;
> + tiled = !!(obj_priv->tiling_mode == I915_TILING_X);
Having pinned the buffer, we can now drop the mutex.
> + /*
> + * Queue the flip with the lock held in case the flip happens
> + * immediately.
> + */
> + spin_lock_irqsave(&dev_priv->vblank_lock, flags);
vblank_lock is never initialised.
> +
> + BEGIN_LP_RING(4);
> + OUT_RING(CMD_OP_DISPLAYBUFFER_INFO | (plane << 20));
> + OUT_RING((pitch / 8) << 3); /* flip queue and/or pitch */
> + OUT_RING(offset | tiled);
> + OUT_RING(((flip_data->x - 1) << 16) | (flip_data->y - 1));
x/y look reversed compared to other commands (but I'm just speculating
without the documentation).
> + ADVANCE_LP_RING();
> +
> + list_add_tail(&obj_priv->vblank_head, &dev_priv->mm.v
Re: [PATCH] [drm] Release user fbs in drm_release
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 Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Gem GTT mmaps..
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 cases you found.
> - ref at map time will keep the object around so fault shouldn't fail
> - additional threads will take their refs in vm_open/close
> - unmap will unref and remove mmap_offset allowing object to be freed
>
> --
> Jesse Barnes, Intel Open Source Technology Center
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 6915fb8..2752114 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -460,6 +460,23 @@ drm_gem_object_handle_free(struct kref *kref)
> }
> EXPORT_SYMBOL(drm_gem_object_handle_free);
>
> +void drm_gem_vm_open(struct vm_area_struct *vma)
> +{
> + struct drm_gem_object *obj = vma->vm_private_data;
> +
> + drm_gem_object_reference(obj);
> +}
> +EXPORT_SYMBOL(drm_gem_vm_open);
> +
> +void drm_gem_vm_close(struct vm_area_struct *vma)
> +{
> + struct drm_gem_object *obj = vma->vm_private_data;
> +
> + drm_gem_object_unreference(obj);
Need to take the dev->struct_mutex for this potential free.
> +}
> +EXPORT_SYMBOL(drm_gem_vm_close);
> +
> +
> /**
> * drm_gem_mmap - memory map routine for GEM objects
> * @filp: DRM file pointer
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index aac12ee..a31cbdb 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -94,6 +94,8 @@ static int i915_resume(struct drm_device *dev)
>
> static struct vm_operations_struct i915_gem_vm_ops = {
> .fault = i915_gem_fault,
> + .open = drm_gem_vm_open,
> + .close = drm_gem_vm_close,
> };
>
> static struct drm_driver driver = {
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 1441831..a476de0 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -52,6 +52,7 @@ static void i915_gem_object_free_page_list(struct
> drm_gem_object *obj);
> static int i915_gem_object_wait_rendering(struct drm_gem_object *obj);
> static int i915_gem_object_bind_to_gtt(struct drm_gem_object *obj,
> unsigned alignment);
> +static void i915_gem_free_mmap_offset(struct drm_gem_object *obj);
> static int i915_gem_object_get_fence_reg(struct drm_gem_object *obj, bool
> write);
> static void i915_gem_clear_fence_reg(struct drm_gem_object *obj);
> static int i915_gem_evict_something(struct drm_device *dev);
> @@ -497,6 +498,13 @@ i915_gem_sw_finish_ioctl(struct drm_device *dev, void
> *data,
> i915_gem_object_flush_cpu_write_domain(obj);
>
> drm_gem_object_unreference(obj);
> +
> + /* If it's been GTT mapped, unref it again... */
> + if (obj_priv->mmap_offset) {
This test occurs after the potential free above.
> + i915_gem_free_mmap_offset(obj);
> + drm_gem_object_unreference(obj);
> + }
> +
> mutex_unlock(&dev->struct_mutex);
> return ret;
> }
> @@ -607,8 +615,6 @@ int i915_gem_fault(struct vm_area_struct *vma, struct
> vm_fault *vmf)
> case -EAGAIN:
> return VM_FAULT_OOM;
> case -EFAULT:
> - case -EBUSY:
> - DRM_ERROR("can't insert pfn?? fault or busy...\n");
> return VM_FAULT_SIGBUS;
> default:
> return VM_FAULT_NOPAGE;
> @@ -684,6 +690,32 @@ out_free_list:
> return ret;
> }
>
> +static void
> +i915_gem_free_mmap_offset(struct drm_gem_object *obj)
> +{
> + struct drm_device *dev = obj->dev;
> + struct drm_i915_gem_object *obj_priv = obj->driver_private;
> + struct drm_gem_mm *mm = dev->mm_private;
> + struct drm_map_list *list;
> + struct drm_map *map;
> +
> + list = &obj->map_list;
> + drm_ht_remove_item(&mm->offset_hash, &list->hash);
> +
> + if (list->file_offset_node) {
> + drm_mm_put_block(list->file_offset_node);
> + list->file_offset_node = NULL;
> + }
> +
> + map = list->map;
> + if (map) {
> + drm_free(map, sizeof(*map), DRM_MEM_DRIVER);
> + list->map = NULL;
> + }
> +
> + obj_priv->mmap_offset = 0;
> +}
> +
> /**
> * i915_gem_get_gtt_alignment - return required GTT alignment for an object
> * @obj: object to check
> @@ -788,7 +820,7 @@ i915_gem_mmap_gtt_ioctl(struct drm_device *dev, void
> *data,
> list_add(&obj_priv->list, &dev_priv->mm.inactive_list);
> }
>
> - drm_gem_object_unreference(obj);
> + /* Leave lookup reference around until unmap time */
> mutex_unlock(&dev->struct_mutex);
>
> return 0;
> @@ -2885,9 +2917,6 @@ int i915_gem_init_object(struct drm_gem_object *obj)
> void i915_gem_free_object(struct drm_gem_object *obj)
Re: [PATCH] drm: Fix lock order reversal between mmap_sem and struct_mutex.
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) while we move a non-trivial amount of data
> (copy_from/to_user()), such as i915_gem_pwrite(). Solve this by moving the
> one thing that needed struct_mutex with mmap_sem held to using a lock to cover
> just those data structures (offset hash and offset manager).
Sadly, this does not eliminate this warning:
lt-cairo-perf/2456 is trying to acquire lock:
(&dev->struct_mutex){--..}, at: [] i915_gem_fault+0x48/0x128
but task is already holding lock:
(&mm->mmap_sem){}, at: [] do_page_fault+0x1a4/0x595
which appears to be due to a page fault whilst copying the user
relocations in i915_gem_object_pin_and_relocate().
-ickle
--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
