On 03/23/2018 03:20 PM, Tomasz Figa wrote:
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.
One possibility for android-x86 project would be to have a separate
lunch target (and libraries) for the old machines. Those ones unlikely
support OpenGL ES 3.1?), hardware planes, Vulkan or other modern Android
requirements anyway. These machines could run with old (and stable)
Mesa, drm_gralloc and maybe the old hwcomposer from Intel that does hwc
1.0/1.1, there were even patches to use planes there via drmModeSetPlane
in video usecases IIRC.
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
// Tapani
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
