On Fri, Mar 23, 2018 at 10:15 PM, Stefan Schake <stsch...@gmail.com> wrote: > On Fri, Mar 23, 2018 at 1:02 PM, Tomasz Figa <tf...@chromium.org> wrote: >> On Fri, Mar 23, 2018 at 8:52 PM, Robert Foss <robert.f...@collabora.com> >> wrote: >>> Hey Chih-Wei, >>> >>> >>> On 03/23/2018 03:43 AM, Chih-Wei Huang wrote: >>>> >>>> 2018-03-22 16:23 GMT+08:00 Tomasz Figa <tf...@chromium.org>: >>>>> >>>>> Hi Chih-Wei, >>>>> >>>>> On Thu, Feb 22, 2018 at 2:53 PM, Chih-Wei Huang <cwhu...@linux.org.tw> >>>>> wrote: >>>>>> >>>>>> 2018-02-21 3:03 GMT+08:00 Rob Herring <r...@kernel.org>: >>>>>>> >>>>>>> >>>>>>> Perhaps worth revisiting. Given we've failed to progress at all since >>>>>>> then may change opinions some. We already have to handle multiple >>>>>>> opens share the same pipe_screen, so I don't think reusing the fd buys >>>>>>> us anything. >>>>>>> >>>>>>> Maybe we're close to the point of removing the flink name support too. >>>>>>> The android-x86 folks have been working to get dma-bufs working. >>>>>>> Chih-Wei, any comments on this? >>>>>> >>>>>> >>>>>> Ah! Sorry. I didn't catch or understand the details. >>>>>> Did you mean the attempts to use drm_hwcomposer >>>>>> in android-x86? >>>>>> My understanding so far is most x86 GPUs won't work >>>>>> except some very limited models. >>>>>> It's due to kernel driver issues which may never be solved. >>>>>> So we can't drop the flink name support. >>>>>> Please correct me if I am wrong. >>>>> >>>>> >>>>> Could you elaborate a bit more on those GPUs that won't work and >>>>> corresponding driver issues? We're running cros_gralloc on Intel and >>>>> AMD GPUs, with DMA-buf and render-node only setup and we haven't seen >>>>> any problems. >>>> >>>> >>>> Hi Tomasz, >>>> I remember (in our previous discussion) you said >>>> CrOS uses your own hwcomposer (proprietary?) so >>>> the story may be different. >>>> >>>> What we have tried is gbm_gralloc + drm_hwcomposer >>>> and I reported the issues here: >>>> >>>> https://lists.freedesktop.org/archives/dri-devel/2017-September/153580.html >>> >>> >>> I took the liberty of moving you nouveau issue into the drm_hwc gitlab >>> bugtracker. >>> >>> https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/issues/1 >> >> Hmm, reading further in that thread, that seemed to be related to >> missing nouveau.atomic=1 in kernel command line: >> https://lists.freedesktop.org/archives/dri-devel/2017-September/153681.html >> >> It went further, but didn't work very well. I suspect that could have >> been related to DRM_GRALLOC_GET_FD being used, which makes the mess >> from the system due to gralloc and Mesa stepping on each other's GEM >> handles (which aren't reference counted by design and importing a >> buffer several time will always return the same handle). > > I think mixing in drm_hwcomposer here would be trying to do too much at once. > It has a lot of requirements (atomic driver, fence fds, alpha/rotation props) > and no fallback path to speak of. Coming from drm_gralloc where I think in > practice all composition is punted to the hwui GL compositor and DRM is > only around for putting the final framebuffer on a display, it's asking a lot > of some of the (legacy) hardware used for Android-x86.
Do we have any feasible alternative? Chih-Wei pointed me to the drm_gralloc used on android-x86 and it seems to seriously pre-date any DMA-buf support. Everything there is done with the assumption that GEM names are used and adding DMA-buf would require a significant rework of all the code. That leaves us with gbm_gralloc (or possibly Chromium minigbm, used by Android-IA too), which doesn't implement the legacy FB management, so some hwcomposer would be needed. Best regards, Tomasz _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev