Questions about GLX and GL over network

Questions about GLX and GL over network

Post by Nathaniel Tag » Wed, 13 Nov 2002 23:40:58



Hi all.

Thanks to those who helped me eariler; I now have a system where I can
run a program (client) on a distant machine, and have the graphics show
up on my local X-server. This now works far better than trying to render
on the client-side and then blit the X-window (as was happening eariler).

Now I want to optimize.

It's quite clear from looking at the system that neither the client nor
the server is taking any time to create or render the scene; my
bottleneck is currently the network connection.

I'm rendering about 1000 - 2000 polys in a scene.  I'm using simple
lighting, alpha blending, and no textures.  I'm currently using no
vertex arrays or anything of the sort.

What can I do to speed this system up?

Thanks in advance,
----Nathaniel

--
Dr. Nathaniel Tagg - Postdoc, MINOS project - University of Oxford
         "The chances of a neutrino actually hitting something as it
travels through all this howling emptiness are roughly comparable to
that of dropping a ball bearing at random from a cruising 747 and
hitting, say, an egg sandwich."  -- Douglas Adams, (1952-2001)

 
 
 

Questions about GLX and GL over network

Post by watsacha » Thu, 14 Nov 2002 07:04:11



Quote:

> What can I do to speed this system up?

Compress on fly ? Implement a cache manager ?

 
 
 

Questions about GLX and GL over network

Post by Jon Lee » Thu, 14 Nov 2002 10:58:20




Quote:>Hi all.

>Thanks to those who helped me eariler; I now have a system where I can
>run a program (client) on a distant machine, and have the graphics show
>up on my local X-server. This now works far better than trying to render
>on the client-side and then blit the X-window (as was happening eariler).

>Now I want to optimize.

>It's quite clear from looking at the system that neither the client nor
>the server is taking any time to create or render the scene; my
>bottleneck is currently the network connection.

>I'm rendering about 1000 - 2000 polys in a scene.  I'm using simple
>lighting, alpha blending, and no textures.  I'm currently using no
>vertex arrays or anything of the sort.

>What can I do to speed this system up?

    Practically speaking:

  - Move fixed geometry into display lists, which are sent once to the
    server instead of every time you draw the object(s).
  - If you can't do that, at least make sure you're using triangle/quad
    strips instead of separate triangles/quads.
  - Get a faster and/or lower latency network connection between the
    machines.

    BOTE calculation: 2K polys/frame * 1 vertex/poly * 40 bytes/vertex
(coordinate, normal, color + GLX opcode overhead) is about 80
Kbytes/frame, or 640Kbits/frame. 10 Mbit ethernet would sustain at most
15 frames/second of such non-textured, vertex colored and lit,
stripified data, roughly speaking.

    Another possible option, if the app runs on a SGI IRIX machine, is
OpenGL Vizserver. This is an application-transparent way of rendering on
the machine the app is running on, compressing the result, and
transporting it to a remote display server. It makes sense in cases
where the compressed image size is small compared to the amount of
dynamic geometry and texture information the app would otherwise send
over the network.

    Jon Leech
    SGI

 
 
 

Questions about GLX and GL over network

Post by Nathaniel Tag » Thu, 14 Nov 2002 22:08:18



>     Practically speaking:

>   - Move fixed geometry into display lists, which are sent once to th
>     server instead of every time you draw the object(s).

Ok.. I'm a bit of a newbie.. what are 'display lists'?  Is this the same
as a vertex list buffer?

How does one create such a buffer so that overhead isn't high?  Do you
cycle through all your objects to create the buffer, then cyle through
again to draw them?  If so, doesn't that create some rather dramatic
overhead?

Quote:>   - If you can't do that, at least make sure you're using triangle/quad
>     strips instead of separate triangles/quads.

I'll look into this; my polys are actually simple rectangular prisms; I
haven't looked up quad strips yet.

Quote:>   - Get a faster and/or lower latency network connection between the
>     machines.

Of course. ;)

Quote:

>     BOTE calculation: 2K polys/frame * 1 vertex/poly * 40 bytes/vertex
> (coordinate, normal, color + GLX opcode overhead) is about 80
> Kbytes/frame, or 640Kbits/frame. 10 Mbit ethernet would sustain at most
> 15 frames/second of such non-textured, vertex colored and lit,
> stripified data, roughly speaking.

My calc: 50 prisms * 6 faces * 4 vertices * 40 bytes/vertex =
50kb/frame, which is roughly on the same order.

In contrast, I'm getting only a few frames a second, with the bandwidth
capping out at about 5 MB peak rate.

