Originally posted by elanthis
View Post
1. Memory management APIs differ from hardware vendor to another (since the underlying hardware is quite different in that area) so at least part of the "common DDX code" is not likely to be common any time soon.
2. The DDX code doesn't seem to represent a big maintenance overhead today and so it would be a lot more work to replace it than to keep the current DDX code going.
If we reach a point where the DDX code needs to be substantially re-written anyways (new acceleration APIs inside X or radically different hardware) then it might make sense to rewrite part of the code using Gallium3D operations, but for now it seems to make more sense to leave DDX alone and work on other parts of the stack instead.
It's a bit like the transition to Gallium3D - if you were writing a driver from scratch then writing it against the Gallium3D interfaces is less work than writing a "classic" driver... but if you already *have* a classic driver that works then re-writing to Gallium3D is *more* work rather than less.
One minor point -- the Gallium3D interface is not actually exposed by mesa - the code just happens to reside in the mesa tree because mesa is "the first and biggest customer". AFAIK the Gallium3D pipe and winsys drivers are built into whatever driver uses them, so there would be a copy of the drivers in the DDX, a copy in mesa, a copy in the video decode driver etc...
Comment