On Fri, Feb 9, 2018 at 3:58 AM, Tomasz Figa <tf...@chromium.org> wrote: > On Fri, Feb 2, 2018 at 11:51 PM, Tomasz Figa <tf...@chromium.org> wrote: >> On Fri, Feb 2, 2018 at 11:00 PM, Rob Herring <r...@kernel.org> wrote: >>> On Fri, Feb 2, 2018 at 2:01 AM, Tomasz Figa <tf...@chromium.org> wrote: >>>> Hi Rob, >>>> >>>> On Tue, Jan 30, 2018 at 9:36 PM, Robert Foss <robert.f...@collabora.com> >>>> wrote: >>>>>>>>>> uint32_t (*get_fd)(buffer_handle_t handle, uint32_t plane); >>>>>>>>>> uint64_t (*get_modifier)(buffer_handle_t handle, uint32_t >>>>>>>>>> plane); >>>>>>>>>> uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t >>>>>>>>>> plane); >>>>>>>>>> uint32_t (*get_stride)(buffer_handle_t handle, uint32_t plane); >>>>>>>>>> ... >>>>>>>>>> } gralloc_funcs_t; >>>>>> >>>>>> >>>>>> These ones? > >>>>>> Yeah, if we could retrieve such function pointer struct using perform >>>>>> or any equivalent (like the implementation-specific methods in >>>>>> gralloc1, but not sure if that's going to be used in practice >>>>>> anywhere), it could work for us. >>>>> >>>>> >>>>> So this is where you and Rob Herring lose me, I don't think I understand >>>>> quite how the gralloc1 call would be used, and how it would tie into this >>>>> handle struct. I think I could do with some guidance on this. >>>> >>>> This would be very similar to gralloc0 perform call. gralloc1 >>>> implementations need to provide getFunction() callback [1], which >>>> returns a pointer to given function. The list of standard functions is >>>> defined in the gralloc1.h header [2], but we could take some random >>>> big number and use it for our function that fills in provided >>>> gralloc_funcs_t struct with necessary pointers. >>>> >>>> [1] >>>> https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h#300 >>>> [2] >>>> https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h#134 >>> >>> This is a deadend because it won't work with a HIDL based >>> implementation (aka gralloc 2.0). You can't set function pointers (or >>> any pointers) because gralloc runs in a different process. Yes, >>> currently gralloc is a pass-thru HAL, but AIUI that will go away. >> >> Part of it. I can't see IMapper being implemented by a separate >> process. You can't map a buffer into one process from another process. >> >> But anyway, it's a good point, thanks, I almost forgot about its >> existence. I'll do further investigation. > > Okay, so IMapper indeed breaks the approach I suggested. I'm not sure > at the moment what we could do about it. (The idea of a dynamic > library of a pre-defined name, exporting functions we specify, might > still work, though.) > > Note that the DRM_GRALLOC_GET_FD used currently by Mesa will also be > impossible to implement with IAllocator/IMapper. (Although I still > think Mesa and Gralloc are free to have separate logic for choosing > the DRM device to use.)
I think the need for GET_FD goes away when the render node is used. We may still need the card node for s/w rendering (if I can ever get that working) though. Of course, if we use the vgem approach like CrOS then we wouldn't. Rob _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
