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. 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
pgpTtITkP99xw.pgp
Description: PGP signature