Quote:>     Another possible option, if the app runs on a SGI IRIX machine, is
> OpenGL Vizserver. This is an application-transparent way of rendering on
> the machine the app is running on, compressing the result, and
> transporting it to a remote display server. It makes sense in cases
> where the compressed image size is small compared to the amount of
> dynamic geometry and texture information the app would otherwise send
> over the network.

Although this may be the case for a specific site, I'm coding the
software as fairly platform-independent, and the local use case is Linux
client side, Windoze server side (yuck) so I can't go for anything
simple like just using the right equipment.. I have to make the wrong
equipment work faster.

Thanks for the tips.

---Nathaniel

--
Dr. Nathaniel Tagg - Postdoc, MINOS project - University of Oxford
         "The chances of a neutrino actually hitting something as it
travels through all this howling emptiness are roughly comparable to
that of dropping a ball bearing at random from a cruising 747 and
hitting, say, an egg sandwich."  -- Douglas Adams, (1952-2001)

 
 
 

Questions about GLX and GL over network

Post by Rolf Magnu » Fri, 15 Nov 2002 01:01:01




>>     Practically speaking:

>>   - Move fixed geometry into display lists, which are sent once to th
>>     server instead of every time you draw the object(s).

> Ok.. I'm a bit of a newbie.. what are 'display lists'?  Is this the
> same as a vertex list buffer?

No. A Display list just stores a list of OpenGL commands for later use.
Instead of glBegin()/glEnd(), you use glNewsList()/glEndList(). The
part in between can be replayed later with a glCallList(). The
important part is that the list only needs to be transfered to the
server once.

Quote:>>   - If you can't do that, at least make sure you're using
>>   triangle/quad
>>     strips instead of separate triangles/quads.

> I'll look into this; my polys are actually simple rectangular prisms;
> I haven't looked up quad strips yet.

Triangle/Quad strips reduce the number of vertices you have to transfer
by quite a big amount. For a triangle strip, instead of 3 vertices per
triangle, you only need 2 + (1 per triangle). I guess that this,
combined with display lists, will produce quite a big performance win
with networking.
 
 
 

Questions about GLX and GL over network

Post by Jon Lee » Fri, 15 Nov 2002 10:35:50




Quote:>Ok.. I'm a bit of a newbie.. what are 'display lists'?  Is this the same
>as a vertex list buffer?

    Rolf nailed that in his reply.

Quote:>My calc: 50 prisms * 6 faces * 4 vertices * 40 bytes/vertex =
>50kb/frame, which is roughly on the same order.

    If the prisms are all the same shape and color, and are just being
transformed individually (this is maybe a sci-viz app?), you could keep
a single prism in a display list and call the list repeatedly for each
object after setting up the right transformations, which could help a
good deal.

Quote:>In contrast, I'm getting only a few frames a second, with the bandwidth
>capping out at about 5 MB peak rate.

    Not actually all that horrid, for a 10 Mbit shared network.

    Jon Leech
    SGI

 
 
 

Questions about GLX and GL over network

Post by Nathaniel Tag » Fri, 15 Nov 2002 20:24:39



>>My calc: 50 prisms * 6 faces * 4 vertices * 40 bytes/vertex =
>>50kb/frame, which is roughly on the same order.

>     If the prisms are all the same shape and color, and are just being
> transformed individually (this is maybe a sci-viz app?), you could keep
> a single prism in a display list and call the list repeatedly for each
> object after setting up the right transformations, which could help a
> good deal.

It is indeed a sci-viz app, used to display neutrino interaction events
in the MINOS detectors:

http://www-pnp.physics.ox.ac.uk/~tagg/trid_screenshot.png

I do indeed plot very similar objects repeatedly, but currently I'm
drawing them all in absolute-coordiante space (which is how the analysis
framework works). So, a quad prism consists of a center coordinate,
three orientation vectors, and three half-lengths.  I use those
coordinates to generate 8 vertices that make the quad.

This could easily be changed into a simple cube that is instead
translated, rotated, and stretched... would this really help the speed?

