Re: [9fans] lucio- now: student projects

Re: [9fans] lucio- now: student projects

[Richard Miller]

> (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

Re: [9fans] lucio- now: student projects

[andrey mirtchovski]

> 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

Re: [9fans] lucio- now: student projects

[forsyth]

[-- 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

Re: [9fans] lucio- now: student projects

[forsyth]

>>	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.

Re: [9fans] lucio- now: student projects

[Martin C.Atkins]

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.

Re: [9fans] lucio-

[geoff]

It depends what you mean by ``bogs down the fileserver''.  Depending
on how many dirty blocks are in the mag disk cache, triggering a dump
to worm disks makes the file server completely unresponsive to
requests from the network for anywhere from a few seconds to a couple
of minutes while the copy-on-write fork of the file system is
performed.  Thereafter, it can take quite a while (depending on the
speed of worm writing) to complete the dump, but performance of the
file server is essentially unaffected.

So warning people in advance of a dump would give them time to take a
short break and get coffee or coke without feeling annoyed.  I have
occasionally wished for a more direct means of notifcation than mail,
perhaps the ability to write a short message after the time in a
vismon window or pop up an acme window containing a brief message.

Re: [9fans] lucio-

[Luis Fernandes]

>>>>> "geoff" == geoff  <geoff@collyer.net> writes:

    geoff> [...] I have occasionally wished for a more direct means
    geoff> of notifcation than mail, perhaps the ability to write a
    geoff> short message after the time in a vismon window or pop up
    geoff> an acme window containing a brief message.

Sounds like you need xmotd for Plan9. 

I will add it to the todo list and perhaps propose it as a student
project.

Re: [9fans] lucio- now: student projects

[Martin C.Atkins]

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.