chromium-users — Mailing list for all users of the Chromuim rendering system

Re: [Chromium-users] running chromium

[Mike H. M. <mm...@pp...>]

I just began using Chromium today (CVS as of about 7:30ET), and had a few
notes on the installation "instructions". At PPPL, we're currently running
WireGL with Myrinet, so I thought I'd give Chromium a try... right now,
I'm still figuring things out, but to get GM support, I just noticed one
small change that had to be made.

3. cd $TOP

4. make 
        It gives:
        gm.c:822: warning: implicit declaration of function `ntohl'
        gm.c:825: warning: implicit declaration of function `ntohs'
5. Add #include <netinet/in.h> to gm.c
        (It's already in tcpip.c)
 
6. make
        Compiles just fine 

The numbers are just from my personal notes. Right now, Chromium appears
to work over TCP/IP, and I'm working on trying out GM. Just my $.02. 

--Mike Miller
mm...@pp...

Re: [Chromium-users] running chromium

[Greg H. <hu...@Gr...>]

On Fri, 22 Jun 2001, Peter Kirchner wrote:

> Have others noticed chromium's cvs progressing?  

I have, since I've been doing the updating :)

> Lately 20-30 files a
> day are being updated. I built chromium( cvs 6/18/01) on Linux, but I
> was unclear on how to run it or what the results should be.  I read the
> archives, looked at some of the code, and made a few lucky guesses.
> Here's what I remember:

This is a nice list of stuff you figured out!  Since we haven't done a
release yet, I haven't really documented any of the "how to use" things.

> 1)Python-2.0 is required in order to *build* (doh!) not just run.  

Yeah, Python 2.0 added the very handy feature that you could use the nice
"print" builtin to print to things *other* than standard output.  So
instead of writing:

	file.write( "my_string\n" )

you can just do:

	print >> file, "my_string"

Getting the newline for free, and making debugging output and file output
symmetric.  Also, 2.0 (finally) added increment statements (i += 1), which
are used all over the place.

> I changed cr/config/Linux.mk:
>     PYTHON=/usr/local/src/Python-2.0.1/python
>     LDFLAGS += -L/usr/X11R6/lib -L/usr/local/src/gm/binary/lib
>     CFLAGS += -DLINUX -Wall -Werror -I/usr/local/src/gm/binary/include
>     and the same for CXXFLAGS

Seems reasonable.  If your Python and GM aren't installed in the normal
places, you will have to do just that.

>     This said, I haven't actually verified gm operation.
>     The make completed without a hitch.

GM is currently untested, and I guarantee that it doesn't work.  Like I
said, we haven't done a release yet.  It's on my (very) short list.

