Hi Arunkumar, Have you measured: 1) The time to load all of the dependencies and get to "int main" of the compositor? 2) The time from "int main" to the first rendered frame? Is this what you mean by 500 ms? This looks abnormally large to me. First one may be improved by programs like preload. For second one, you should use tracing within Weston to figure out where is most of the time being spent. -Satyeshwar -----Original Message----- From: wayland-devel <wayland-devel-bounces@lists.freedesktop.org> On Behalf Of Daniel Stone Sent: Monday, July 27, 2020 3:02 AM To: arunkrish20 <arunkrish20@gmail.com> Cc: svadive2@visteon.com; genivi-ivi <genivi-ivi-layer-management@lists.genivi.org>; wayland <wayland-devel@lists.freedesktop.org> Subject: Re: Trying to reduce boot time for weston and logo from weston Hi Arunkumar, On Mon, 27 Jul 2020 at 06:59, arunkrish20 <arunkrish20@gmail.com> wrote: > We are working with the i.MX8 platform. We are working with weston and DRM backend. Below are the version details. > > NXP BSP Version: 4.14.98_2.0.0_ga > SC Firmware Version : 1.3.1 > wayland version 1.16 am > weston- ivi - 5.0.0 We are currently working our way towards releasing Weston 9.0.0, so this version is quite old. > Our requirement is to display the first screen in 2 Seconds. > > In the current environment we are able to see the first screen in the 6th seconds. Ouch, that's quite long. > We tried to boot the weston in initramfs. But due to size constraints we are not able to. Size comes around 65MB. > > Is there any possibility for reducing the size of weston? Weston itself with the DRM + GL backends only takes around 750kB once installed. I assume the 65MB comes from extra dependencies, but that is something you would have to investigate and configure in your Yocto build. Weston itself does not have many dependencies, and those dependencies are not large. > Weston taking 500ms to complete the initialization. Can we reduce this timing? e.g if we block unwanted device probing etc, any idea? > > In case if we use separate drm based rendering application for the first screen and switching to weston are seeing blank. Instead of clearing the weston screen buffer can we have a logo on first rendering. so that blank can be avoided between the first drm application to weston rendering. NXP has forked Weston and written their own backend, which is responsible for the initialisation (both the time and the blank screen). The default DRM backend is quite quick to come up and be responsive, and doesn't blank the screen. So both these issues are something you'd need to raise with NXP support, as they are due to NXP's changes to our code. Cheers, Daniel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Hi Satyeshwar, Thanks for your input. Following is the sequence to render the first screen. will it not take atleast 500~ms? 1. weston init.(clear the screen content). 2. Create a window from the user application process and render the content. 3. Layer manager needs to react to the window creation and the render order configuration. 4. Then only rendered content can be seen in the display. If we want stripdown weston dependencies then what could be your input? Thanks in advance, Arunkumar R On Tue, Jul 28, 2020 at 7:28 AM Singh, Satyeshwar < satyeshwar.singh@intel.com> wrote: > Hi Arunkumar, > Have you measured: > 1) The time to load all of the dependencies and get to "int main" of the > compositor? > 2) The time from "int main" to the first rendered frame? Is this what you > mean by 500 ms? This looks abnormally large to me. > > First one may be improved by programs like preload. For second one, you > should use tracing within Weston to figure out where is most of the time > being spent. > -Satyeshwar > > -----Original Message----- > From: wayland-devel <wayland-devel-bounces@lists.freedesktop.org> On > Behalf Of Daniel Stone > Sent: Monday, July 27, 2020 3:02 AM > To: arunkrish20 <arunkrish20@gmail.com> > Cc: svadive2@visteon.com; genivi-ivi < > genivi-ivi-layer-management@lists.genivi.org>; wayland < > wayland-devel@lists.freedesktop.org> > Subject: Re: Trying to reduce boot time for weston and logo from weston > > Hi Arunkumar, > > On Mon, 27 Jul 2020 at 06:59, arunkrish20 <arunkrish20@gmail.com> wrote: > > We are working with the i.MX8 platform. We are working with weston and > DRM backend. Below are the version details. > > > > NXP BSP Version: 4.14.98_2.0.0_ga > > SC Firmware Version : 1.3.1 > > wayland version 1.16 am > > weston- ivi - 5.0.0 > > We are currently working our way towards releasing Weston 9.0.0, so this > version is quite old. > > > Our requirement is to display the first screen in 2 Seconds. > > > > In the current environment we are able to see the first screen in the > 6th seconds. > > Ouch, that's quite long. > > > We tried to boot the weston in initramfs. But due to size constraints we > are not able to. Size comes around 65MB. > > > > Is there any possibility for reducing the size of weston? > > Weston itself with the DRM + GL backends only takes around 750kB once > installed. I assume the 65MB comes from extra dependencies, but that is > something you would have to investigate and configure in your Yocto build. > Weston itself does not have many dependencies, and those dependencies are > not large. > > > Weston taking 500ms to complete the initialization. Can we reduce this > timing? e.g if we block unwanted device probing etc, any idea? > > > > In case if we use separate drm based rendering application for the first > screen and switching to weston are seeing blank. Instead of clearing the > weston screen buffer can we have a logo on first rendering. so that blank > can be avoided between the first drm application to weston rendering. > > NXP has forked Weston and written their own backend, which is responsible > for the initialisation (both the time and the blank screen). The default > DRM backend is quite quick to come up and be responsive, and doesn't blank > the screen. So both these issues are something you'd need to raise with NXP > support, as they are due to NXP's changes to our code. > > Cheers, > Daniel > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel >