This patchset is an inital RFC I wanted to send out to get some
early review and feedback.
I've been working to enable the drm_hwcomposer for HiKey and
HiKey960 boards in AOSP, and this patchset contains the required
changes to the drm_hwcomposer code to get things working.
I'm really quite naive when it comes to graphics, and I'm sure I
don't fully understand the drm_hwcomposer code, so forgive me if
I've done anything terribly stupid here.
There are a few terrible hacks involved, which I'd …
[View More]really love
to get any guidance on how things should be properly done here.
The first is I'm using Rob's patch to force use of single plane,
without which I don't get anything on the screen.
The second is that after getting the drm_hwcomposer running, I
was seeing tons of tearing, which was exactly the behavior I'm
making this effort to avoid. So I have another hack patch that
removes some checks that fail which keep us from doing fence
handling properly. Again, any tips for what deeper issues need
to be addressed would be helpful!
Finally, the third hack isn't in this patchset, but in the
kernel, where with the drm_hwcomposer, on initialization, we
would hit the case where it was trying to enable vsync while the
crtc is off. So I worked around that here:
https://git.linaro.org/people/john.stultz/android-dev.git/commit/?h=dev/hik…
For that last issue, I'm not sure if this is due to some quirk
w/ the drm_hwcomposer initialization, or some other quirk of the
kirin drm driver, but in development of this, I've also worked
with an older drm based hwc implementations which didn't trigger
this issue.
Anyway, outside of those hacks I'm sure there can be further
improvement as well, so I wanted to get it out for some initial
review.
If anyone wants to try the code out on either a HiKey or
HiKey960, you will need this patchset on top of the
freedesktop/master branch of drm_hwcomposer. You'll also need
the freedesktop/master branch of libdrm. You'll need the
following patches to the device/linaro/hikey project:
https://github.com/johnstultz-work/android_device_linaro_hikey/commits/drm_…
And you'll need to replace the kernel Image-dtb with one built
from the following tree:
https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/hikey-…
Any thoughts or feedback will be very much appreciated!
Many thanks to Rob Herring and Matt Szczesiak for help to get
this working so far!
Thanks so much for your time!
-john
Cc: Marissa Wall <marissaw(a)google.com>
Cc: Sean Paul <seanpaul(a)google.com>
Cc: Dmitry Shmidt <dimitrysh(a)google.com>
Cc: Robert Foss <robert.foss(a)collabora.com>
Cc: Matt Szczesiak <matt.szczesiak(a)arm.com>
Cc: Liviu Dudau <Liviu.Dudau(a)arm.com>
Cc: David Hanna <david.hanna11(a)gmail.com>
Cc: Rob Herring <rob.herring(a)linaro.org>
John Stultz (3):
drm_hwcomposer: glworker: Add build time options for certain shader
feature names
drm_hwcomposer: Add platformhisi buffer importer for hikey and
hikey960
drm_hwcomposer: HACK: Fix tearing on hikey/hikey960
Rob Herring (2):
drm_hwcomposer: provide a common gralloc handle definition
drm_hwcomposer: HACK: force single plane
Android.mk | 13 ++-
drmdisplaycompositor.cpp | 9 ++-
drmhwctwo.cpp | 4 +-
glworker.cpp | 15 +++-
gralloc_drm_handle.h | 87 +++++++++++++++++++++
platformhisi.cpp | 200 +++++++++++++++++++++++++++++++++++++++++++++++
platformhisi.h | 50 ++++++++++++
7 files changed, 368 insertions(+), 10 deletions(-)
create mode 100644 gralloc_drm_handle.h
create mode 100644 platformhisi.cpp
create mode 100644 platformhisi.h
--
2.7.4
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=104598
--- Comment #4 from Christoph Haag <haagch(a)frickel.club> ---
Yes it also happens with modesetting. It is a bit different though as the
messages switch to Device or resource busy very quickly
[ 26.386] (WW) modeset(0): flip queue failed: Cannot allocate memory
[ 26.386] (WW) modeset(0): Page flip failed: Cannot allocate memory
[ 26.386] (EE) modeset(0): present flip failed
[ 26.387] (WW) modeset(0): flip queue failed: …
[View More]Cannot allocate memory
[ 26.387] (WW) modeset(0): Page flip failed: Cannot allocate memory
[ 26.387] (EE) modeset(0): failed to set mode: Invalid argument
[ 26.404] (WW) modeset(0): flip queue failed: Device or resource busy
[ 26.404] (WW) modeset(0): Page flip failed: Device or resource busy
[ 26.404] (EE) modeset(0): present flip failed
[ 26.422] (WW) modeset(0): flip queue failed: Device or resource busy
[ 26.422] (WW) modeset(0): Page flip failed: Device or resource busy
also modesetting doesn't recover once vkmark quits, the messages keep spamming
and X keeps being screwed up (feels laggy and some synchronization artifacts).
Disabling kwin compositing then makes X freeze completely. But that may be
unrelated since modesetting seems to have other issues too, like freezing on a
black screen when exiting X or tty switching.
It could indeed be an issue with kwin/radeonsi that just happens to be
triggered by two different vulkan drivers with this one specific application in
mailbox present mode.
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=104598
--- Comment #3 from David Mao <david.mao(a)amd.com> ---
This seems like related with Mesa OGL when doing the compositing present within
the KWIN.
AMDVLK actually did not allow flip in current release.
>From the attached log, the amdgpu ddx driver is being used.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=104598
--- Comment #2 from Michel Dänzer <michel(a)daenzer.net> ---
Does this also happen with the modesetting driver instead of xf86-video-amdgpu?
--
You are receiving this mail because:
You are the assignee for the bug.
Hi,
Changes since v1:
- normalize_zpos flag moved to drm_mode_config
- Added comment to note the side effect of normalization and updated the comment
for normalized_zpos in the header file as well.
- Added Acked-by from Daniel to patch 2-6 but not for patch 1 as I'm not sure if
the comments I have added matches with what is expected to be.
The first patch is adding a flag to drm_device that drivers can set if they want
the zpos to be normalized.
Then convert exynos, tegra, sti and rcar-…
[View More]du to use this flag instead of
re-implementing the drm_atomic_helper_check() locally just to add the call to
drm_atomic_normalize_zpos().
The last patch is moving omapdrm to use the zpos normalization as well to comply
with the UAPI documentation regarding to zpos.
Laurent's note in an earlier thread:
https://marc.info/?l=dri-devel&m=151567355225029&w=2
"The problem is that zpos normalization requires accessing the state of all
enabled planes for a CRTC in order to compute (and store) the normalized zpos
values. This thus forces all planes to be added to the commit state, even when
the commit doesn't touch the zpos property. I assume this caused issues
(possibly performance issues) in drivers that then performed hardware setup of
all planes as a result."
can be addressed later in the core for all users of drm_atomic_normalize_zpos()
Regards,
Peter
---
Peter Ujfalusi (6):
drm: Add drm_mode_config->normalize_zpos boolean
drm/exynos: Let core take care of normalizing the zpos
drm/tegra: Let core take care of normalizing the zpos
drm/sti: Let core take care of normalizing the zpos
drm: rcar-du: Let core take care of normalizing the zpos
drm/omap: Use normalized zpos for plane placement
drivers/gpu/drm/drm_atomic_helper.c | 11 +++++++++++
drivers/gpu/drm/exynos/exynos_drm_drv.c | 20 --------------------
drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 -
drivers/gpu/drm/exynos/exynos_drm_fb.c | 4 +++-
drivers/gpu/drm/omapdrm/omap_drv.c | 3 +++
drivers/gpu/drm/omapdrm/omap_plane.c | 2 +-
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 11 ++---------
drivers/gpu/drm/sti/sti_drv.c | 24 +++---------------------
drivers/gpu/drm/tegra/drm.c | 27 +++------------------------
include/drm/drm_mode_config.h | 8 ++++++++
include/drm/drm_plane.h | 4 ++--
11 files changed, 36 insertions(+), 79 deletions(-)
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[View Less]