[Bug 17397] Google earth slow if atmosphere on
http://bugs.freedesktop.org/show_bug.cgi?id=17397 Gordon Jin <[EMAIL PROTECTED]> changed: What|Removed |Added Keywords|NEEDINFO| -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
libdrm CVS build error for some days
kernel openSUSE 10.3 2.6.22.19-0.1-default /opt/drm> ./configure --prefix=/usr [-] checking whether the g++ linker (/usr/i586-suse-linux/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking dependency style of gcc... (cached) gcc3 checking for ANSI C header files... (cached) yes checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... 64 ./configure: line 20465: syntax error near unexpected token `PTHREADSTUBS,' ./configure: line 20465: `PKG_CHECK_MODULES(PTHREADSTUBS, pthread-stubs)' Thanks, Dieter - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libdrm CVS build error for some days
On Tue, Oct 28, 2008 at 8:44 AM, Dieter Nützel <[EMAIL PROTECTED]> wrote: > kernel openSUSE 10.3 2.6.22.19-0.1-default > > /opt/drm> ./configure --prefix=/usr > > [-] > > checking whether the g++ linker (/usr/i586-suse-linux/bin/ld) supports shared > libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > appending configuration tag "F77" to libtool > checking for gcc... (cached) gcc > checking whether we are using the GNU C compiler... (cached) yes > checking whether gcc accepts -g... (cached) yes > checking for gcc option to accept ISO C89... (cached) none needed > checking dependency style of gcc... (cached) gcc3 > checking for ANSI C header files... (cached) yes > checking for special C compiler options needed for large files... no > checking for _FILE_OFFSET_BITS value needed for large files... 64 > ./configure: line 20465: syntax error near unexpected token `PTHREADSTUBS,' > ./configure: line 20465: `PKG_CHECK_MODULES(PTHREADSTUBS, pthread-stubs)' Do you have pkg-config installed? Can aclocal find pkg.m4 (should be in /usr/share/aclocal)? -- Dan - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libdrm CVS build error for some days
Am Dienstag, 28. Oktober 2008 schrieb Dan Nicholson: > On Tue, Oct 28, 2008 at 8:44 AM, Dieter Nützel <[EMAIL PROTECTED]> wrote: > > kernel openSUSE 10.3 2.6.22.19-0.1-default > > > > /opt/drm> ./configure --prefix=/usr > > > > [-] > > > > checking whether the g++ linker (/usr/i586-suse-linux/bin/ld) supports > > shared libraries... yes > > checking dynamic linker characteristics... GNU/Linux ld.so > > checking how to hardcode library paths into programs... immediate > > appending configuration tag "F77" to libtool > > checking for gcc... (cached) gcc > > checking whether we are using the GNU C compiler... (cached) yes > > checking whether gcc accepts -g... (cached) yes > > checking for gcc option to accept ISO C89... (cached) none needed > > checking dependency style of gcc... (cached) gcc3 > > checking for ANSI C header files... (cached) yes > > checking for special C compiler options needed for large files... no > > checking for _FILE_OFFSET_BITS value needed for large files... 64 > > ./configure: line 20465: syntax error near unexpected token > > `PTHREADSTUBS,' ./configure: line 20465: `PKG_CHECK_MODULES(PTHREADSTUBS, > > pthread-stubs)' > > Do you have pkg-config installed? Can aclocal find pkg.m4 (should be > in /usr/share/aclocal)? All there: /home/nuetzel> l /usr/share/aclocal/pkg.m4 -rw-r--r-- 1 root root 5232 21. Sep 2007 /usr/share/aclocal/pkg.m4 diff with older libdrm said that this token is _new_: PTHREADSTUBS -Dieter - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libdrm CVS build error for some days
On Tue, Oct 28, 2008 at 9:07 AM, Dieter Nützel <[EMAIL PROTECTED]> wrote: > Am Dienstag, 28. Oktober 2008 schrieb Dan Nicholson: >> On Tue, Oct 28, 2008 at 8:44 AM, Dieter Nützel <[EMAIL PROTECTED]> wrote: >> > kernel openSUSE 10.3 2.6.22.19-0.1-default >> > >> > /opt/drm> ./configure --prefix=/usr >> > >> > [-] >> > >> > checking whether the g++ linker (/usr/i586-suse-linux/bin/ld) supports >> > shared libraries... yes >> > checking dynamic linker characteristics... GNU/Linux ld.so >> > checking how to hardcode library paths into programs... immediate >> > appending configuration tag "F77" to libtool >> > checking for gcc... (cached) gcc >> > checking whether we are using the GNU C compiler... (cached) yes >> > checking whether gcc accepts -g... (cached) yes >> > checking for gcc option to accept ISO C89... (cached) none needed >> > checking dependency style of gcc... (cached) gcc3 >> > checking for ANSI C header files... (cached) yes >> > checking for special C compiler options needed for large files... no >> > checking for _FILE_OFFSET_BITS value needed for large files... 64 >> > ./configure: line 20465: syntax error near unexpected token >> > `PTHREADSTUBS,' ./configure: line 20465: `PKG_CHECK_MODULES(PTHREADSTUBS, >> > pthread-stubs)' >> >> Do you have pkg-config installed? Can aclocal find pkg.m4 (should be >> in /usr/share/aclocal)? > > All there: > > /home/nuetzel> l /usr/share/aclocal/pkg.m4 > -rw-r--r-- 1 root root 5232 21. Sep 2007 /usr/share/aclocal/pkg.m4 > > diff with older libdrm said that this token is _new_: > > PTHREADSTUBS Did you regenerate configure? The PKG_CHECK_MODULES macro is not being substituted for you. -- Dan - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libdrm CVS build error for some days
Am Dienstag, 28. Oktober 2008 schrieb Dan Nicholson: > On Tue, Oct 28, 2008 at 9:07 AM, Dieter Nützel <[EMAIL PROTECTED]> wrote: > > Am Dienstag, 28. Oktober 2008 schrieb Dan Nicholson: > >> On Tue, Oct 28, 2008 at 8:44 AM, Dieter Nützel <[EMAIL PROTECTED]> wrote: > >> > kernel openSUSE 10.3 2.6.22.19-0.1-default > >> > > >> > /opt/drm> ./configure --prefix=/usr > >> > > >> > [-] > >> > > >> > checking whether the g++ linker (/usr/i586-suse-linux/bin/ld) supports > >> > shared libraries... yes > >> > checking dynamic linker characteristics... GNU/Linux ld.so > >> > checking how to hardcode library paths into programs... immediate > >> > appending configuration tag "F77" to libtool > >> > checking for gcc... (cached) gcc > >> > checking whether we are using the GNU C compiler... (cached) yes > >> > checking whether gcc accepts -g... (cached) yes > >> > checking for gcc option to accept ISO C89... (cached) none needed > >> > checking dependency style of gcc... (cached) gcc3 > >> > checking for ANSI C header files... (cached) yes > >> > checking for special C compiler options needed for large files... no > >> > checking for _FILE_OFFSET_BITS value needed for large files... 64 > >> > ./configure: line 20465: syntax error near unexpected token > >> > `PTHREADSTUBS,' ./configure: line 20465: > >> > `PKG_CHECK_MODULES(PTHREADSTUBS, pthread-stubs)' > >> > >> Do you have pkg-config installed? Can aclocal find pkg.m4 (should be > >> in /usr/share/aclocal)? > > > > All there: > > > > /home/nuetzel> l /usr/share/aclocal/pkg.m4 > > -rw-r--r-- 1 root root 5232 21. Sep 2007 /usr/share/aclocal/pkg.m4 > > > > diff with older libdrm said that this token is _new_: > > > > PTHREADSTUBS > > Did you regenerate configure? The PKG_CHECK_MODULES macro is not being > substituted for you. Uh, argh,... ...a man get OLD! /opt/drm> ./autogen.sh did it. Thanks, Dieter - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] non-crashy GTT mapping patch
On Monday, October 27, 2008 11:27 am Jesse Barnes wrote:
> On Friday, October 24, 2008 2:57 pm Jesse Barnes wrote:
> > Ok this one doesn't crash and doesn't leave the flushing list full at
> > leavevt time, so I think it's ready for some actual review.
> >
> > I'm using the patch I posted to intel-gfx@ to do tiled EXA pixmaps, but I
> > think my approach of faulting in fence registers may not be the best one
> > (though I haven't tried making the fence register allocator use LRU yet);
> > it
> > seems like we may want a big contiguous chunk of GTT space where pixmaps
> > sit so we can re-use a single fence register to cover the needs of most
> > pixmaps. Suggestions appreciated.
> >
> > This patch should be pretty safe to push upstream I think since the new
> > code won't be used unless applications actually call the GTT mapping
> > ioctl.
>
> And with untested 915/830 fence register support.
Merged up to drm-next from this morning.
Jesse
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index bde64b8..9916366 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -262,6 +262,9 @@ static int drm_addmap_core(struct drm_device * dev,
unsigned int offset,
DRM_DEBUG("AGP offset = 0x%08lx, size = 0x%08lx\n",
map->offset, map->size);
break;
+ case _DRM_GEM:
+ DRM_ERROR("tried to rmmap GEM object\n");
+ break;
}
case _DRM_SCATTER_GATHER:
if (!dev->sg) {
@@ -419,6 +422,9 @@ int drm_rmmap_locked(struct drm_device *dev,
drm_local_map_t *map)
dmah.size = map->size;
__drm_pci_free(dev, &dmah);
break;
+ case _DRM_GEM:
+ DRM_ERROR("tried to rmmap GEM object\n");
+ break;
}
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 96f416a..aad8d76 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -236,6 +236,7 @@ int drm_lastclose(struct drm_device * dev)
dev->lock.file_priv = NULL;
wake_up_interruptible(&dev->lock.lock_queue);
}
+ dev->dev_mapping = NULL;
mutex_unlock(&dev->struct_mutex);
DRM_DEBUG("lastclose completed\n");
@@ -290,6 +291,8 @@ EXPORT_SYMBOL(drm_init);
*/
static void drm_cleanup(struct drm_device * dev)
{
+ struct drm_driver *driver = dev->driver;
+
DRM_DEBUG("\n");
if (!dev) {
@@ -319,6 +322,9 @@ static void drm_cleanup(struct drm_device * dev)
drm_ht_remove(&dev->map_hash);
drm_ctxbitmap_cleanup(dev);
+ if (driver->driver_features & DRIVER_GEM)
+ drm_gem_destroy(dev);
+
drm_put_minor(&dev->primary);
if (drm_put_dev(dev))
DRM_ERROR("Cannot unload module\n");
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 0d46627..0958cf6 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -147,11 +147,21 @@ int drm_open(struct inode *inode, struct file *filp)
spin_lock(&dev->count_lock);
if (!dev->open_count++) {
spin_unlock(&dev->count_lock);
- return drm_setup(dev);
+ retcode = drm_setup(dev);
+ goto out;
}
spin_unlock(&dev->count_lock);
}
+out:
+ mutex_lock(&dev->struct_mutex);
+ if (dev->dev_mapping == NULL)
+ dev->dev_mapping = inode->i_mapping;
+ else if (dev->dev_mapping != inode->i_mapping)
+ WARN(1, "dev->dev_mapping not inode mapping (%p expected %p)\n",
+dev->dev_mapping, inode->i_mapping);
+ mutex_unlock(&dev->struct_mutex);
+
return retcode;
}
EXPORT_SYMBOL(drm_open);
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index ccd1afd..431dc3c 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -64,6 +64,13 @@
* up at a later date, and as our interface with shmfs for memory allocation.
*/
+/*
+ * We make up offsets for buffer objects so we can recognize them at
+ * mmap time.
+ */
+#define DRM_FILE_PAGE_OFFSET_START ((0xUL >> PAGE_SHIFT) + 1)
+#define DRM_FILE_PAGE_OFFSET_SIZE ((0xUL >> PAGE_SHIFT) * 16)
+
/**
* Initialize the GEM device fields
*/
@@ -71,6 +78,8 @@
int
drm_gem_init(struct drm_device *dev)
{
+ struct drm_gem_mm *mm;
+
spin_lock_init(&dev->object_name_lock);
idr_init(&dev->object_name_idr);
atomic_set(&dev->object_count, 0);
@@ -79,9 +88,41 @@ drm_gem_init(struct drm_device *dev)
atomic_set(&dev->pin_memory, 0);
atomic_set(&dev->gtt_count, 0);
atomic_set(&dev->gtt_memory, 0);
+
+ mm = drm_calloc(1, sizeof(struct drm_gem_mm), DRM_MEM_MM);
+ if (!mm) {
+ DRM_ERROR("out of memory\
Re: [PATCH] non-crashy GTT mapping patch
On Tue, 2008-10-28 at 14:37 -0700, Jesse Barnes wrote:
> On Monday, October 27, 2008 11:27 am Jesse Barnes wrote:
> > On Friday, October 24, 2008 2:57 pm Jesse Barnes wrote:
> > > Ok this one doesn't crash and doesn't leave the flushing list full at
> > > leavevt time, so I think it's ready for some actual review.
> > >
> > > I'm using the patch I posted to intel-gfx@ to do tiled EXA pixmaps, but I
> > > think my approach of faulting in fence registers may not be the best one
> > > (though I haven't tried making the fence register allocator use LRU yet);
> > > it
> > > seems like we may want a big contiguous chunk of GTT space where pixmaps
> > > sit so we can re-use a single fence register to cover the needs of most
> > > pixmaps. Suggestions appreciated.
> > >
> > > This patch should be pretty safe to push upstream I think since the new
> > > code won't be used unless applications actually call the GTT mapping
> > > ioctl.
> >
> > And with untested 915/830 fence register support.
>
> Merged up to drm-next from this morning.
>
> Jesse
Comment here noting what this function's about (handling gtt mmap setup)
might be nice, as just naming-wise it sounds similar to the gem mmap
ioctl which doesn't hit this.
> +int
> +drm_gem_mmap(struct file *filp, struct vm_area_struct *vma)
> +{
> + struct drm_file *priv = filp->private_data;
> + struct drm_device *dev = priv->minor->dev;
> + struct drm_gem_mm *mm = dev->mm_private;
> + struct drm_map *map = NULL;
> + struct drm_gem_object *obj;
> + struct drm_hash_item *hash;
> + unsigned long prot;
> + int ret = 0;
> +
> + mutex_lock(&dev->struct_mutex);
> +
> + if (drm_ht_find_item(&mm->offset_hash, vma->vm_pgoff, &hash)) {
> + mutex_unlock(&dev->struct_mutex);
> + return drm_mmap(filp, vma);
> + }
> +
> + map = drm_hash_entry(hash, struct drm_map_list, hash)->map;
> + if (!map ||
> + ((map->flags & _DRM_RESTRICTED) && !capable(CAP_SYS_ADMIN))) {
> + ret = -EPERM;
> + goto out_unlock;
> + }
> +
> + /* Check for valid size. */
> + if (map->size < vma->vm_end - vma->vm_start) {
> + ret = -EINVAL;
> + goto out_unlock;
> + }
> +
> + obj = map->handle;
> + if (!obj->dev->driver->gem_vm_ops) {
> + ret = -EINVAL;
> + goto out_unlock;
> + }
> +
> + vma->vm_flags |= VM_RESERVED | VM_IO | VM_PFNMAP | VM_DONTEXPAND;
> + vma->vm_ops = obj->dev->driver->gem_vm_ops;
> + vma->vm_private_data = map->handle;
> + /* FIXME: use pgprot_writecombine when available */
> + prot = pgprot_val(vma->vm_page_prot);
> + prot |= _PAGE_CACHE_WC;
> + vma->vm_page_prot = __pgprot(prot);
> +
> + vma->vm_file = filp;/* Needed for drm_vm_open() */
> + drm_vm_open_locked(vma);
> +
> +out_unlock:
> + mutex_unlock(&dev->struct_mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_gem_mmap);
> diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
> index 3316067..af539f7 100644
> --- a/drivers/gpu/drm/drm_hashtab.c
> +++ b/drivers/gpu/drm/drm_hashtab.c
> + /**
> + * Required alignment for the object
> + */
> + uint32_t gtt_alignment;
We've got another gtt alignment value that comes in through
i915_gem_pin_ioctl. We probably want to just calculate this one (which
is about getting things aligned for tiling fence regs) in the kernel
instad of being an ioctl argument from the gtt mmap ioctl, and be sure
in bind_to_gtt to take this value if it's larger than what pin passed
us.
> +/**
> + * i915_gem_fault - fault a page into the GTT
> + * vma: VMA in question
> + * vmf: fault info
> + *
> + * The fault handler is set up by drm_gem_mmap() when a object is GTT mapped
> + * from userspace. The fault handler takes care of binding the object to
> + * the GTT (if needed), allocating and programming a fence register (again,
> + * only if needed based on whether the old reg is still valid or the object
> + * is tiled) and inserting a new PTE into the faulting process.
> + *
> + * Note that the faulting process may involve evicting existing objects
> + * from the GTT and/or fence registers to make room. So performance may
> + * suffer if the GTT working set is large or there are few fence registers
> + * left.
> + */
> +int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> +{
> + struct drm_gem_object *obj = vma->vm_private_data;
> + struct drm_device *dev = obj->dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct drm_i915_gem_object *obj_priv = obj->driver_private;
> + pgoff_t page_offset;
> + unsigned long pfn;
> + int ret = 0;
> +
> + /* We don't use vmf->pgoff since that has the fake offset */
> + page_offset = ((unsigned long)vmf->virtual_address - vma->vm_start) >>
> + PAGE_SHIFT;
> +
> + /* Now bind it into the GTT if needed */
> + mutex_lock(&dev-
Re: [PATCH] non-crashy GTT mapping patch
On Tuesday, October 28, 2008 4:55 pm Eric Anholt wrote:
> On Tue, 2008-10-28 at 14:37 -0700, Jesse Barnes wrote:
> > On Monday, October 27, 2008 11:27 am Jesse Barnes wrote:
> > > On Friday, October 24, 2008 2:57 pm Jesse Barnes wrote:
> > > > Ok this one doesn't crash and doesn't leave the flushing list full at
> > > > leavevt time, so I think it's ready for some actual review.
> > > >
> > > > I'm using the patch I posted to intel-gfx@ to do tiled EXA pixmaps,
> > > > but I think my approach of faulting in fence registers may not be the
> > > > best one (though I haven't tried making the fence register allocator
> > > > use LRU yet); it
> > > > seems like we may want a big contiguous chunk of GTT space where
> > > > pixmaps sit so we can re-use a single fence register to cover the
> > > > needs of most pixmaps. Suggestions appreciated.
> > > >
> > > > This patch should be pretty safe to push upstream I think since the
> > > > new code won't be used unless applications actually call the GTT
> > > > mapping ioctl.
> > >
> > > And with untested 915/830 fence register support.
> >
> > Merged up to drm-next from this morning.
> >
> > Jesse
>
> Comment here noting what this function's about (handling gtt mmap setup)
> might be nice, as just naming-wise it sounds similar to the gem mmap
> ioctl which doesn't hit this.
>
> > +int
> > +drm_gem_mmap(struct file *filp, struct vm_area_struct *vma)
Oh yeah, should have thought of that. Will document.
> > + /**
> > +* Required alignment for the object
> > +*/
> > + uint32_t gtt_alignment;
>
> We've got another gtt alignment value that comes in through
> i915_gem_pin_ioctl. We probably want to just calculate this one (which
> is about getting things aligned for tiling fence regs) in the kernel
> instad of being an ioctl argument from the gtt mmap ioctl, and be sure
> in bind_to_gtt to take this value if it's larger than what pin passed
> us.
Yeah now that you mention it, that would be much better. I think we can
calculate it correctly in every case for the various tiling formats and chip
types, so we shouldn't need to pass it in.
> > + /* Need a new fence register? */
> > + if (obj_priv->fence_reg == I915_FENCE_REG_NONE &&
> > + obj_priv->tiling_mode != I915_TILING_NONE)
> > + i915_gem_object_get_fence_reg(obj);
>
> I like that this is here as opposed to always at object bind time.
> However, we need to make sure we get a fence register covering X-tiled
> stuff at exec time on pre-965, as it's relied on for 2D rendering (since
> they didn't give us bits in the 2D instructions to specify it. sigh.)
See below.
> > +int
> > +i915_gem_mmap_gtt_ioctl(struct drm_device *dev, void *data,
> > + struct drm_file *file_priv)
> > +{
> > + struct drm_i915_gem_mmap_gtt *args = data;
> > + struct drm_i915_private *dev_priv = dev->dev_private;
> > + struct drm_gem_object *obj;
> > + struct drm_i915_gem_object *obj_priv;
> > + int ret;
> > +
> > + if (!(dev->driver->driver_features & DRIVER_GEM))
> > + return -ENODEV;
> > +
> > + mutex_lock(&dev->struct_mutex);
> > + obj = drm_gem_object_lookup(dev, file_priv, args->handle);
> > + if (obj == NULL) {
> > + drm_gem_object_unreference(obj);
> > + mutex_unlock(&dev->struct_mutex);
> > + return -EBADF;
> > + }
>
> You can call object_lookup without the struct_mutex held. It's protected
> by the table_lock spinlock. Also, unref on obj == NULL?
Oops. :) I'll fix that up.
>
> > @@ -656,10 +787,6 @@ i915_gem_retire_request(struct drm_device *dev,
> > */
> > if (obj_priv->last_rendering_seqno != request->seqno)
> > return;
> > -#if WATCH_LRU
> > - DRM_INFO("%s: retire %d moves to inactive list %p\n",
> > -__func__, request->seqno, obj);
> > -#endif
> >
> > if (obj->write_domain != 0) {
> > list_move_tail(&obj_priv->list,
> > @@ -788,7 +915,7 @@ i915_wait_request(struct drm_device *dev, uint32_t
> > seqno) * buffer to have made it to the inactive list, and we would need *
> > a separate wait queue to handle that.
> > */
> > - if (ret == 0)
> > + if (ret == 0 || ret == -ERESTARTSYS)
> > i915_gem_retire_requests(dev);
> >
> > return ret;
>
> Not sure what these two hunks are doing in this patch.
Just leftovers from my debugging of the flushing list stuff I saw, I can kill
them (unless you think the second chunk is a valid fix; seems to be).
> > + if (obj_priv->fence_reg != I915_FENCE_REG_NONE) {
> > + if (IS_I965G(dev)) {
> > + I915_WRITE64(FENCE_REG_965_0 +
> > +(obj_priv->fence_reg * 8), 0);
> > + } else {
> > + I915_WRITE(FENCE_REG_830_0 +
> > + (obj_priv->fence_reg * 4), 0);
> > + }
> > + dev_priv->fence_regs[obj_priv->fence_reg].obj = NULL;
> > +
[Bug 12092] [OGL] Get incorrect texture image if texture' s internalformat is COMPRESSED_RGB_FXT1_3DFX
http://bugs.freedesktop.org/show_bug.cgi?id=12092 Gordon Jin <[EMAIL PROTECTED]> changed: What|Removed |Added Summary|Get incorrect texture image |[OGL] Get incorrect texture |if texture's internalformat |image if texture's |is COMPRESSED_RGB_FXT1_3DFX |internalformat is ||COMPRESSED_RGB_FXT1_3DFX -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
