Subject: Re: Good news: no more begging for HW

From: [email-masked] (Ariel Faigon)
Date: Mon, 16 Jun 1997 18:06:41 -0700 (PDT)

:
:Ariel,
:
:that's great news.  Just send all the hardware to me ;-)
:
:Jokes aside, I was thinking since some time if the FSF wouldn't be a
:great place to install some machines.  Another suggestion would be
:Thomas Bogendoerfer who already wrote a network driver for the Mips
:Magnum 4000 and others for Intel/Alpha.  I guess he might also be
:interested.
:
If you know interested people in the FSF (real names)
please have them email me with a short justification
why they want the machines and what will they use them for.
Same for Thomas.

I cannot promise anything since there may be some
oversubscription to the service :-)

I think the fairest way would be to publish all these
requests on this forum and have the people who care (us)
vote on who should get them.  I certainly don't want to
be the fascist person who decides who gets what.

-- 
Peace, Ariel

---

From: Alex deVries <[email-masked]>
Date: Mon, 16 Jun 1997 21:53:16 -0400 (EDT)

> be the fascist person who decides who gets what.

Well... I hate to be the first to jump in pleading for hardware, but I
could really use it. To date, the only SGI I have access to is
bogomips.ingenia.ca, which is Mike Shaver's machine in Ottawa. This is
difficult, as I can't do anything hardware related, or anything involving
rebooting, etc. Plus, bandwidth is a frequent problem.

I've always been interested in working with the application side of things
(particularly, porting all of RedHat 4.2), but I'd like to get involved in
other things, such as an X server and filesystem support.

Despite my email address, I actually reside in Boston.  I just administer
engsoc.carleton.ca in Ottawa remotely in my spare time (and quite
creatively, too, might I add). 

Oh, and my vote is on getting Ralf an SGI, if he doesn't have one already.
I'm not quite sure what the future is like for bogomips.ingenia.com.

- Alex

      Alex deVries           "Alex can cut a mean rug."
  System Administrator       - M. Dittberner <[email-masked]>
   The EngSoc Project

---

From: "David S. Miller" <[email-masked]>
Date: Mon, 16 Jun 1997 22:01:27 -0400

From: [email-masked] (Ariel Faigon)
   Date: Mon, 16 Jun 1997 18:06:41 -0700 (PDT)

   I cannot promise anything since there may be some oversubscription
   to the service :-)

   I think the fairest way would be to publish all these requests on
   this forum and have the people who care (us) vote on who should get
   them.  I certainly don't want to be the fascist person who decides
   who gets what.

Before this gets out of control, I just want to express one sentiment
of high caution.

Although it may seem desirable to contribute most of the donation
hardware to kernel level hackers, this can be a mistake in the making.
At this stage in the game it is just as important to get userland/libc
developers machines.

Therefore I suggest that at least one person who knows GNU libc,
binutils, _and_ gcc internals backwards and forwards be on the top of
the donation list.  If I were asked for such a candidate, I would
recommend Richard Henderson ([email-masked]) He has done the
Alpha/Linux port, he designed an ELF standard for 64-bit Alpha from
scratch with no existing standard available, he is doing the same
exact thing for 64-bit SparcLinux at the moment as well.

Not having a good libc/userland person in this port is why I lost half
my summer last year and was not able to hack the kernel as much as I
really would have liked to at all...

---------------------------------------------////
Yow! 11.26 MB/s remote host TCP bandwidth & ////
199 usec remote TCP latency over 100Mb/s   ////
ethernet.  Beat that!                     ////
-----------------------------------------////__________  o
David S. Miller, [email-masked] /_____________/ / // /_/ ><

---

From: [email-masked] (richard offer)
Date: Tue, 17 Jun 1997 09:23:12 -0700

