On Fri, Mar 23, 2018 at 1:02 PM, Tomasz Figa <[email protected]> wrote: > On Fri, Mar 23, 2018 at 8:52 PM, Robert Foss <[email protected]> > 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 <[email protected]>: >>>> >>>> Hi Chih-Wei, >>>> >>>> On Thu, Feb 22, 2018 at 2:53 PM, Chih-Wei Huang <[email protected]> >>>> wrote: >>>>> >>>>> 2018-02-21 3:03 GMT+08:00 Rob Herring <[email protected]>: >>>>>> >>>>>> >>>>>> 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. Thanks, Stefan _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
