On Fri, May 21, 2010 at 1:52 AM, Denis Oliver Kropp <d...@directfb.org> wrote: > Melwyn Lobo wrote: >> >> Hi, >> On my platform, I need to move the voodoo renderer (server) to a >> simple (mmu less) RTOS, serving requests from a DFB client >> applications running on a processor having linux kernel, are these the >> things I need to port: > > What exactly do you mean by voodoo renderer? [ edit: saw later, see below > ] > > The Voodoo server is usually the dfbproxy executable which is > either slave or master of a local DirectFB session. > > Do you want to run a whole DirectFB master on the other core?
No. I need to run all DFB client apps and the master on the main core. dfbproxy would run on the other core (acclerator). This assuming the first app to start on the main core would become the master. So does this imply that DirectFB instance would belong to dfbproxy rather than the master app on the main core? Or I am missing something. > >> 1. voodoo underlying IP socket communication with something else >> (Shared memory ?) > > I have Voodoo working via pipe or socket pairs between forked processes. > > Adding a shared memory transport would not be difficult. ok. > >> 2. Fusion kernel module to user space fusion. > > You would use the single application core on the RTOS. It's just using > pthreads. > >> 3. Underlying systems fbdev to be replaced with RTOS render functionality > > Yes, a system module would be required. > >> First is the above correct and logical way to proceed. If anyone has >> prior experience with such an architecture can you please highlight >> the pitfalls faced. >> >> Second, In an ordinary (single processor) DFB world with no libvoodoo, >> the first DFB app becomes the server and takes control of the input >> devices, ttyx and fb. DFB apps starting up after the this first one >> assume the role of a slave and communicate their rendering requests to >> the server via fusion. Does this also apply in libvoodoo (over RTOS) >> environment, where the first DFB app (running on linux) becomes >> master, or all DFB apps have same role to play. For example, which DFB >> app can read input and ttyx device events. > > A Voodoo client does not have a DirectFB instance itself, but only uses > proxy interfaces. > >> Third, on my platform with framebuffer being a shared memory between >> the two processors, Is it possible that I choose only specific >> operations that should be communicated with the (voodoo) server and >> some other operations can be done in the normal (voodoo-less) fashion. > > I see, you like to have some rendering methods running on the other core > and use libvoodoo for RPC. > > At the moment you cannot easily move components to other cores, > but that's being worked on :) > > For now you'd have a Fusion based multi application session running on the > CPU and your driver or system module would use libvoodoo internally for RPC > with your other code on the other core. Hence the question above of who owns/creates a DirectfB instance and becomes the master app in the 2-core DFB voodoo based environment Thanks, M. > >> Fourth, since fusion is only meant for IPC, does voodoo make fusion >> obsolete? > > Fusion is the IPC between local DirectFB instances within a multi > application > session. Voodoo just adds a very efficient layer to use the public DirectFB > API > (or other APIs) remotely, without a DirectFB instance on the client. > > You could run multiple applications in one session by using Voodoo only, > i.e. > having the dfbproxy be the single application core process. > > So it's rather an alternative. > > -- > Best regards, > Denis Oliver Kropp > > .------------------------------------------. > | DirectFB - Hardware accelerated graphics | > | http://www.directfb.org/ | > '------------------------------------------' > _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