* $ from [email-masked] at "16-Jun:10:01pm" | sed "1,$s/^/* /"
*
*
*    From: [email-masked] (Ariel Faigon)
*    Date: Mon, 16 Jun 1997 18:06:41 -0700 (PDT)
*
*    I cannot promise anything since there may be some oversubscription
*    to the service :-)
*
*    I think the fairest way would be to publish all these requests on
*    this forum and have the people who care (us) vote on who should get
*    them.  I certainly don't want to be the fascist person who decides
*    who gets what.
*
* Before this gets out of control, I just want to express one sentiment
* of high caution.
*
* Although it may seem desirable to contribute most of the donation
* hardware to kernel level hackers, this can be a mistake in the making.
* At this stage in the game it is just as important to get userland/libc
* developers machines.
*
* Therefore I suggest that at least one person who knows GNU libc,
* binutils, _and_ gcc internals backwards and forwards be on the top of
* the donation list.

We need an X server if we are ever going to get it usable by real users---or is
everyone assuming its for headles machines only. I would put an X server above
most applications in terms of priority (just below native gcc/libc).

Perhaps one ought to go to Xfree86/someone who knows our hardware (not to start
this thread all over again).

This should be very tighly focused, since an X server is a lot of work and we
need a lot of them, one per board (okay in version one we could only support
1280x1024x8, but that seems a waste of all our spiffy hardware).

I used to have a contact in Xfree86, but I haven't heard from him for a while.

If someone takes the server, I'll try and get the clients libraries done
(assuming that I can get remote access to a box).

richard.

____________________________________________________________________

A Guest Signature from Laurent Duperval <Laurent at Grafnetix.com>

  I don't understand why people break up and then get back together.
  It's like going to the fridge, taking a carton of milk that has
  gone bad, then saying: "I'll put it back and see if it's better
  tomorrow."

---

From: Miguel de Icaza <[email-masked]>
Date: Tue, 17 Jun 1997 12:10:12 -0500

> (assuming that I can get remote access to a box).

I was interested in working on the X server for the SGI.  I already
did that for the Linux/SPARC, and I had a couple of questions to make,
so this seems like a good time to ask them (please note that I haven't
actually traced my SGI X server to see what it does).

1. On the SPARC, the X server mmap()s the frame buffer into its
   address space and uses a couple of ioctls to talk with the kernel
   (to ask the kernel to change the palette and the hardware cursor,
   on later versions, with got rid of that, and we just poked at the
   frame buffer control registers from the X server).

   How does this work on the SGI?  Is the video card just a thing that
   can be mapped into the X server address space?  

   If this is the case, getting the X11R6 server to work will just take
   a couple of days of coding.

2. What kind of acceleration features are available on the SGI
   machines?  The X11R6 server has hooks for different set of
   features, so for example, bitblit can be easily hacked into the X
   server. 

   But I imagine the SGI has more acceleration features that I can
   dream of.

3. How does OpenGL work on the SGIs?  Is the OpenGL engine embedded in
   the X server, or it is something that is present on the video card?
   
   I looked yesterday at a program called glxinfo, which led me to
   believe that applications may have some of the GL code linked in
   trough the libraries and the other part resides on the X server.

   So, in this case, what are the specs for what needs to be on the X
   server to be able to run OpenGL applications.

4. Would it be possible for a free software company to redistribute
   the SGI's X server?  In that case, we could concentrate on getting
   the IRIX emulation as good as possible and just use the SGI X
   server and let Red Hat/Debian/GNU ship the cd with that binary.

Cheers,
Miguel.

---

From: Mike Shaver <[email-masked]>
Date: Tue, 17 Jun 1997 13:49:29 -0400 (EDT)

>    server and let Red Hat/Debian/GNU ship the cd with that binary.

