On Mon, 2003-07-14 at 12:32, Denis Oliver Kropp wrote: > Quoting Michel D�nzer ([EMAIL PROTECTED]): > > On Sun, 2003-07-13 at 23:45, Torgeir Veimo wrote: > > > > > > How far away is running OpenGL apps with DRI drivers alongside this new > > > ati driver? > > > > I don't know the status of the Radeon DRI drivers wrt DirectFB (I'm > > curious myself :), but I know that it would likely be unstable unless > > the DirectFB driver cooperates and also uses the CP. But then that may > > be required for blending and scaling anyway. > > The Radeon DRI driver should work with DirectFBGL, at least without > hardware acceleration in DirectFB. There's no need for a DirectFB driver > to get a DRI driver working for DirectFBGL.
But software rendering sucks. :) > Unfortunately, the Radeon DRI driver in embedded-2-branch has to be > changed the way like the Matrox driver did. It's not trivial, but not > that difficult, too. I'll try to sort this mess out when I get some time. :\ A unified driver would definitely be great, I'm mostly interested in GLX with XDirectFB though. > DirectFB and DRI drivers are cooperating nearly automatically. The DirectFBGL > core acquires the graphics lock of DirectFB before acquiring the lock of DRI > and pumping the last DRI state to the hardware. This is typically done before > rendering a whole frame. After that both locks are released and the application > most probably flips the surface. The DirectFB driver is told to (re)initialize > the engine when the next graphics lock is done by DirectFB . The problem is direct register writes while the CP is running. Even radeonfb ioctls can cause lockups, the XFree86 radeon driver at least grabs the DRM lock and idles the CP around them, it even stops the CP for some. -- Earthling Michel D�nzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
