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?
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.
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.
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