FWIW, I'm quite interested in working on the IRIX emulation.
I picked up a bunch of stuff about the MIPS ABI at the SGI DevCon
(after arriving late for Ariel's talk =(), which also looks
interesting.

Mike

-- 
#> Mike Shaver ([email-masked]) Ingenia Communications Corporation 
#>                 UNIX medicine man -- dark magick, cheap!            
#>                                                                     
#>  When the going gets tough, the tough give cryptic error messages.  
#>          "We believe in rough consensus and running code."

---

From: [email-masked] (richard offer)
Date: Tue, 17 Jun 1997 10:53:12 -0700

* $ from [email-masked] at "17-Jun:12:10pm" | sed "1,$s/^/* /"
*
*
*
* > If someone takes the server, I'll try and get the clients libraries done
* > (assuming that I can get remote access to a box).
*
* I was interested in working on the X server for the SGI.  I already
* did that for the Linux/SPARC, and I had a couple of questions to make,
* so this seems like a good time to ask them (please note that I haven't
* actually traced my SGI X server to see what it does).

The questions are good, but I'm not the person who can answer them, me I'm a
Motif hacker, anything at a level lower than Xt is akin to assembler for me.

So with that in mind take the rest with a pinch of salt.

*
* 1. On the SPARC, the X server mmap()s the frame buffer into its
*    address space and uses a couple of ioctls to talk with the kernel
*    (to ask the kernel to change the palette and the hardware cursor,
*    on later versions, with got rid of that, and we just poked at the
*    frame buffer control registers from the X server).
*
*    How does this work on the SGI?  Is the video card just a thing that
*    can be mapped into the X server address space?
*
*    If this is the case, getting the X11R6 server to work will just take
*    a couple of days of coding.
*
*
* 2. What kind of acceleration features are available on the SGI
*    machines?  The X11R6 server has hooks for different set of
*    features, so for example, bitblit can be easily hacked into the X
*    server.
*
*    But I imagine the SGI has more acceleration features that I can
*    dream of.

The problem is that (I think) we have so many graphics cards that its done
differently in every one (some cards are simple frame buffers (8/24bit), then
there are some with multiple GE, oh and we also have extra visuals for overlay
and pop-ups.

The O2 has no graphics memory, everything is done in main memory.

*
*
* 3. How does OpenGL work on the SGIs?  Is the OpenGL engine embedded in
*    the X server, or it is something that is present on the video card?
*
*    I looked yesterday at a program called glxinfo, which led me to
*    believe that applications may have some of the GL code linked in
*    trough the libraries and the other part resides on the X server.

Both :-) We don't do things the way easy here.

The is a GLX extension in the X server which allows GL to run in an X window.

There is also I think a DSO that holds the hardware specific GL calls.

*
*    So, in this case, what are the specs for what needs to be on the X
*    server to be able to run OpenGL applications.
*
*
* 4. Would it be possible for a free software company to redistribute
*    the SGI's X server?  In that case, we could concentrate on getting
*    the IRIX emulation as good as possible and just use the SGI X
*    server and let Red Hat/Debian/GNU ship the cd with that binary.

This would be my preferred solution, but I've had many an argument on this
subject that I felt very dubious about bringing it up again.

To me the quickest (and the best) way of getting an X server would be if we
could simply port the existing Irix X server to Linux/SGI. My suggestion would
be, now that we have backing for hardware to get official backing for software.
I don't think we should neccesarrily release the source code for the ddx part
of the X server to the public, but we should at least be able to get backing to
release .o files so the user could re-link the X server if they needed to (Sun
have done this before).

*
*
* Cheers,
* Miguel.
*
*

richard

-----------------------------------------------------------------------
Richard M. Offer        Widget FAQ --> http://reality.sgi.com/widgetFAQ
MTS-Core Design (Motif)
___________________________________________http://reality.sgi.com/offer

---

From: Miguel de Icaza <[email-masked]>
Date: Tue, 17 Jun 1997 13:00:39 -0500

> there are some with multiple GE, oh and we also have extra visuals for overlay

What does "multiple GE" stand for?  

Supporting a wide variety of devices in X11R6 should be quite easy.
This X server also can support multiple visuals on a display, so this
should be easy to hack on as well.

> Both :-) We don't do things the way easy here.

So OpenGL applications can run without an X server, or they have code
to bypass the X server if they need to?

> There is also I think a DSO that holds the hardware specific GL calls.

Sorry, but what does DSO stand for?

