From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin C.Atkins To: 9fans@cse.psu.edu Subject: Re: [9fans] lucio- now: student projects Message-Id: <20020312183836.1e652e48.martin@mca-ltd.com> In-Reply-To: <20020312102009.D97E1199EE@mail.cse.psu.edu> References: <20020312102009.D97E1199EE@mail.cse.psu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Tue, 12 Mar 2002 18:38:36 +0530 Topicbox-Message-UUID: 65525b4c-eaca-11e9-9e20-41e7f4b1d025 On Tue, 12 Mar 2002 10:13:22 0000 forsyth@caldo.demon.co.uk wrote: > >> I believe that most real-time video boards write directly into > >> the video adaptor's memory - how would this best be integrated with > >> the Plan 9 graphics system? > > it's not uncommon now to find that the `video adapter's memory' > is the processor's memory; there's even a separate MMU for it. You mean on the 810, etc motherboards... Yes. I think the video capture cards I'm thinking of should work with any memory that's addressable from the PCI bus. > >> be a bottleneck? X has come up with techniques to let the application > >> write directly into a window's memory to get reasonable performance in this > >> situation - how would Plan 9 address this, hopefully without these > >> extra levels of complication? > > i think a write to /dev/draw of properly aligned and formatted data to > an unobscured window amounts to a memmove > from user memory directly into a linearly-mapped frame buffer. Ultimately, this might still end up with one more copy than is strictly necessary (without doing truely horrible things with page tables, a la Mach), depending on how the double buffering works. Do the commands on /dev/draw lend themselves to having the data "properly aligned"? But nevertheless, that *is* quite encouraging! (Of course, if the screen is remote, then it's not going to work however clever we are - but then neither is the X "solution") > > unlike 8-1/2 where /dev/bitblt was multiplexed by 8-1/2 itself as a file server > (i'm not using the Unicode 1/2 because of some stupid mail gateways), with rio > applications us their own connection to /dev/draw directly, and application graphics operations > therefore go direct to the frame buffer (if there is one) through the > kernel without going through rio. Yes, that would be a requirement. > scheduling the frame rate precisely might or might not be a problem. > i'd know already except that the nicest free DVD playing software i can > find looks all right itself but is buried in one of those ./configure marvels. > Yep - I just close my eyes and hope whenever I come across one :-). So maybe we won't have to wait for a student? :-) ! Would extra commands on /dev/draw be feasible for 3-D graphics? They'd have to be designed with "some care"! Martin -- Martin C. Atkins martin@mca-ltd.com Mission Critical Applications Ltd, U.K.