> 2) some of the executables like to find their .so's in the current
> working directory.  Is it a win32 thing? A direct approach is to run
> crserver from cr/lib/linux .  For convenience,
>     cd cr/lib/Linux
>     ln -s ../../bin/Linux/* .
> to pick up the executables

win32 will pick .so's out of the PATH, so on Windows, the DLL's are copied
to the bin/WIN_NT directory.  On Linux, they're put somewhere else
(cr/lib/Linux), so you need to put that on your LD_LIBRARY_PATH.  For
finding SPU's, you can actually put those wherever you want since you can
specify the SPU dir (if it's not on the LD_LIBRARY_PATH) in the
configuration script.  However, it's still necessary to set up the
LD_LIBRARY_PATH correctly to run the server or the app faker.

> 4) Customize cr/mothership/server/mural.conf for your system.  At first
> glance it may be unclear what to change and what to leave alone.  Here
> are my suggestions for a first-time test.

All of this stuff will be documented fairly soon.  I'll also include a
number of other sample configuration files.  Many many configuration
scripts have been written in the process of adding the NVIDIA extensions
into Chromium (did that get anyone's attention?)

> clientnode.SetApplication(r'/usr/local/src/wiregl_1.2.1/bin/Linux/atlantis')

I'm glad to see that other people use atlantis to test things with too :)

> 5) start in sequence the mothership, the crserver, and the crappfaker
>     a) on CRMOTHERSHIP,
>             cd cr/mothership/server
>             python mural.conf
> There will ordinarily be no output on this xterm until step b:

This is correct.  Before I do the release I'll have the mothership print
out a reassuring message like "what you did was reasonable, I'm running
now" rather than "no news is good news"

>     b) on server0 (through n)
>             cd cr/lib/Linux
>             ./crserver

Eventually, these processes will be started by the mothership itself,
which is more than just a convenience, because if you start them manually
you have to make sure to start them in a reverse-topologically-sorted
order (why is left as an exercise to the reader).  If you do start them
manually, you can pass the "-mothership FOO" flag to the server or the app
faker (where FOO is the name of the mothership server) in case the
mothership doesn't happen to be running on 'localhost'.  Alternately, you
can set the CRMOTHERSHIP environment variable, although I tried VERY hard
to minimize environment variables.  You should need none to build, and
possibly only LD_LIBRARY_PATH to run.

>     c) on myappnode
>             cd cr/lib/Linux
>             ./crappfaker
> 
> There will be a bunch of debug messages from from this xterm and a
> continuing stream of messages on the crserver xterm.  'atlantis' will be
> showing/animating on server0 in the 'Chromium Render SPU" window (but if
> you obscure the GLUT Atlantis demo window on myappnode, the animation
> stops).

Yup, that's preetty much it.  Atlantis stops hogging the CPU if you
obscure its window -- there's not much I can do about that.

Again, we won't be doing an official release for another few weeks, but
I'm glad that you had some initial success!  I have managed to run some
applications on our display wall using Chromium, so things are coming
together.  I haven't added Vertex Arrays yet, so no Quake III.

-- 
Some people call me the space cowboy
Some call me the gangster of love
Some people call me ... HUMPER
hu...@gr...

[Chromium-users] running chromium

[Peter K. <kir...@at...>]

Have others noticed chromium's cvs progressing?  Lately 20-30 files a
day are being updated. I built chromium( cvs 6/18/01) on Linux, but I
was unclear on how to run it or what the results should be.  I read the
archives, looked at some of the code, and made a few lucky guesses.
Here's what I remember:

1)Python-2.0 is required in order to *build* (doh!) not just run.  I
changed cr/config/Linux.mk:
    PYTHON=/usr/local/src/Python-2.0.1/python
    LDFLAGS += -L/usr/X11R6/lib -L/usr/local/src/gm/binary/lib
    CFLAGS += -DLINUX -Wall -Werror -I/usr/local/src/gm/binary/include
    and the same for CXXFLAGS
    This said, I haven't actually verified gm operation.
    The make completed without a hitch.

2) some of the executables like to find their .so's in the current
working directory.  Is it a win32 thing? A direct approach is to run
crserver from cr/lib/linux .  For convenience,
    cd cr/lib/Linux
    ln -s ../../bin/Linux/* .
to pick up the executables

3) I set up my login to export the cr/lib/Linux dir in the
LD_LIBRARY_PATH and to export CRMOTHERSHIP set to the hostname that will
be running mothership (invoked by "python mural.conf").  I put my
python2 installation in my path before other pythons.

4) Customize cr/mothership/server/mural.conf for your system.  At first
glance it may be unclear what to change and what to leave alone.  Here
are my suggestions for a first-time test.

line 9-ish
    TILE_COLS=1
    TILE_ROWS=1
        # this is a single-server test...

line 22-ish
    SPUdir = '/usr/local/src/cr/lib/Linux'
        #again, we've linked the executables from this directory

line 24-ish
    clientnode = CRApplicationNode( 'myappnode')
        # at the risk of belaboring the obvious,
        #    replace myappnode with the hostname that will run your
application

line 27-ish

clientnode.SetApplication(r'/usr/local/src/wiregl_1.2.1/bin/Linux/atlantis')

        # Maybe the path isn't needed but it helps remove ambiguity.
        # Pick your favorite. For me the glut atlantis demo makes a
handy self-animating test.
        # btw the leading "r" leaves backslashes in, a nice thing for
windows folks,
        #      see http://www.python.org/doc/current/ref/strings.html

line 40-ish
    node=CRNetworkNode('server%d' % (row*TILE_COLS + col ))
        # note row and col start at zero... so 'server0' is the first
server hostname
        # perhaps just put in the hostname for the single server this
time around, i.e.
        # node=CRNetworkNode('server0');

5) start in sequence the mothership, the crserver, and the crappfaker
    a) on CRMOTHERSHIP,
            cd cr/mothership/server
            python mural.conf
There will ordinarily be no output on this xterm until step b:

    b) on server0 (through n)
            cd cr/lib/Linux
            ./crserver

There will be lots of verbose dialog displayed on this xterm and
mothership's if the connection is successful.  Some messages (e.g. "Got
a line: quit" and "Bye") are fine, they only sound dire.  crserver will
open a window (until there is something to draw you'll just see the
frame) on server0.

    c) on myappnode
            cd cr/lib/Linux
            ./crappfaker

There will be a bunch of debug messages from from this xterm and a
continuing stream of messages on the crserver xterm.  'atlantis' will be
showing/animating on server0 in the 'Chromium Render SPU" window (but if
you obscure the GLUT Atlantis demo window on myappnode, the animation
stops).


Pete