Add i.MX8MQ machine template that uses etnaviv

Close for JJ RC3

@Farshid Monhaseri, I provided the template since there was interest expressed and I had previously experimented with it a bit, it's up to AGL users to decide what they want to use.  NXP provide no developers to support upstream AGL development, so all i.MX support is community driven, and for the most part has been done by me the last several years to attempt to provide a starting point for people.  If you want to use Vivante, there's the imx8mqevk-viv template for reference, something similar is relatively straightforward to do for i.MX6 platforms.

I don't know when you tried i.MX6 and how you tried it, but we (Collabora) have experience with many deployments of etnaviv in i.MX6DL/Q/QP in the field where the performance is superior to the proprietary driver. This includes the open upstream 'coda' driver for zerocopy media support, where we are able to decode high-resolution videos with very low CPU usage using a fully-upstream Linux/GStreamer/Weston/Mesa stack.

For i.MX8MQ, we have been able to support 4K UI workloads with the open driver - a level of performance NXP claimed was not possible to achieve, and again higher than the proprietary driver. (I cannot share specific details as they are of a non-AGL customer product, but the UI was based on Qt, and we used upstream Weston/Mesa/KMS for display.)

Regardless of performance though, people may have other reasons for choosing a different stack. These include long-term support and maintenance from the upstream communities, security issues with the proprietary BSP, stability and conformance requirements, the ability to use other vendors for support and modification of the BSP, etc. All these reasons are quite relevant for automotive.

Closer integration with upstream communities is also a strong goal of AGL. We fully support the open-source upstream i.MX ecosystem, and believe that doing so is strongly relevant to AGL.

@Scott Murray using etnaviv sound good but It is not practical in production! ... The performance of IMX open source graphic stack components is way behind the its proprietary equivalents . I tested the etnaviv vs vivante on imx6. When we use etnaviv, we lost the imx original GStreamer elements and on heavy-duty multimedia processing (e.g. h264 streams video codding/decoding) considerably we will have poor performance with etnaviv driver and other open-source components (imx community-written and generals elements) as compare as vivante with the forked DRM, Weston, GStreamers components.
An imx6solo with vivante and imx GStreamer components could stream a live h264 video stream with 30fps with almost no CPU usage (totally hardware-accelerated and zero-copy) but we a lot of efforts, try-error and setting optimal properties for open-source elements and GStreamer pipeline, I could rich the same functionality with %30 average CPU usage (with v4l2 h264 decoder & sink to an OpenGL context). Maybe It can be optimized better but I can say, it is not straightforward at all. Because of that personally, I don't like the imx open-source graphic & multimedia stack for now, but I hope they would be improved in the near future. Maybe on imx8 they have better performance, did you have any performance analyzing the etnaviv vs vivante on imx8 family?