Rob Herring <r...@kernel.org> writes: > On Wed, Apr 27, 2016 at 5:01 PM, Emil Velikov <emil.l.veli...@gmail.com> > wrote: >> On 27 April 2016 at 19:51, Eric Anholt <e...@anholt.net> wrote: >>> Rob Herring <r...@kernel.org> writes: >>> >>>> On Mon, Apr 25, 2016 at 7:53 PM, Eric Anholt <e...@anholt.net> wrote: >>>>> Rob Herring <r...@kernel.org> writes: >>>>> >>>>>> On Fri, Apr 22, 2016 at 9:08 PM, Rob Herring <r...@kernel.org> wrote: >>>>>>> On Fri, Apr 22, 2016 at 6:32 PM, Emil Velikov >>>>>>> <emil.l.veli...@gmail.com> wrote: >>>>>>>> Hi Rob, >>>>>>>> >>>>>>>> On 22 April 2016 at 16:50, Rob Herring <r...@kernel.org> wrote: >>>>>>>>> This adds map and unmap functions to GBM utilizing the DRIimage >>>>>>>>> extension >>>>>>>>> mapImage/unmapImage functions or existing internal mapping for dumb >>>>>>>>> buffers. >>>>>>>> Ftr that this is quite sensitive and apart from the obvious breakage >>>>>>>> (coming in a second) it will need some testing on a gnome-continuous >>>>>>>> setup (iirc some used to hand out in #xorg-devel) >>>>>>>> >>>>>>>>> Unlike prior attempts, this version provides a region to map and >>>>>>>>> usage flags for the mapping. The operation follows the same semantics >>>>>>>>> as >>>>>>>>> the gallium transfer_map() function. >>>>>>>>> >>>>>>>>> This was tested with GBM based gralloc on Android. >>>>>>>>> >>>>>>>>> This still creates a context, but I've moved it into gbm_create_device >>>>>>>>> rather than in the map function. This should remove any need for >>>>>>>>> reference >>>>>>>>> counting and problems with memory leaks. >>>>>>>>> >>>>>>>>> Signed-off-by: Rob Herring <r...@kernel.org> >>>>>>> >>>>>>> [...] >>>>>>> >>>>>> >>>>>>>>> @@ -1004,6 +1058,10 @@ dri_device_create(int fd) >>>>>>>>> if (ret) >>>>>>>>> goto err_dri; >>>>>>>>> >>>>>>>>> + if (dri->image->base.version >= 12) >>>>>>>>> + dri->context = dri->dri2->createNewContext(dri->screen, NULL, >>>>>>>>> + NULL, NULL); >>>>>>>>> + >>>>>>>> Have you measured how much this costs us (cpu time and/or memory) ? >>>>>>> >>>>>>> No, will do. >>>>>> >>>>>> On Android (x86_64 + virgl), it is 2ms and ~2MB (out of 20). A >>>>>> standalone test with swrast is 4ms and ~4MB. I measured with >>>>>> getrusage(). >>>>> >>>>> Given that existing clients of GBM don't use this API, it's not OK to >>>>> add this cost to all of them. >>>> >>>> Agreed. >>>> >>>>> If you need pthreads to protect the allocation check at map time, >>>> >>>> I do... >>>> >>>>> there's this bit of configure.ac from libdrm so that you don't need to >>>>> force libgbm to pull in real pthreads and its overhead: >>>>> >>>>> PKG_CHECK_MODULES(PTHREADSTUBS, pthread-stubs) >>>>> AC_SUBST(PTHREADSTUBS_CFLAGS) >>>>> AC_SUBST(PTHREADSTUBS_LIBS) >>>> >> Side note: pthread-stubs expands to a single .pc file on GLIBC (Linux >> in general ?) platforms. That's because libc.so already has these >> stubs. >> >>>> GBM requires DRI which already pulls in pthreads, so I don't think >>>> this is needed. Or am I missing something? >>> >>> I'm fine with that, just noting that my libgbm currently doesn't link >>> pthreads, and providing a solution if people didn't want to force >>> linking pthreads for libgbm.so. >> Not only yours - libgbm does not link against pthreads.so. Period. >> The DRI modules on the other hand (amongst others) do. > > Okay, with Emil's patch I have it just using the stub. However, it > seems I don't really need the above configure.ac hunk. Is that only > needed for non-Linux/glibc builds?
Yeah, it's the tool that hides that nastiness of other platforms for us.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