Anyone know a good snippet or tutorial on triangle stips and/or display
lists?  (I haven't started hunting yet but I will.)

Thanks again for the help; I love a friendly newsgroup.

---Nathaniel

--
Dr. Nathaniel Tagg - Postdoc, MINOS project - University of Oxford
         "The chances of a neutrino actually hitting something as it
travels through all this howling emptiness are roughly comparable to
that of dropping a ball bearing at random from a cruising 747 and
hitting, say, an egg sandwich."  -- Douglas Adams, (1952-2001)

 
 
 

Questions about GLX and GL over network

Post by Jon Lee » Fri, 22 Nov 2002 08:19:44




Quote:>It is indeed a sci-viz app, used to display neutrino interaction events
>in the MINOS detectors:

>http://www-pnp.physics.ox.ac.uk/~tagg/trid_screenshot.png

    Nifty. Are you up and running yet?

Quote:>I do indeed plot very similar objects repeatedly, but currently I'm
>drawing them all in absolute-coordiante space (which is how the analysis
>framework works). So, a quad prism consists of a center coordinate,
>three orientation vectors, and three half-lengths.  I use those
>coordinates to generate 8 vertices that make the quad.

>This could easily be changed into a simple cube that is instead
>translated, rotated, and stretched... would this really help the speed?

    There would be considerably less network traffic - sending a single
LoadMatrix or the right sequence of glScale/Translate/Rotate commands,
followed by a CallList, should use maybe 10-20% of the bandwidth of
sending all the vertices, normals, and colors in immediate mode. So you
might get a considerable speedup in the likely event that you're
network-limited. Trying it is the only way to be sure.

    I suggest defining a list containing a cube centered around the
origin, then scale, rotate, and translate it in that order for ease of
modelling what's happening to the cube - also make sure that you restore
the transform matrix state after drawing each cube or you
won't get the desired results.

Quote:>Anyone know a good snippet or tutorial on triangle stips and/or display
>lists? (I haven't started hunting yet but I will.)

    The developer documentation area of www.opengl.org is a good place
to start. There are many other OpenGL developer sites on the web, some
of which are linked from opengl.org.

    Jon Leech
    SGI

 
 
 

Questions about GLX and GL over network

Post by Rolf Magnu » Fri, 22 Nov 2002 18:49:36



>     There would be considerably less network traffic - sending a
>     single
> LoadMatrix or the right sequence of glScale/Translate/Rotate commands,
> followed by a CallList, should use maybe 10-20% of the bandwidth of
> sending all the vertices, normals, and colors in immediate mode. So
> you might get a considerable speedup in the likely event that you're
> network-limited. Trying it is the only way to be sure.

Are you sure about this? I mean, for complex objects, I'm quite sure
that this is true, but also for something as simple as cubes?
 
 
 

Questions about GLX and GL over network

Post by Jon Lee » Sat, 23 Nov 2002 09:40:27





>>     There would be considerably less network traffic - sending a single
>> LoadMatrix or the right sequence of glScale/Translate/Rotate commands,
>> followed by a CallList, should use maybe 10-20% of the bandwidth of
>> sending all the vertices, normals, and colors in immediate mode. So
>> you might get a considerable speedup in the likely event that you're
>> network-limited. Trying it is the only way to be sure.

>Are you sure about this? I mean, for complex objects, I'm quite sure
>that this is true, but also for something as simple as cubes?

    Roughly speaking, the GLX protocol bandwidth needed is:

Immediate mode:

    4 bytes/call GLX overhead (approximately)
    per-vertex cost = v3f + n3f + c3ub
                    = (4 + 3*4) + (4 + 3*4) + (4 + 4)
                    = 40 bytes/vertex
    independent quads = 6 * 4 vertices = 24 verts. * 40 bytes/vert
                      = 960 bytes/cube
    quadstrip = 18 verts * 40 bytes/vert = 720 bytes/cube

    total = 720-960 bytes/cube

Display lists:

    PushMatrix = 4 bytes
    translate = (4 + 3*4) bytes
    rotate = (4 + 4*4) bytes
    scale = (4 + 3*4) bytes
    CallList = (4 + 4) bytes
    PopMatrix = 4 bytes

    total = 68 bytes/cube or ~10% of the immediate mode bandwidth

    Of course if the cubes were even slightly different, or had less
per-vertex data, the display list method might be less favorable or
unusable.

    Jon Leech
    SGI

 
 
 

1. :: Open Gl / Network question ::

HI.
        At University? we use Gl on a old IRIS (without support for
OpenGL).We have also  2 other Indigo,  not accessible for student, but we can
make remote login on it. My question is: do you thing we can use Open GL
remote and use the indigo to make the hardware stuff and use the IRIS only
like a Terminal ?  Any suggestion, let me know...

        Excuse my english , I am french and I don't have my dictionnaire

/////////////////////////////////////////////////////////////////
/ Hugo Villeneuve               Walking Machine SAE ETS         /

/ Departement de GPA            Universite du Quebec            /      
/////////////////////////////////////////////////////////////////

2. - just another SUNLIGHT question

3. Networking without GLX

4. ATI FireGL4 vs. NVIDIA Quadro4 900XGL

5. GLX across a network

6. Reopen last doc - action possible ?

7. GL/glut.h, GL/gl.h question...

8. Software development on SGI: GL or GLX?

9. IRIS GL -> GLX queries

10. X/GLX/GL and window/font/text

11. GL initialization in mixed GLX mode

12. GL vs. GLX