On Wed, Mar 23, 2011 at 9:09 AM, Robert Fekete <robert.fek...@linaro.org>wrote:
> On 21 March 2011 21:08, Alex Deucher <alexdeuc...@gmail.com> wrote: > > On Mon, Mar 21, 2011 at 3:50 PM, Geert Uytterhoeven > > <ge...@linux-m68k.org> wrote: > >> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes <jbar...@virtuousgeek.org> > wrote: > >>> On Mon, 21 Mar 2011 19:19:43 +0000 > >>> timofonic timofonic <timofo...@gmail.com> wrote: > >>>> So if KMS is so cool and provides many advantages over fbdev and > >>>> such... Why isn't more widely used intead of still relying on fbdev? > >>>> Why still using fbdev emulation (that is partial and somewhat broken, > >>>> it seems) instead using KMS directly? > >>> > >>> Used by what? All three major GPU device classes have KMS support > >>> (Intel, ATI, and nVidia). If you want it for a particular device, you > >>> can always port it over. > >> > >> The three major GPU device classes on PC... > > > > Sadly it gets worse. A lot of the SoC vendors are adding an fbdev > > emulation layer on top of v4l rather than using fbdev directly or > > using KMS and v4l has grown it's own edid, hdmi, and cec handling. > > > > I agree, it is sad that as a SoC vendor there are different > kernel/user API's(v4l2/fbdev/drm) to choose from when implementing say > a Display controller driver. One must also remember that there are big > differences between a desktop/PC multimedia/graphics system and the > ones present on an embedded SoC. It is two very different cultures and > HW designs now trying to merge into one Linux Kernel. Of course there > will be some overlaps but I believe it can be sorted out as soon as we > understand each others different possibilities/limitations. Doing > duplicate work like HDMI will not benefit any party. > > Just to list some of the differences. > > - Developments within V4L2 has mainly been driven by embedded devices > while DRM is a result of desktop Graphics cards. And for some extent > also solving different problems. > - Embedded devices usually have several different hw IP's managing > displays, hdmi, camera/ISP, video codecs(h264 accellerators), DSP's, > 2D blitters, Open GL ES hw, all of which have a separate device/driver > in the kernel, while on a desktop nowadays all this functionality > usually resides on ONE graphics card, hence one DRM device for all. > - DRM is closely developed in conjunction with desktop/Xorg, while X11 > on an embedded device is not very 2011...wayland on the other hand is > :-), but do wayland really need the full potential of DRM/DRI or just > parts of it. > - Copying buffers is really bad for embedded devices due to lower > memory bandwidth and power consumption while on a Desktop memory > bandwidth is from an other galaxy (copying still bad but accepted it > seems), AND embedded devices of today records and plays/displays 1080p > content as well. > - Not all embedded devices have MMU's for each IP requiring physical > contiguous memory, while on a desktop MMU's have been present for > ages. > - Embedded devices are usually ARM based SoCs while x86 dominates the > Desktop/Laptop market, and functionality provided is soon the very > same. > - yada yada....The list can grow very long....There are also > similarities of course. > > The outcome is that SoC vendors likes the embedded friendliness of > v4l2 and fbdev while "we" also glance at the DRM part due to its > de-facto standard on desktop environments. But from an embedded point > of view DRM lacks the support for interconnecting multiple > devices/drivers mentioned above, GEM/TTM is valid within a DRM device, > the execution/context management is not needed,, no overlays(or > similar), the coupling to DRI/X11 not wanted. SoCs like KMS/GEM but > the rest of DRM will likely not be heavily used on SoCs unless running > X11 as well. Most likely this worked on as well within the DRI > community. I can see good features all over the place(sometimes > duplicated) but not find one single guideline/API that solves all the > embedded SoC problems (which involves use-cases optimized for no-copy > cross media/drivers). > > Last but not least... > > On Linaro there is already discussions ongoing to solve one of the > biggest issues from a SoC point of view and that is a "System Wide > Memory manager" which manages buffer sharing and resolves no-copy use > cases between devices/drivers. Read more on the following thread: > http://lists.linaro.org/pipermail/linaro-dev/2011-March/003053.html. > > At least if you care about X11 (and probably wayland, since I assume it will inherit some of this from X11), one nice thing about drm/dri/gem is that it has already solved the problem with sharing buffers between X11 and video decoders/encoders (although some of that is a bit in vendor specific parts of vaapi).. but still it would be nice to somehow extend existing solutions so we have some better chance of desktop sw working on arm, rather than just throwing existing desktop solutions out the window.. If we add camera/v4l2 support for drm/dri (and maybe vaapi above that?), then I think we have full zero-copy use-cases, and something that existing desktop sw can run on with minimal/no work.. that said, I'm not quite sure how this should all fit together, but I am quite sure it should be done with an eye to enable existing sw to work, rather than a competing standard compared to what is done in the desktop world. BR, -R > BR > /Robert Fekete > st-ericsson > > _______________________________________________ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev >
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
