> 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.
First, it is GGI, not CGI. Second, why must this be set in
stone? If things can change as much as they have in the /proc
filesystem, a precedent is there for this sort of thing. Besides, there
are undoubtedly ways of either ensuring complete backwards compatibility
(i.e., IOCTLs only get added, never removed or modified) or implementing
some srt of versioning scheme to ensure that older apps always use the
IOCTL set they were compiled to use. I'm sure that there are other
solutions as well.
> 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.
It wouldn't be a bad idea to use those primitives as our API (or
part of it, anyway). What you say is true - there are going to be lots of
OpenGL-supporting boards soon (which may become a standard hardware
acceleration interface).
> 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.
See above.
> 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.
Since both codebases are free, why duplicate the work? Either
they develop it first and we use their code, or the reverse.
> 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?
If an XFree driver for the card exists and no one that has one of
the cards wants to port it, I won't have much sympathy for them. If your
hardware isn't supported by Linux and you don't want to do that support up
yourself, don't bitch. That's the way it has always been. Besides, this
probably won't be an issue, seeing as how porting video driver from one
API to another isn't all THAT difficult (I'm doing this very task right
now for Mach32 and Trio64). If the XFree people did a driver for card
XYZ, I'd be very surprised if no one who had the card and used Linux was
willing to port the driver. As a last resort, we *could* always ask them
to keep making server for Linux anyway, at least the ones for cards W/O
GGI drivers yet.
> 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.
See above.
Jon Taylor = <taylorj@gaia.ecs.csus.edu> | <http://gaia.ecs.csus.edu/~taylorj>
------------------------------------------------------------------------------
"Everything in excess! To enjoy the flavor of life, take big bites.
Moderation is for monks." - Lazarus Long