[lkml]   [1996]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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

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

 \ /
  Last update: 2005-03-22 13:37    [W:0.096 / U:7.852 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site