Date: Wed, 3 Feb 1999 08:25:04 -0600 (CST) From: Kevin Day <toasty@home.dragondata.com> To: dot@dotat.at (Tony Finch) Cc: hackers@FreeBSD.ORG Subject: Re: USB drivers Message-ID: <199902031425.IAA21006@home.dragondata.com> In-Reply-To: <E10701v-0004uS-00@fanf.noc.demon.net> from Tony Finch at "Jan 31, 1999 4:47:27 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > >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. > This is done now. The Cyrix MediaGX series, as well as a few other cpu'ss use a unified memory system, where video ram is pulled from system ram. Having your bzero() speed vary depending on what video mode you're in takes a while to get used to. :) > 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. While I can't name names, (NDA's), several 2d/3d chips out there now allow you to at least busmaster data from ram into the chip, without the CPU's involvement. You can also setup a circular buffer of commands for the draw unit to do in memory, and give the chip an address, and tell it to 'go', and just keep filling the buffer and bringing stuff off of disk as needed. As to having the video system talk directly to the disk.... Now that would be an interesting system. Kevin Day 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?199902031425.IAA21006>