Re: [9fans] hardware acceleration

Re: [9fans] hardware acceleration

[William Staniewicz]

Just curious. What are you using to compose your
thesis if you don't have a working Plan 9 terminal? If you
did, I would presume you would use troff with
Acme or SAM.

		-Bill
. . . .
> Besides the VESA problems (which I really would like
> to see done, but I've a thesis to write and currently
> don't even have a working Plan 9 terminal) what else
> could be improved?  I'm always interested in ways to
. . . .
>
> Russ

Re: [9fans] hardware acceleration

[forsyth]

>>I used to wonder how
>>ls in UNIX could tell the input wasn't a tty and decide not to columnate
>>the listing, but once I realized it was doing something like isatty()
>>it didn't really offend me that it did. Sure, in a purist world it
>>would not columnate, but are we that anal? If the installer 'needs' a GUI

since the idea is that what i see from
	ls
should be a good guide to what grep sees in
	ls | grep '\.c'
then yes, that isatty is indeed a bad idea

Re: [9fans] hardware acceleration

[Douglas A. Gwyn]

George Michaelson wrote:
> ... I used to wonder how ls in UNIX could tell the input wasn't a tty
> and decide not to columnate the listing, ...

Actually that is still a sore point with many of us -- UNIX "ls"
did *not* automatically columnate its output if it was attached
to a tty; that was added in some version of BSD.  A difference in
a utility's operation based on what is sensed about the environment
is exactly opposite of the direction Plan 9 headed in.

I have to say, it would be a real pity to tailor Plan 9 very
much to accommodate the vagaries of the hodge-podge known as
the "PC architecture".  Video cards designed to support Quake
aren't the only approach to graphics, nor ultimately the best.
The more one ties fundamental aspects of a system to today's
commercial junk, the less its long-term influence on computing.

Re: [9fans] hardware acceleration

[nigel]

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

In support of this, it would seem that the access the vga chip
affords to memory through the bus is inversely proportional
to the speed at which it can bitblt itself.

In other words, the more the chip does for you, the less the
designers feel the need to put in decent bus access.

What really ought to limit it is the priority access the playout
has. So, it you want to speed up your vga i/o, perhaps turning
down the refresh rate is the answer. Somehow I doubt it.


[-- Attachment #2: Type: message/rfc822, Size: 1490 bytes --]

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: [9fans] hardware acceleration
Date: Tue, 13 Feb 2001 19:45:01 -0500
Message-ID: <20010214004507.48578199D5@mail.cse.psu.edu>

To address that, in 8bpp it's really not too much
of an issue, but for higher modes the system is mostly
unusable without scrolling and filling.  It's not
a question of the efficiency of the code (i.e., having
a JIT wouldn't help).  The problem is the readback speed
on the VGA card, which nails you when you're doing
software scrolling.  I can read from my 5400rpm disk
faster than I can read from my VGA memory.

Russ

Re: [9fans] hardware acceleration

[Russ Cox]

	Just curious. What are you using to compose your
	thesis if you don't have a working Plan 9 terminal? If you
	did, I would presume you would use troff with
	Acme or SAM.

I'm using troff, acme, and a staggering amount
of chewing gum and twine.  I'll have a working
Plan 9 terminal again in a couple hours, I hope.
Something in an experimental kernel did some bad
things to my kfs file system.  I can still read
it, just not boot from it.  (It's very odd.)
I'm setting up a cached fake worm file server
(using Eric's IDE patches) at the moment, so that
such damage will be easier to undo in the future.
I should have done this a long time ago.

Russ

Re: [9fans] hardware acceleration

[Russ Cox]

  Oh, getting a thesis is definately more important [no joke] but
  while you aren't... *why* didn't you want to turn off interrupts
  at that point? -Its an install process, its inherently single-user
  state, whats the risk?

Turning off interrupts in user space means you have to
trust the user program not to do anything bad, like page
fault or go into an infinite loop; there's no recourse
when it does.  I don't trust my program and the BIOS not to misbehave,
and it would be awful to debug when it did, since the system
would just hang or reboot.

  I've always assumed the linux direct to frame-buffer drivers and
  bindings onto them were the way to go. Last time I did a redhat
  (for work, never for home) it was 640x480x8 and 'just worked' -but
  was it pulling in a mini-X11 or was it doing frobs on framebuffer?

I think it pulls in a mini-X11 w/ Tk but I could be wrong.
That's the other thing -- if we had a software graphics
cursor we could at least run in some standard mode.

  Um, is it really that tightly coupled to a GUI? I didn't pick up
  on that. I'd assumed there were low level primitives to drive this
  totally from a kb->ASCII input method.

Yeah, it is.  The window system provides the delete => send interrupt
mapping.

  why can't rio handle a non-graphical stream? I used to wonder how
  ls in UNIX could tell the input wasn't a tty and decide not to columnate
  the listing, but once I realized it was doing something like isatty()
  it didn't really offend me that it did. Sure, in a purist world it
  would not columnate, but are we that anal?

Damn right we are.

  If you're thinking of delaying the switch, isn't is possible
  a bunch of stuff could be done in textmode like disk layout
  and write-to-disk such that when you do fail, whats left on-disk
  is closer to usable? or that a decision to go with a 2-floppy
  install would permit debug/fixit tools to be available?

The second edition install was done in CGA mode, with a custom
program that frobbed the CGA graphics memory.  People installed
the system only to find that they couldn't use it because they
only had text mode.  The rationale behind using a GUI was that
it was much easier to write the install process (it's a fairly
clean 1500 lines of shell script), and people had to run into
the VGA wall at some point so it might just as well be early.

It has the downside you point out, but for the most part I
think it has been a win.  I certainly appreciate being able to
draw new windows to look at what's going on when something
goes wrong (or to do other things entirely: I used to cpu out
and read mail while I ran test installs).

Next time I get my hands dirty I'll probably add an option
to run in text mode only, in the spirit of the diffs posted before,
for situations like yours.

My backup CD has finished writing, so I'm back to figuring
out how I broke my file system.

Russ

Re: [9fans] hardware acceleration

[George Michaelson]

  	because frankly, the install process is baroque.

  Besides the VESA problems (which I really would like
  to see done, but I've a thesis to write and currently
  don't even have a working Plan 9 terminal) what else
  could be improved?  I'm always interested in ways to
  make it better.  The hardware detection aspect
  is admittedly not as good as it could be, but that's
  a problem permeating the system rather than a shortcoming
  of the install process.  Are there other inadequacies
  that stand out?

No. the one killer is that you have to 'know' your own h/w intimately
to pre-tell the installer how to work. That the outputs appear to be
DOS editable files on a DOS readable floppy isn't well exposed in the
README or web: if the GUI is erally just fronting a script creation
and little or no binary at the backend changes, exposing this would
make it much simpler: tell people how to write the config and have one
image to maintain.

Other operating systems manage to do single-disk install in a couple
of ways: either by booting enough network state to download the rest
of the code needed, by cheating and being a 2.88Mb japanese floppy on
a CD, or by doing text only install, and having a kernel which is overloaded
with uncompressers, binary code melded into one mega-sh-on-steroids-with
all-the-_main_-as-procedures [see, I can't count, thats three] -What plan
9 install is doing isn't clear to me because its deciding to need gfx
very early on, and fails.

  	How about writing it to drive off the serial port, and bypassing the
  	screen altogether for some level of bootstrap?

  Others have done this (in text mode, which amounts to the
  same thing).  The problem is that it's not a particularly
  usable system -- without rio, there's no functional equivalent
  of job control or even an interrupt key, so the result is a
  bit tough to use.  But if you want to do it, the diffs
  are in the archives.

Its a bootstrap loop: I can't do diddly with the hardware I have
because I cant get beyond my card to install.

Um, is it really that tightly coupled to a GUI? I didn't pick up
on that. I'd assumed there were low level primitives to drive this
totally from a kb->ASCII input method.

why can't rio handle a non-graphical stream? I used to wonder how
ls in UNIX could tell the input wasn't a tty and decide not to columnate
the listing, but once I realized it was doing something like isatty()
it didn't really offend me that it did. Sure, in a purist world it
would not columnate, but are we that anal? If the installer 'needs' a GUI
then given the debate over the last few years, which side of the anal
debate is plan 9? My god! Sunos used to use pictures of VME disks and a
sliding graphic of the free space hog, pre-X11, they ditched it for text!

  I started to write a reply to the VESA discussion earlier
  this evening, in which I complained that VBE < 3.0 (by far
  the common case) needs a real-mode call to jumpstart it,
  and that would mean passing the info about graphics mode
  through the boot loaders.  There's no room for font data
  and graphics code in ld.com, and I'd rather keep it out of
  9load too.  While writing this it occurred to me that we
  can probably defer the switch from text to graphics mode,
  so I canned the reply.

If you're thinking of delaying the switch, isn't is possible
a bunch of stuff could be done in textmode like disk layout
and write-to-disk such that when you do fail, whats left on-disk
is closer to usable? or that a decision to go with a 2-floppy
install would permit debug/fixit tools to be available?

  Then again, if you want VBE 1.2, you need to do the graphics
  switch right away, and all the problems come back.  I did
  a google search for XFree86 startup dumps and found that
  there were a huge number of VBE 1.2 (non-VBE 2.0) cards still
  out there, so it seems reasonable to want to support them.

I've always assumed the linux direct to frame-buffer drivers and
bindings onto them were the way to go. Last time I did a redhat
(for work, never for home) it was 640x480x8 and 'just worked' -but
was it pulling in a mini-X11 or was it doing frobs on framebuffer?

  An approach that works even for VBE 1.2 is to
  simulate the BIOS code rather than run it directly.  The
  Alpha PC does this in firmware, I'm told.  I wrote
  a 3000-line real mode x86 emulator that seems to do a decent job,
  and it keeps the x86 creepiness contained.  The only
  problem is that the mode switch on my particular card
  makes some INT 15 calls to grub around PCI space, and
  simulating those in turn requires turning off interrupts,
  which I'd rather not do from user space.  Answering the
  INT15 calls directly is probably enough to get the mode
  switches working, but I haven't gotten back to it.

Oh, getting a thesis is definately more important [no joke] but
while you aren't... *why* didn't you want to turn off interrupts
at that point? -Its an install process, its inherently single-user
state, whats the risk?

Look, I'm an outsider. A classic whiner. I'm not going to write code,
you should de-rate my input by a minimum of 2 orders of magnitude to
anybody else. Its not impossible you could sink hours into VESA mode
and other people or me would still whine.

However, I don't have an Iron Bar, and I don't wear a flak jacket. So
telling me to shut up or go away has a very low downside risk.

cheers
	-George
--
George Michaelson         |  DSTC Pty Ltd
Email: ggm@dstc.edu.au    |  University of Qld 4072
Phone: +61 7 3365 4310    |  Australia
  Fax: +61 7 3365 4311    |  http://www.dstc.edu.au

Re: [9fans] hardware acceleration

[Russ Cox]

	because frankly, the install process is baroque.

Besides the VESA problems (which I really would like
to see done, but I've a thesis to write and currently
don't even have a working Plan 9 terminal) what else
could be improved?  I'm always interested in ways to
make it better.  The hardware detection aspect
is admittedly not as good as it could be, but that's
a problem permeating the system rather than a shortcoming
of the install process.  Are there other inadequacies
that stand out?

	How about writing it to drive off the serial port, and bypassing the
	screen altogether for some level of bootstrap?

Others have done this (in text mode, which amounts to the
same thing).  The problem is that it's not a particularly
usable system -- without rio, there's no functional equivalent
of job control or even an interrupt key, so the result is a
bit tough to use.  But if you want to do it, the diffs
are in the archives.

I started to write a reply to the VESA discussion earlier
this evening, in which I complained that VBE < 3.0 (by far
the common case) needs a real-mode call to jumpstart it,
and that would mean passing the info about graphics mode
through the boot loaders.  There's no room for font data
and graphics code in ld.com, and I'd rather keep it out of
9load too.  While writing this it occurred to me that we
can probably defer the switch from text to graphics mode,
so I canned the reply.

Then again, if you want VBE 1.2, you need to do the graphics
switch right away, and all the problems come back.  I did
a google search for XFree86 startup dumps and found that
there were a huge number of VBE 1.2 (non-VBE 2.0) cards still
out there, so it seems reasonable to want to support them.

An approach that works even for VBE 1.2 is to
simulate the BIOS code rather than run it directly.  The
Alpha PC does this in firmware, I'm told.  I wrote
a 3000-line real mode x86 emulator that seems to do a decent job,
and it keeps the x86 creepiness contained.  The only
problem is that the mode switch on my particular card
makes some INT 15 calls to grub around PCI space, and
simulating those in turn requires turning off interrupts,
which I'd rather not do from user space.  Answering the
INT15 calls directly is probably enough to get the mode
switches working, but I haven't gotten back to it.

g% 8.out
>> info
signature: VESA
version: 2.0
oem string: Diamond Mutlimedia. Savage4		[sic -rsc]
capabilities: 8-bit-dac
video modes:
	0109 010a 012e 010e 010f 0131 0133 0134 0141
	0143 0144 0151 0153 0154 0100 011d 011e 0101
	0111 0112 0171 0173 0174 017c 017e 017f 0102
	0103 0114 0115 0104 0105 0117 0118 0161 0163
	0164 0106 0107 011a 011b 0120 0122 0124 0191
	0193 0194 01a1 01a3 01a4 0136 0138 0139
total memory: 16777216
oem software rev: 1.1
vendor name: Diamond Multimedia Inc.
product name: Stealth III Savage4
product rev: Rev C
>> modeinfo 0x0139
mode attributes: supported color graphics linear
bytes per scan line: 7680
resolution: 1920x1440
charsize: 8x16
1 planes, 32 bpp, 1 banks @ 0 kb each
memory model 6 (direct)
r8g8b8x8 r@16 g@8 b@0 x@24
directcolor:
physptr: 0xE0000000
g%

Russ

Re: [9fans] hardware acceleration

[George Michaelson]

The relative importance of something like VESA isn't running it
permanently: its being able to use it to bootstrap.

Nigel offered to help me get a G400 working. I couldn't get his
mods into a floppy, and get it to work, not the least because the
boot/install floppy is already near max size, and because frankly,
the install process is baroque.

If I'd been able to use a VESA mode driver to get to a running state
however slow, slipping his mods in would have been trivial.

As a put-off to newbies, install is a big one. And if you discount
flamage about the relative merits of Paris to Pennsylvania a really
large number of Qs in the mail seem to be about making p9 work on
hardware that is both modern, easy to buy, and demonstrably working
(albiet from arcane and crude codehacks) for other s/w systems.

I do sympathise with people who have to cut this code saying that
its not a 100% solution, but the current one is way below 80:20 and
could (I suspect) with VESA be a lot closer.

If you look at the circumstances of a P9 newbie, its increasingly
unlikely they will have the hardware specs in the install page. So
this problem only gets worse.

How about writing it to drive off the serial port, and bypassing the
screen altogether for some level of bootstrap?

-George

[9fans] hardware acceleration

[Russ Cox]

To address that, in 8bpp it's really not too much
of an issue, but for higher modes the system is mostly
unusable without scrolling and filling.  It's not
a question of the efficiency of the code (i.e., having
a JIT wouldn't help).  The problem is the readback speed
on the VGA card, which nails you when you're doing
software scrolling.  I can read from my 5400rpm disk
faster than I can read from my VGA memory.

Russ