On Tue, 2003-03-25 at 21:48, Keith Whitwell wrote:
The final point that I would like to make is that we're going to NEED to load the DRI driver on the server-side at some point in order to support accelerated server-side rendering. We could then implemented a server-side software-only "DRI" driver. This driver could then export a wide variety of fbconfigs (16-bit/32-bit/floating-point per channel color for pbuffers) that the underlying hardware doesn't support.
It really shouldn't be that hard. Against it are:
One thing I never understood was whether the server should do this or fork off a client which is just another DRI direct render application that happens to get told to render the GLX commands coming down the connection from the remote host. I've no real feel for the costs of doing it that way, or enough experience to know if I'm talking out of my hat obviously.
People want to fork it off for two reasons:
1) They fear the latency caused by doing the whole 3d pipe while blocking the 2d server.
2) By forking it off, the 3d driver is always on a client of some sort, so there is some consistency there. XFree86 has the additional issue of the binary module format.
At the moment, the software 3d rendering is done in the server, so doing hw rendering in the server can't be any worse... I think there's a fair degree of overestimation of the latencies, etc that would be caused from doing hw 3d in the server process. It's not as if a client couldn't send a similar number of 2d requests to the server.
The binary module format issues are seperate, but I think IHV's like NVIDIA & ATI who distribute their own 2d modules get to bypass the guidelines & just issue direct dlopen()'s from inside their drivers.
Keith
------------------------------------------------------- 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
