Date: Sun, 31 Jan 1999 16:47:27 +0000 From: Tony Finch <dot@dotat.at> To: hackers@FreeBSD.ORG Subject: Re: USB drivers Message-ID: <E10701v-0004uS-00@fanf.noc.demon.net> In-Reply-To: <199901310006.RAA25943@usr04.primenet.com> References: <E106FOS-0003F1-00@fanf.noc.demon.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert <tlambert@primenet.com> wrote: >> >Anyone considered building a PC whose only means of talking to >> >the world is a USB port? >> >> It'd be rather crippled with only 12Mbit/s of IO. > >Beats ethernet... I doubt I'd want to swap over it, though :-) >> >Anyway, Amancio says he'd prefer FireWire for the monitor (at it's >> >slowest, FW can transfer 68 Mbits/S more a second than PCI!), but >> >of course he's a video geek. 8-). >> >> I think you have your bits and bytes mixed up :-) Firewire starts out >> at 100Mbit/s (or at least it did when I first heard about it in 1994) >> and PCI starts at 132Mbyte/s. IIRC Firewire was designed to be >> extended to 800Mbit/s which doesn't get very near PCI's minimum. > >Feh. You're right. Mea Culpa (and the maximum is 400Mbits/S). On >the plus side, the PCI number you have is a burst rate, and not >sustainable for something like a video frame rate. The same is true for FireWire, of course. If I remember the wire protocol correctly there's an overhead of about 50%. >And I guess the ability to pull an Amiga and use a section of main >memory as video memory, with a memory bus connector, instead of >on-board video hardware. I'm not convinced that this is feasible nowadays. For years now graphics cards have had fairly special memory architectures (VRAM etc.) so that they can stream data from the RAM to the DAC at a couple of hundred megapixels per second without killing the bandwidth available to the controller (let alone the CPU). I was never an Amiga geek but I guess "chip RAM" or whatever it was called was supposed to address this problem. But then: > What you should do instead is send S3/ATI/whatever commands to a chipset > in the monitor case, running the raster out of dual ported RAM based > on what the engine has been told to render. > > This is less useful for, say, throwing BT848 input to a monitor, but > you'd expect that video hardware would use the computer as a peripheral > instead of the other way around (i.e., you're video-in-to-video-out > would ignore the computer, for the most part, if you are trying to move > all of the pixels in sync with an input source, as opposed to generating > the pixels computationally. It would also be cool to be able to plug your disks and your graphics controller into the same bus so that you can tell your rendering engine to load its graphics from over there and then spend some time doing something more useful than shuffling megabytes... Maybe in a year or two :-) Tony. -- f.a.n.finch dot@dotat.at fanf@demon.net 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?E10701v-0004uS-00>