Philip Brown wrote:
So since it is orthogonal, you should have no objections to lowest-level
allocation of video memory being done by GLX calling xf86Allocate routines, yes?
(ie: "leave the X core code alone")

That is what's currently done. The goal was two fold. One (very minor, IMO) goal was to allow the pixmap cache to cooperate with the texture cache. The other goal was to allow the amount of memory used by the front buffer to be dynamic when the screen mode changes.


I believe this whole thread started off by references to hacking X server
code to call DRI extension code. That is what I am arguing against, as
unneccessary. Extension code should call core code, not the other way
around  (except for API-registered callbacks, of course)

The way to do that is to reproduce code from the 3D driver in the X server. 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.

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.

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.

Do you think the guy playing Quake 7 or using Maya really cares if the X sever calls into extension code or if memory managment code is duplicated in the 3D driver and the X server? :) The question for us is, "Which compromise do we want to make to give the user what they want?"




------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to