On Friday, February 6, 2009 4:52 pm Chris Wilson wrote:
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.
This one relies on
On Tuesday, February 10, 2009 2:00 pm Eric Anholt wrote:
On Fri, 2009-02-06 at 14:24 -0800, Jesse Barnes wrote:
On Friday, February 6, 2009 1:35 pm Thomas Hellström wrote:
Jesse Barnes wrote:
On Thursday, February 5, 2009 10:37 am Jesse Barnes wrote:
So if we leave the lookup
On Fri, 2009-02-06 at 14:24 -0800, Jesse Barnes wrote:
On Friday, February 6, 2009 1:35 pm Thomas Hellström wrote:
Jesse Barnes wrote:
On Thursday, February 5, 2009 10:37 am Jesse Barnes wrote:
So if we leave the lookup reference around from the GTT mapping ioctl,
that would take care
Le vendredi 06 février 2009 à 14:24 -0800, Jesse Barnes a écrit :
+ map = list-map;
+ if (map) {
+ drm_free(map, sizeof(*map), DRM_MEM_DRIVER);
+ list-map = NULL;
I would have inverted the two last lines (otherwise why wouldn't you
directly
On Thursday, February 5, 2009 10:37 am Jesse Barnes wrote:
So if we leave the lookup reference around from the GTT mapping ioctl, that
would take care of new mappings. And if we added/removed references at VM
open/close time, we should be covered for fork. But is it ok to add a new
unref in
On Friday, February 6, 2009 1:35 pm Thomas Hellström wrote:
Jesse Barnes wrote:
On Thursday, February 5, 2009 10:37 am Jesse Barnes wrote:
So if we leave the lookup reference around from the GTT mapping ioctl,
that would take care of new mappings. And if we added/removed
references at VM
Jesse Barnes wrote:
On Friday, February 6, 2009 1:35 pm Thomas Hellström wrote:
Jesse Barnes wrote:
On Thursday, February 5, 2009 10:37 am Jesse Barnes wrote:
So if we leave the lookup reference around from the GTT mapping ioctl,
that would take care of new mappings. And if
On Friday, February 6, 2009 2:39 pm Thomas Hellström wrote:
Jesse Barnes wrote:
On Friday, February 6, 2009 1:35 pm Thomas Hellström wrote:
Jesse Barnes wrote:
On Thursday, February 5, 2009 10:37 am Jesse Barnes wrote:
So if we leave the lookup reference around from the GTT mapping ioctl,
I tried it, it's not too happy. My only concern is that this now relies
on userspace to correctly call SW_FINISH (and not unmap after mmapping
the GTT_MMAP) or otherwise the object is leaked? Patch comments inline.
On Fri, 2009-02-06 at 14:24 -0800, Jesse Barnes wrote:
This one should cover the
On Wednesday, February 4, 2009 3:42 pm Eric Anholt wrote:
On Wed, 2009-02-04 at 15:02 -0800, Jesse Barnes wrote:
On Wednesday, February 4, 2009 2:32 pm Thomas Hellström wrote:
Jesse,
I have some concerns about the GEM GTT mmap functionality.
Thanks for looking it over again; you
Jesse,
I have some concerns about the GEM GTT mmap functionality.
First, a gem object pointer is copied to map-offset and then to the
vma-vm_private_data without proper reference counting. This pointer is
used in i915_gem_fault() to access the gem object. However if the gem
object is
On Wednesday, February 4, 2009 2:32 pm Thomas Hellström wrote:
Jesse,
I have some concerns about the GEM GTT mmap functionality.
Thanks for looking it over again; you would know since some of this code came
from you in the first place. :)
First, a gem object pointer is copied to map-offset
On Wed, 2009-02-04 at 15:02 -0800, Jesse Barnes wrote:
On Wednesday, February 4, 2009 2:32 pm Thomas Hellström wrote:
Jesse,
I have some concerns about the GEM GTT mmap functionality.
Thanks for looking it over again; you would know since some of this code came
from you in the first
13 matches
Mail list logo
