On 03/17/2017 05:20 AM, Jan Vesely wrote: > On Thu, 2017-03-16 at 18:07 -0700, Francisco Jerez wrote: >> Jan Vesely <jan.ves...@rutgers.edu> writes: >> >>> On Thu, 2017-03-16 at 17:22 -0700, Francisco Jerez wrote: >>>> Jan Vesely <jan.ves...@rutgers.edu> writes: >>>> >>>>> On Thu, 2017-03-16 at 15:24 -0700, Francisco Jerez wrote: >>>>>> Jan Vesely <jan.ves...@rutgers.edu> writes: >>>>>> >>>>>>> v2: buffers are created with one reference. >>>>>>> v3: add pipe_resource reference to mapping object >>>>>>> >>>>>> >>>>>> Mapping objects are supposed to be short-lived, they're logically part >>>>>> of the parent resource object so they shouldn't ever out-live it. What >>>>>> is this useful for? >>>>> >>>>> currently they can outlive the underlying pipe_resource. pipe_resource >>>>> is destroyed in root_resource destructor, while the list of mappings is >>>>> destroyed after resource destructor. >>>> >>>> Right. I guess the problem is that the pipe_transfer object associated >>>> to the clover::mapping object holds a pointer to the backing >>>> pipe_resource object but it fails to increment its reference count? I >>>> guess that's the reason why v2 didn't help? >>> >>> yes, though the pointer is hidden somewhere. I thought pxfer->resource >>> might be it, but it's not, and digging deeper into the structure didn't >>> sound like a good idea to me. >>> >> >> What is pxfer->resource about in that case? > > that's a good question, so I did a bit of digging. for EG global > buffers are shadowed in global buffer memory pool, so mapping uses > memory pool's pipe_resource. I'm still not 100% sure where exactly > unmapping the global pool accesses the original buffer's pipe_resource, > but I don't think it matters that much. It's not required for pxfer- >> resource to be equal to resource->pipe. we need to guarantee that > resource->pipe outlives all mappings. > either explicitly, or by grabbing reference. > > Jan >
Jan's v3 solves the problem, as does my version. Francisco, do you have a particular preference how should we proceed? Regards, Vedran -- Vedran Miletić vedran.miletic.net _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
