From: Philip B. <ph...@bo...> - 2003-03-26 21:19:47
|
On Wed, Mar 26, 2003 at 12:22:48PM -0800, Ian Romanick wrote: > ... The memory management code that is in the 3D driver (for doing > the allocations and communicating with the DRM) really has to be there. > Moving it into the X server would really hurt performance. There's > really only four possible solutions: > > 1. Have the X server call the code in the 3D driver. > 2. Have the 3D driver call the code in the X server. > 3. Have the code exist in both places. > 4. Leave things as they are. > > I'm saying the #2 is unacceptable for performance reasons. You're > saying that #1 unacceptable for software engineering reasons. We're > both saying that #3 is unacceptable for software engineering reasons. > Users are saying #4 is unacceptable for performance reasons. Where does > that leave us? > > To be perfectly honest, I would much rather pick #3 over #2 or #4. Likewise. However, I think that your evaluation of #2 is premature. There are a few different ways to accomplish that, and I dont think you're seeing all the possibilities clearly. > If the paged memory system is only used when DRI is enabled, does it > really matter where the code the X server calls is located? Could we > make the memory manager some sort of API-registered callback? It would > be one that only DRI (and perhaps video-capture extensions) would ever > use, but still. Details of the API sound like some good fodder for a long irc discussion > I really do want to find a compromise here. I really want to help make > Linux / XFree86 a first-class platform for 3D. Right now there are a > few infrastructure elements missing, and I believe that this is a > significant one. There are two issues from the end-user perspective: > stability and performance. Since this is a performance issue, I can't > in good conscience accept a solution that loses significant performance. The users will always cry about performance more. But you have to always consider stability FIRST. Performance can usually be incrementally improved. Stability is not so easy. Stability comes first and formost from clean design, which leads to better maintainability, and smaller scope of debugging (ie: modularity) |