> release .o files so the user could re-link the X server if they needed to (Sun

Ok.  This sound good enough.  

Miguel.

---

From: Martin Knoblauch <[email-masked]>
Date: Tue, 17 Jun 1997 20:30:36 +0200

> What does "multiple GE" stand for?

 GE == Geometry engine. The part of the OpenGL pipeline that
does the 3D transformations, lighting and other FPU intensive
stuff.

 Some of our GFX "card" do this stuff on the CPU (your Indy,
O2, some Indigo2), but most adaptors have separate GEs. In
all cases (except O2), you have no direct mapping from virtual
memory into the frame buffer.

> to bypass the X server if they need to?

 The apps use the Xserver to create the windows and do the
window and event managment. On fast, HW accellerated adapters,
they bypass the server when drawing. But they also can draw through
the server (as in the remote display case).

> Sorry, but what does DSO stand for?

 Dynamic Shared Object. Basically our term for Dynamic Shared
Library.

Martin
-- 
+---------------------------------+-----------------------------------+
|Martin Knoblauch                 | Silicon Graphics GmbH             |
|Manager Technical Marketing      | Am Hochacker 3 - Technopark       |
|Silicon Graphics Computer Systems| D-85630 Grasbrunn-Neukeferloh, FRG|
|---------------------------------| Phone: (+int) 89 46108-179 or -0  |
|http://reality.sgi.com/knobi     | Fax:   (+int) 89 46107-179        |
+---------------------------------+-----------------------------------+
|e-mail: <[email-masked]>   | VM: 6-333-8197 | M/S: IDE-3150    |
+---------------------------------------------------------------------+

---

From: "David S. Miller" <[email-masked]>
Date: Tue, 17 Jun 1997 14:45:53 -0400

Date: Tue, 17 Jun 1997 20:30:36 +0200
   From: Martin Knoblauch <[email-masked]>

How fast can these suckers assemble components along an interpolated
line?  Is it something like 1 component per clock at 300Mhz?

(some of you might know where that rate comes from, if you do,
 two points for you ;-)

Later,
David "Sparc" Miller
[email-masked]

---

From: [email-masked] (John Wiederhirn)
Date: Tue, 17 Jun 1997 17:00:11 -0700

> release .o files so the user could re-link the X server if they needed to
(Sun

While this appears to be an ideal solution on the surface, it has some obvious
and immediate problems as well.  Namely, the complete lack of the driver
infrastructure to support the device-dependant layer of the Xsgi server.

Given that it's unlikely we'd release the source code to our gfx drivers, there
is no easily viable way to produce the drivers in the linux kernel image.
 Lacking the drivers, Xsgi would need some _major_ redesigns, which brings us
back to Xfree-porting-level efforts needing to be expended.

There are some very serious issues which come up even getting Xfree to a
moderate level of acceleration.  By the time you've got all the pieces in
place, you are probably looking at the same device-independant ->
device-dependant -> gfx-device layering that Xsgi has in place.  OpenGL adds an
order of magnitude of complexity to the issue.

I realize this comes off as fairly negative, but I'm just trying to explain the
issues involved once gfx gets added to the mix.  There would need to be a
buy-in at a very high level of SGI mgmt. before we could start making the
hardware details of our graphics subsystems available (at least the more modern
ones, such as O2, Impact, etc.).

-- 
John Wiederhirn (DSD, Graphics Kernel MTS)        [email-masked]
       "Smithers, unleash the human insight and creativity."

---

From: [email-masked] (richard offer)
Date: Tue, 17 Jun 1997 17:15:52 -0700

* $ from jwiede@blammo at "17-Jun: 5:00pm" | sed "1,$s/^/* /"
*
*
* I realize this comes off as fairly negative, but I'm just trying to explain
the
* issues involved once gfx gets added to the mix.  There would need to be a
* buy-in at a very high level of SGI mgmt. before we could start making the
* hardware details of our graphics subsystems available (at least the more
modern
* ones, such as O2, Impact, etc.).

I don't think this is being negitive, it might not be what we want to hear, but
at least someone who knows about our underlying hardware is making comments.

Probably the first thing to do would be to get the go ahead for a proof of
concept only (under NDA) probably using an old indy. If this proves impossible
from either the technical or political pov's then we need to re-think.

I personaly don't think we have much chance unless we go to NDA and even then
its going to be really hard to get buy-in.

*
*
* --
* John Wiederhirn (DSD, Graphics Kernel MTS)        [email-masked]
*        "Smithers, unleash the human insight and creativity."
*

richard.

________________________________________________________________________

  Dogbert:    "From now on I will not try to reason with the idiots I 
              encounter. I will dismiss them by waving my paw and saying 
              'BAH'".

  Dilbert:    "Just because someone thinks differently from you doesn't 
              mean he's an idiot, Dogbert".

  Dogbert:    [waves paw], "BAH".

                                                   Dilbert: 27-July-96.

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 18 Jun 1997 02:32:00 +0200 (MET DST)

> its going to be really hard to get buy-in.

I guess a workable model for the current technology like O2 etc. would be
that SGI gives documentation out under NDA to the developer(s).  After
a certain time (I think about 18 month or two years) after which a product
generation is obsoleted by successors the source and hopefully even the
documentation may be published freely.

  Ralf

---

From: [email-masked] (Ariel Faigon)
Date: Tue, 17 Jun 1997 17:34:24 -0700 (PDT)

[note the change in subject]

First a note to all SGI linux subscribers:
There are about 10 interested parties external to SGI
on this list.  I just say this so you're all aware of it.

:
:Given that it's unlikely we'd release the source code to our gfx drivers,
:
Well, after getting some hardware, that's our next hurdle :-)

I believe it would be a very good idea to release the Indy low-level
graphics source (even under NDA, although personally, I wouldn't
use NDAs) to XFree developers.  I'm not even talking amazing 3D or
Octane stuff here.  Let's first get basic X11 running on Indys
then worry about OpenGL / O2s etc.

Note that this means getting the basic 2D stuff running.  Heck, I can't
understand the logic of anyone being so protective about 5 year
technology, it is available on every PC with mid-range level graphics
by now.

:
:I realize this comes off as fairly negative, but I'm just trying to explain the
:issues involved once gfx gets added to the mix.  There would need to be a
:buy-in at a very high level of SGI mgmt. before we could start making the
:hardware details of our graphics subsystems available (at least the more modern
:ones, such as O2, Impact, etc.).
:
John, lest I sound negative, I don't mean to.  I hope all the
people on this list can agree on such obvious things.  I hope
that that fuzzy cloud called "upper level management" will
somehow transform into a person I can talk to.  My experience
is that once you get to the right upper level person, and
you state your case sensibly, you get what you want.

If anyone on the list knows the people to talk to to get this
happen please share.

P.S:
It is interesting to note how the SPARC port happened despite Sun
never releasing low-level stuff (as if they had anything to lose
by that) and David's reverse engineering all their stuff.  SGI
has nothing to lose and everything to gain from cooperation with
the hacker's community.  Linux is running on Alpha and SPARC
by now.  We don't want to see Linux running on HP and IBM
before it does on our iron, do we ?

-- 
Peace, Ariel

---

From: Miguel de Icaza <[email-masked]>
Date: Tue, 17 Jun 1997 21:47:58 -0500

> infrastructure to support the device-dependant layer of the Xsgi server.

I personally would like to provide the same interface to the userland
independently of what X server we end up using (the IRIX X server or
the ported X11R6 server).  

And from the rest of your mail, it seems like the easier approach will
be to run the stock IRIX Xsgi server on Linux. 

I have been doing my homework, and have a list of device drivers that
are used by the X server.  Most of the devices are trivial to code
(keyboard, mouse, input, semaphore drver), some are more interesting (the shmiq will be
an interesting driver, since it seems the only user of this driver is
the X server, and it is nowhere documented in the man pages) and
finally the hard device driver to write is the /dev/opengl driver.

Some of the ioctls that are performed on the opengl should be trivial
to implemnt. 

There is particularly one interesting ioctl: the GFX_ATTACH_BOARD
which appears to take a (struct gfx_attach_board_args *).  This
structure is:

struct gfx_attach_board_args {
        unsigned int board;
        void        *vaddr;     /* this is a user space address */
};

On my machine, the ioctl on /dev/opengl is being called with vaddr set
to 0x02000000.  I wonder what exactly is being done at this address
space?    I know it does not do any mmap on this address (my test
program showed me this).  Probably I need to have allocated this
memory before hand?

Anyways, just after the X server calls this ioctl, it start calling a
bunch of ioctl, for which I could not figure out much:

0x530c, 0x520f, 0x520e, 0x5401, 0x5302, 0x5303,
0x5208, 0x5308, 0x5208, 0x5203, 0x5401, 0x5203

There are no ioctls in /usr/include that would make any sense for
these.  No IO*_ 'S' nor 'T' are documented there.

Put personally, I do not believe codign the /dev/opengl device will be
very hard either.  

Now, back to disassembling /unix opengl_ioctl and try to figure out
those ioctls :-)

Cheers,
Miguel.

---

From: "William J. Earl" <[email-masked]>
Date: Wed, 18 Jun 1997 05:38:42 -0700

> > subject that I felt very dubious about bringing it up again.
...
     I talked with David Miller about this area last year.  I suspect that
one can run any of the cards with the firmware loaded by the PROM, in "dumb"
mode.  One would basically render by hand, or with very limited acceleration
and just DMA the data into the frame buffer (since the frame buffer is generally
not memory-mapped).  The result would not be really fast, but it would be functional.
I am travelling today, but I will check tomorrow.

---

From: "Christopher W. Carlson" <[email-masked]>
Date: Wed, 18 Jun 1997 09:28:41 -0700

On Jun 17,  5:34pm, Ariel Faigon wrote:
>-- End of excerpt from Ariel Faigon

I agree.  I'm not sure, but how much are we really giving away if we
provide some of our software to the linux community?  Imagine the
proliferation of OpenGL software that would be generated and the
number of computers we would sell if Joe Shmoe could buy an O2 with
Linux and OpenGL support?  SGI is a hardware company!  It surprises me
that much of our company has forgotten that.

-- 

		Chris Carlson

	+------------------------------------------------------+
	| Also, [email-masked]                                |
	|   Work:   (714) 224-4530                             |
	|   Vnet:       6-678-4530     FAX:    (714) 833-9503  |
	|                                                      |
	| Trivia fact: an electroencephalogram shows that a    |
	| human brain and a bowl of quivering lime Jell-O have |
	| the same waves.  [Time Magazine, Mar 17, 1997]       |
	+------------------------------------------------------+

---

From: Nigel Gamble <[email-masked]>
Date: Wed, 18 Jun 1997 12:30:33 -0700 (PDT)

On Wed, 18 Jun 1997, Christopher W. Carlson wrote:
>                            SGI is a hardware company!  It surprises me

If it was ever true, it's certainly not true any longer.  SGI is
a systems company.  By which I mean that our "edge" over the
competition comes from a combination of hardware and software
working very closely together.

Nigel Gamble       "Are we going to push the edge of the envelope, Brain?"
Silicon Graphics   "No, Pinky, but we may get to the sticky part."
[email-masked]
(415) 933-3109

---

From: "William J. Earl" <[email-masked]>
Date: Thu, 19 Jun 1997 12:23:50 -0700

...

    O2 is actually simpler.  We would have to document how to set up
the display engine (which copies the frame buffer to the screen), but,
since O2 is UMA, a purely software X rendering engine will work just
fine.  I doubt there will be much concern about X, and the software
OpenGL reference implementation is widely available.  I believe that
most internal concerns are about the optimized hardware-dependent GL
implementations, where software advances are a competitive issue.
(For example, we just released an updated set of GL libraries for O2
which increased performance by 30% on the same hardware.)  In that
case, since the graphics pipeline is conceptually the same on all our
platforms, the optimized algorithms do not become obsolete, just
because a particular product is obsolete.

    I expect that there is room for a reasonable compromise here, without
having to get into the complications of NDAs and the like, given that
the initial goal, at least, is to get a simple X port done.