Hi Dave,
On 2017-04-20 21:02, Dave Airlie wrote:
On 20 April 2017 at 19:13, Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> wrote:
This is an updated proposal for extending EXYNOS DRM API with generic support
for hardware modules, which can be used for processing image data from the
one memory buffer to another. Typical memory-to-memory operations are:
rotation, scaling, colour space conversion or mix of them. This is
a follow-up of my previous proposal "[RFC 0/2] New feature: Framebuffer
processors", which has been rejected as "not really needed in the DRM core":
http://www.mail-archive.com/dri-devel@xxxxxxxxxxxxxxxxxxxxx/msg146286.html
In this proposal I moved all the code to Exynos DRM driver, so now this
will be specific only to Exynos DRM. I've also changed the name from
framebuffer processor (fbproc) to picture processor (pp) to avoid confusion
with fbdev API.
Here is a bit more information what picture processors are:
Embedded SoCs are known to have a number of hardware blocks, which perform
such operations. They can be used in paralel to the main GPU module to
offload CPU from processing grapics or video data. One of example use of
such modules is implementing video overlay, which usually requires color
space conversion from NV12 (or similar) to RGB32 color space and scaling to
target window size.
The proposed API is heavily inspired by atomic KMS approach - it is also
based on DRM objects and their properties. A new DRM object is introduced:
picture processor (called pp for convenience). Such objects have a set of
standard DRM properties, which describes the operation to be performed by
respective hardware module. In typical case those properties are a source
fb id and rectangle (x, y, width, height) and destination fb id and
rectangle. Optionally a rotation property can be also specified if
supported by the given hardware. To perform an operation on image data,
userspace provides a set of properties and their values for given fbproc
object in a similar way as object and properties are provided for
performing atomic page flip / mode setting.
The proposed API consists of the 3 new ioctls:
- DRM_IOCTL_EXYNOS_PP_GET_RESOURCES: to enumerate all available picture
processors,
- DRM_IOCTL_EXYNOS_PP_GET: to query capabilities of given picture
processor,
- DRM_IOCTL_EXYNOS_PP_COMMIT: to perform operation described by given
property set.
The proposed API is extensible. Drivers can attach their own, custom
properties to add support for more advanced picture processing (for example
blending).
So this looks more like a command submission API like we have for other drivers.
Is there an overarching reason why it needs to reuse the core drm
object tracking
and properties, or was that just a nice to have, vs something like
amdgpu chunks.
Thanks for your comment.
DRM objects and properties were my first choice when designing this new api,
but I'm still a bit new to DRM at all. I was also a bit fascinated by the
atomic KMS approach, though. I selected them simply to reuse the code for
managing objects and enumerating their properties from userspace. If this is
not the preferred approach, I will rewrite the code to use something custom.
I didn't know about amdgpu chunks, but from the quick look they are just a
structure to store a set of ids and data for them. Maybe there is no need to
use strings for enumerating the properties and limiting the API to the known
set of IDs will be more than enough in this case.
My worry about exposing objects and properties to the drivers is I'm
sure someone
could get quite inventive and end up with a forked atomic API that we don't see,
or undocumented things.
Okay. I will try different approach then.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
