> >> I understand the requirement for the multi-plane graphical chips in a > >> legacy > >> situation. > > Why do you say this is one legacy situation? I do believe it will provide > > better > performance than original HW overlay solution for video experience. > > What I meant by a legacy situation was that, historically the chips used in TV > and STB products where lower power, didn't have an embedded GPU and so > enabled compositing via specialized hardware for multiple planes. So I > understand how that situation is around. There are two types of compositing: one by software and one by hardware. The embedded GPU enabling compositing is something like software compositing who use OpenGL or Xrender to handle the alpha blending. And the hardware compositing method: multi pipeline method is providing several planes and finally composite them. And these two kinds of compositing can co-work together for TV usage. When you want to composite several video steams, you can use the method of multi pipeline. When you want to composite UI applications directly, you can use the software composite method. You can find CE4100's Product Brief from the internet and CE4100 provides both of these compositing methods. From that "Product Brief", you can find that it also have its CPU and GPU and the multi pipeline solution, and the whole SOC is with the low power(7-9W). Here is one product brief I found from the internet: http://www.wpgholdings.com/epaper/US/newsRelease_20091215/255874.pdf
> But to my mind, given the proliferation of mobile embedded CPU and GPU > technology and software > compositing that runs on these devices, I'm not sure that requirement for > specialized multi-plane hardware is relevant anymore. If anything, it's > probably > becoming an impediment. Here is the TV platform, multi-stream and stereo support are very significant features. We need this multi pipeline method to free the CPU and GPU to provide more powerful 2D & 3D user experiences. > -----Original Message----- > From: Glen Gray [mailto:sla...@slaine.org] > Sent: Tuesday, July 05, 2011 6:13 PM > To: Zhao, Juan J > Cc: 'Kristian H?gsberg'; 'meego...@lists.meego.com'; 'Ville M. Vainio'; > 'meego-dev@meego.com' > Subject: Re: [MeeGo-dev] which compositer will meego use for wayland? > > > On 5 Jul 2011, at 11:02, Zhao, Juan J wrote: > > >> I understand the requirement for the multi-plane graphical chips in a > >> legacy > >> situation. > > Why do you say this is one legacy situation? I do believe it will provide > > better > performance than original HW overlay solution for video experience. > > What I meant by a legacy situation was that, historically the chips used in TV > and STB products where lower power, didn't have an embedded GPU and so > enabled compositing via specialized hardware for multiple planes. So I > understand how that situation is around. But to my mind, given the > proliferation of mobile embedded CPU and GPU technology and software > compositing that runs on these devices, I'm not sure that requirement for > specialized multi-plane hardware is relevant anymore. If anything, it's > probably > becoming an impediment. > > >> Could Wayland+GPU not act as the multi-plane compositor now, composing > the > >> resulting TV image of the Picture, OSD etc. ? > > Yes, I also want this answer. And want to get along with it early. I do hope > that compositor can work as directFB and will provide such layer > functionalities. > > And how will this work? Can the client set its own plane directly? > > And I got the information that dri already took this considered. > > > > > ----- > > *^_^* BRs, > > Juan > > > > > > > >> -----Original Message----- > >> From: Glen Gray [mailto:sla...@slaine.org] > >> Sent: Tuesday, July 05, 2011 5:50 PM > >> To: Zhao, Juan J > >> Cc: Kristian H?gsberg; meego...@lists.meego.com; Ville M. Vainio; > meego-dev > >> list) > >> Subject: Re: [MeeGo-dev] which compositer will meego use for wayland? > >> > >> This is something I've actually been thinking of lately. It's so obvious > >> I'm sure > >> it's already been discussed and theres a valid reason for it not being > pursued. > >> However, I'll ask anyway :) > >> > >> I understand the requirement for the multi-plane graphical chips in a > >> legacy > >> situation. However, given the move towards GPU accelerated drawing and > >> compositing, is this still a requirement of the TV/STB hardware ? I've CC'd > the > >> meego-tv list on this question too as I think it's pertinent, especially > >> with > >> regard to getting dev boards up and running and not having sufficient > >> drivers > >> available for the CE4100 chipset. > >> > >> > >> > >> > >> On 5 Jul 2011, at 06:28, Zhao, Juan J wrote: > >> > >>> Meego TV platform have a special function--multi plane(multi pipeline). > >>> On Xorg, we use window manager to support this multi plane function. > >>> When moving to wayland, I think the compositor is still the best place to > >> support such functionality. > >>> So I raised this question; want to follow the meego compositer authors and > >> help to add our special functionality into that compositor. > >>> > >>> ----- > >>> *^_^* BRs, > >>> Juan > >>> > >>> > >>>> -----Original Message----- > >>>> From: meego-dev-boun...@meego.com > >>>> [mailto:meego-dev-boun...@meego.com] On Behalf Of Kristian > H?gsberg > >>>> Sent: Thursday, June 30, 2011 10:46 PM > >>>> To: Ville M. Vainio > >>>> Cc: meego-dev@meego.com > >>>> Subject: Re: [MeeGo-dev] which compositer will meego use for wayland? > >>>> > >>>> On Thu, Jun 30, 2011 at 10:22 AM, Ville M. Vainio <vivai...@gmail.com> > >>>> wrote: > >>>>> On Thu, Jun 30, 2011 at 2:41 PM, Thiago Macieira <thi...@kde.org> > >> wrote: > >>>>> > >>>>>> It doesn't. I was going to ask steven what reasons he had for using the > qt > >>>>>> compositor. It's just a sample compositor, showing what is possible to > do > >> if > >>>>>> you integrate the wayland libraries into a QML-based application. I've > >> seen > >>>>>> other experiments doing the same, some of which would definitely > never > >>>> qualify > >>>>>> for a product. > >>>>> > >>>>> One advantage of using Qt Compositor as starting point would be > making > >>>>> the compositor easy to modify, e.g. for OEM's looking for > >>>>> differentiated experience at compositor level. > >>>>> > >>>>> If you don't get worse performance with Qt Compositor, is there a good > >>>>> reason not to use it (as a starting point again, since it's not a > >>>>> "product" in itself)? > >>>> > >>>> It's not ready yet, and won't be for 1.3. > >>>> > >>>> Kristian > >>>> _______________________________________________ > >>>> MeeGo-dev mailing list > >>>> MeeGo-dev@meego.com > >>>> http://lists.meego.com/listinfo/meego-dev > >>>> http://wiki.meego.com/Mailing_list_guidelines > >>> _______________________________________________ > >>> MeeGo-dev mailing list > >>> MeeGo-dev@meego.com > >>> http://lists.meego.com/listinfo/meego-dev > >>> http://wiki.meego.com/Mailing_list_guidelines > >> > >> -- > >> Glen Gray > >> <sla...@slaine.org> > >> > >> > >> > > > > -- > Glen Gray > <sla...@slaine.org> > > > _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
