On Fri, 31 Dec 2004 13:17:34 -0500, Adam Jackson <[EMAIL PROTECTED]> wrote: > On Friday 31 December 2004 09:56, Felix Kühling wrote: > > I have a seventh option for you. Feel free to flame me if it sounds > > stupid ... > > > > - Option 7: Run the GLX server as a separate process forked by the > > Xserver. This way you get rid of the problem with the same library > > linked into the same process multiple times. > > > > Pros: No existing ABIs need to be changed. It would also improve the > > responsiveness of the Xserver when expensive indirect rendering > > operations are performed (for instance software fallbacks). > > This is indeed a major problem. Indirect glxgears is extremely laggy at > processing user input (and worse in 6.8 than it used to be...) > > > Cons: GLX protocol goes through the same channel as X protocol. So doing > > GLX in a separate process would involve forwarding GLX protocol from the > > Xserver to the real GLX server process in some way. Not sure how much > > overhead in time and code complexity that would introduce. > > I'm not sure either. I'd take it as a given that people using indirect > rendering are willing to sacrifice some performance, but they shouldn't be > made to suffer more than necessary. We do have something resembling this in > the form of DMX's glxProxy, but I don't know how much work would be required > to split that out into a helper process. I assume it's doable though. > > The higher issue is that enabling the X server to also be a DRI client is work > that needs to happen for X on GL anyway. That statement doesn't invalidate > the glxProxy approach: The Xgl server could translate core X11 (and > Render/Xv/...) to GL and feed all drawing requests to the glxProxy. Which > would be a rather interesting subversion of the X design. > > So I guess I don't have any hard arguments against that approach. The soft > argument would be that doing indirect GL in the server reduces overall > component count, whereas the proxy approach is trading GLcore for glxProxy. >
glxproxy might also be a better route for adding accelerated 3d support in conjunction with xinerama (where you may have mutliple backend 3d engines, or even shared access to a single 3d engine) rather than having to run dmx or something similar. Alex > Or, to quote the horse from Ren and Stimpy, "No sir, I don't like it." ;) > > They're not mutually exclusive, though. There might be value in doing both, > in-server DRI for maximal performance versus glxProxy for more stability in > the face of driver bugs. If you design the API right pluggability wouldn't > be too hard. > > - ajax > > ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
