Messages in this thread |  | | Date | Wed, 5 Jun 1996 20:25:04 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: SVGA kernel chipset drivers. |
| |
The problem with the GCI architecture you've described it is that it's locked into whatever acceleration features that the GCI team knew about when it first created the GCI architecture.
For example, if they're not already available, I'm sure we'll soon see boards which implement the OpenGL 3-D drawing primitives directly --- all 130 of them. If the GCI architecture doesn't have room for these accelerations in its Kernel-based ioctl API, then an X-server based on the GCI architecture won't be able to use those accelerated functions.
And if GCI has already thought about OpenGL, there will most assuredly be some new acceleration function dreamed up by seom vendor which GCI won't have anticipated.
Finally, please remember that in the grand scheme of things GCI will double the amount of work required; when a vendor releases a new card, someone will have to write a GCI Linux kernel module, and XFree86 will have to put support into their servers directly. After all, remeber that XFree86 runs on a large number of OS's, not just Linux, and so regardless of what we do, XFree86 will still have to do all of this work.
And if we convince XFree86 to do a CGI X server in addition to all of their other servers, and we further convince them not to do native servers for all of the other boards, what happens when we start finding trouble for someone to write the CGI Kernel piece? It may very well be that board X is supported on NetBSD running XFree86, but not under Linux running XFree86, since XFree86 may have stopped supporting native board access for Linux, and no one has written the Linux GCI driver for board X yet.
- Ted
|  |