Date: Mon, 8 Mar 1999 22:45:29 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Jason Thorpe <thorpej@nas.nasa.gov> Cc: The Hermit Hacker <scrappy@hub.org>, Mike Smith <mike@smith.net.au>, "Daniel C. Sobral" <dcs@newsguy.com>, Terry Lambert <tlambert@primenet.com>, sos@freebsd.org, freebsd-hackers@freebsd.org, yokota@freebsd.org Subject: Re: GGI Message-ID: <Pine.BSF.4.05.9903082241030.23337-100000@herring.nlsystems.com> In-Reply-To: <199903081832.KAA00878@lestat.nas.nasa.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 8 Mar 1999, Jason Thorpe wrote: > On Mon, 8 Mar 1999 00:26:02 -0400 (AST) > The Hermit Hacker <scrappy@hub.org> wrote: > > > A friend just picked himself up a Voodoo2 card that Linux now supports and > > keeps cramming down the "FreeBSD doesn't support 3D accelleration" line > > down my throat :( My card is *supposedly* faster then what he has, from > > comparing specs...be great if I can slam it back down his throat :) > > Why should FreeBSD (or NetBSD for that matter) have to care about the > acceleration on the card? An operating system shoudl care about that > only for if the console is a linear framebuffer, and you want scrolling > to be Really Fast. (NetBSD's "wscons" console driver has hooks in the > terminal emulation layer for using hardware acceleration, which we > use on TURBOchannel "sfb" framebuffers, and soon on PCI TGA framebuffers.) > > For _everything_ else, it all belongs in userland. At this point, the > OS's responsibility is to provide a reasonable set of device mapping > primitives which allow source code portability across architectures. > NetBSD's "wscons" has some (albiet not all, yet) of the hooks for this, > as well as some other basic things to make it possible to implement naive > graphics applications, such as get/set colormap, get/set hardware cursor > shape, get/set hardware cursor position, etc. It just isn't possible to get full performance out of a modern DMA driven 3D chipset (which doesn't include the 3dfx) without a very small kernel based driver to feed the DMA pipe. Pretty near all of the rest of the code can live in userland. The bandwidth requirements for fast 3D are much greater than 2D. The 3dfx has a memory-based fifo to feed commands to the card and for this device, the only privileged operation is mapping the register set. AFAIK, the kernel driver for 3dfx does just this. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9903082241030.23337-100000>