Vedran Miletić <ved...@miletic.net> writes: > 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? >
I'm okay either way -- Though I'll send some codestyle-related suggestions to Jan's patch in a minute. > Regards, > Vedran > > -- > Vedran Miletić > vedran.miletic.net
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
