On Thu, Mar 17, 2005 at 10:30:01AM +1100, Benjamin Herrenschmidt wrote: > On Wed, 2005-03-16 at 23:08 +0200, Ville Syrjälä wrote: > > On Wed, Mar 16, 2005 at 03:58:07PM -0500, Alex Deucher wrote: > > > I haven't seen anyone coming forward with a design/code for the memory > > manager. > > > > In the meantime I'm assuming that people might want to make some use of > > their dualhead cards... > > Are you aware that with the current fbdev API, there will simply be no > working use of dual head ? As soon as somebody will try to do 2 > different things on the 2 heads, it will either lockup due to lack of > engine arbitration, or have wrong endianness, or whatever ...
I understand you can't have userspace program the accelerator while someone else is doing the same thing. Oh and I now understand that the same really applies to direct framebuffer access due to the swapper. I hadn't really thought about that issue before since I don't own a big-endian system. I really must try to get one... So basically to fix both issues we need some locks everyone must acquire before accessing the hardware. With the current "mmap() registers and go" interface the accelerator lock wouldn't actually guarantee anything but it would allow well behaving applications to share the accelerator. Good behaviour is already expected from the applications anyway due to the direct access to hardware registers. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
