* Re: [9fans] lucio- now: student projects
@ 2002-03-12 10:13 forsyth
2002-03-12 13:08 ` Martin C.Atkins
0 siblings, 1 reply; 6+ messages in thread
From: forsyth @ 2002-03-12 10:13 UTC (permalink / raw)
To: 9fans
>> 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.
>> 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.
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.
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] lucio- now: student projects
2002-03-12 10:13 [9fans] lucio- now: student projects forsyth
@ 2002-03-12 13:08 ` Martin C.Atkins
0 siblings, 0 replies; 6+ messages in thread
From: Martin C.Atkins @ 2002-03-12 13:08 UTC (permalink / raw)
To: 9fans
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] lucio- now: student projects
@ 2002-03-12 14:59 andrey mirtchovski
0 siblings, 0 replies; 6+ messages in thread
From: andrey mirtchovski @ 2002-03-12 14:59 UTC (permalink / raw)
To: 9fans
> 1) What would be the "plan 9-ish" way to utilize 3-D hardware graphics
> support? To make available (something like) OpenGL?
> (Since just about everything has got 3-D support nowadays....)
I got libGL and libGLU (from Mesa3D) to compile using pcc, I even
started looking at a native compile couple of weeks ago but other,
more important things, got in the way. What would be a nice student
project (IMHO) would be to write a P9 driver for Mesa3D's GL. I looked
at the SVGA and X86 drivers and they appear relatively easy to manage.
From the XaoS port that dpx@lanl fixed couple of weeks ago we found
that double buffering is possible in P9 and it's not completely and
utterly slow, so.. :)
In fact I wanted to do that as a student project a year and a half
ago, but someone offered 'do bioinformatics with p9' since
bioinformatics was all the rage at the time ... *shudder*...
regards, andrey
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] lucio- now: student projects
@ 2002-03-12 12:28 forsyth
0 siblings, 0 replies; 6+ messages in thread
From: forsyth @ 2002-03-12 12:28 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 23 bytes --]
excessive optimism?
[-- Attachment #2: Type: message/rfc822, Size: 1884 bytes --]
To: 9fans@cse.psu.edu
Subject: Re: [9fans] lucio- now: student projects
Date: Tue, 12 Mar 2002 12:04:29 0000
Message-ID: <20020312120527.9B66919A0D@mail.cse.psu.edu>
> (i'm not using the Unicode 1/2 because of some stupid mail gateways)
I wonder why upas/marshal uses Content-Transfer-Encoding: 8bit rather than
quoted-printable for non-ascii message bodies? What is the relative
likelihood of mail gateways not handling the former vs mail readers not
handling the latter?
-- Richard
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] lucio- now: student projects
@ 2002-03-12 12:04 Richard Miller
0 siblings, 0 replies; 6+ messages in thread
From: Richard Miller @ 2002-03-12 12:04 UTC (permalink / raw)
To: 9fans
> (i'm not using the Unicode 1/2 because of some stupid mail gateways)
I wonder why upas/marshal uses Content-Transfer-Encoding: 8bit rather than
quoted-printable for non-ascii message bodies? What is the relative
likelihood of mail gateways not handling the former vs mail readers not
handling the latter?
-- Richard
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] lucio- now: student projects
2002-03-11 10:05 ` Luis Fernandes
@ 2002-03-12 7:17 ` Martin C.Atkins
0 siblings, 0 replies; 6+ messages in thread
From: Martin C.Atkins @ 2002-03-12 7:17 UTC (permalink / raw)
To: 9fans
Hi,
On Mon, 11 Mar 2002 10:05:19 GMT Luis Fernandes <elf@ee.ryerson.ca> wrote:
>..
>
> Sounds like you need xmotd for Plan9.
>
> I will add it to the todo list and perhaps propose it as a student
> project.
As a relative newcomer to Plan 9, or to actually running it, anyway,
I have some further suggestions for "student projects". Or perhaps they
already have answers?
1) What would be the "plan 9-ish" way to utilize 3-D hardware graphics
support? To make available (something like) OpenGL?
(Since just about everything has got 3-D support nowadays....)
2) What would be the "Plan 9-ish" way to do real-time video in a window?
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?
However, if the data is coming from the processor, such as playing
back a DVD, would writing it all through /dev/draw
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 know these are not, perhaps, the sorts of problem domains that Plan 9
has been used in, but it seems to me that before Plan 9 has any
hope of becoming a competitor to those "other" systems, these are the
sort of "everyday" things that there must be answers for....
Furthermore one would hope that the "Plan 9 approach" could be extended
nicely to every problem domain.
Any thoughts?
It makes a change from editor wars, anyway :-)!
Martin
--
Martin C. Atkins martin@mca-ltd.com
Mission Critical Applications Ltd, U.K.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-03-12 14:59 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-03-12 10:13 [9fans] lucio- now: student projects forsyth
2002-03-12 13:08 ` Martin C.Atkins
-- strict thread matches above, loose matches on Subject: below --
2002-03-12 14:59 andrey mirtchovski
2002-03-12 12:28 forsyth
2002-03-12 12:04 Richard Miller
2002-03-05 0:10 [9fans] lucio- geoff
2002-03-11 10:05 ` Luis Fernandes
2002-03-12 7:17 ` [9fans] lucio- now: student projects Martin C.Atkins
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).