Evaluation of the PowerStorm 350 (and 4D51T)

Introduction

The following describes various "potential" bugs and experiences with the PowerStorm 350 drivers from Compaq. The tests are performed on an XP1000 (sometimes es40) running Tru64 version 4.0E (sometimes 4.0F). Comparisons are made between applications being developed inhouse and currently running on 4D51T cards in the same computer and TNT2 cards in PeeCee (Linux) machines.

Texture Performance

Just what performance improvement should I expect between the 4D51T and the PS350? From what I can tell for textured applications, there is very lttle difference (if any). While I have achieved significant improvements for glDrawPixels() calls, and, while I haven't timed it, I believe there are worthwhile improvements for raw geometry. However I don't seem to get much improvement for texture based models like the one shown below.

Frame rate on PowerStorm 4D51T ~ 21 frames per sec Frame rate on PowerStorm 350 ~ 22 rames per second

Frame rate on PowerStorm 4D51T ~ 8 frames per sec Frame rate on PowerStorm 350 ~ 8 frames per second

Note: I would put about a 1 or 2 frames per second variation on the above times. Both timings were performed in identially sized windows. All the textures are mipmapped and are typically around 64x64 to 256x256 in size. There are less than 5000 polygons in the whole model.
BTW: this is a model of our lab, the 64 machines on the right is our cluster.

/var/X11/Xserver.conf settings:

   -screen 1280x992 -I -riDefaultTexel32 -riFlipVSync

I would like to know why "-riDefaultTexel32" isn't the default! Almost all textures look bad if they get converted to 16 bit.

glEnable(GL_BLEND) and antialiasing

PowerStorm 4D51T

PowerStorm 350

Reply
Polygon anti-aliasing is typically performed with depth-sorted polygons (and depth-test disabled) and a blend function of (GL_SRC_ALPHA_SATURATE, GL_ONE) which requires a destination alpha buffer. (Destination alpha is not supported on PS350.) This method of polygon-aa is designed to avoid the artifacts you see in example1 at the seems of triangles. I expect that you'd see similar artifacts if you run example1 on other hardware that supports polygon antialiasing. I would try myself, but I surprisingly have *no* other boards at my disposal that support polygon-aa. 4D51T did not support polygon-aa at all, and so you just see the normal jaggies and no line through the quad. A program can check at run-time whether or not destination alpha is supported, and choose only to turn it on if alpha planes are present (ensuring attractive results).

FAR clipping plane weirdness

If the far cutting plane of gluPerspective() is set to a big number like 1e10, one has weird effects that look like a loss of depth testing. The parameter is supposed to be a double and certainly 1e10 isn't that big.

PowerStorm 4D51T

PowerStorm 350

Reply
1e10 =~ 2^33. This is slightly bigger than the 32-bit Z-buffer on the 4D51T, and *much* bigger than the 24-bit Z-buffer on the PS350. The size of the depth buffer can be queried at runtime, either via the GLX visual, or glGetIntegerv(GL_DEPTH_BITS, &dbits).
It turns out that the 4D51T used Z for the depth buffer while the PS350 uses W. W is linear through the depth buffer, Z is logarithmically bunched up toward the eye. Changing the depth buffer to Z using a undocumented/unsupported untested environment variable fixed the problem, the PS350 for the moment is stuck with a depth buffer based upon W and therefore linear!

glViewPort()

There is something "strange" with glViewPort() or a related function when setting smaller viewports within a large one, eg: I use this for capturing high resolution versions of an OpenGL scene, see the snippet of code below which should give the idea.

      glMatrixMode(GL_PROJECTION);
      glLoadIdentity();
      Set up the projection
      for (i=0;i<4;i++) {
         for (j=0;j<4;j++) {
            fprintf(stderr,"Frame (%d,%d)\n",i,j);
            Clear the left (and right) buffers
            glViewport(
               -i * camera.screenwidth , -j * camera.screenheight,
                4 * camera.screenwidth ,  4 * camera.screenheight);
            glMatrixMode(GL_MODELVIEW);
            glDrawBuffer(GL_BACK_LEFT);
            glLoadIdentity();
            gluLookAt(camera.vp.x,camera.vp.y,camera.vp.z,
                      camera.focus.x,camera.focus.y,camera.focus.z,
                      camera.vu.x,camera.vu.y,camera.vu.z);
            Create the scene geometry and lighting
            Do a glReadBuffer(); glReadPixels();
            The pieces are stitched together later
         }
      }

For example, the following two images show the result from the 4D51T and from the 350. In the code example (example3.c) the right mouse menu provides three image dumping options. My experience is as follows, all image dumping modes work as expected on the 4D51T at screen/window resolutions up to 1280x1024. On the 350 a window of 400x300 the default) works, but full screen (example -f) fails at 1280x992. The program creates 1, 4, or 16 ppm files, sorry but you'll have to stitch them together yourself. However as the images are being saved they are displayed on the screen and it is easy to see thimgs are not working right, it would be even clearer if a more interesting piece of geometry is added to MakeGeometry(). Seems like a viewport resolution matter, I don't know if there are supposed to be any restrictions?!

PowerStorm 4D51T

PowerStorm 350

Reply
Example3 is technically another non-bug. According to the blue-book reference: "Viewport width and height are silently clamped to a range that depends on the implementation. To query this range, call glGet with argument GL_MAX_VIEWPORT_DIMS."
With that said, I don't think there is a reason why our current limit (3840x2048) isn't greater than it is. In fact, in support of 8-head PanoramiX capabilities, I was looking at increasing these numbers anyway. If all goes well, I should have these cranked up to 15360x9600 in the next beta kit. This should allow you to zoom in to your heart's content. You didn't have this problem on 4D51T because it must have the viewport max cranked up (probably arbitrarily).
Yes, the 4D51T has a maximum viewport of 65536 x 65536.
Tested OK in Beta4c-15Jun00.

Emitter light

The stereo emitter stays on, this is a different behavour to the 4D51T where the emitter comes on only when one enters stereo mode. I don't know how this might affect the life of the emitter?!

Stereo pair movie player timings

The following timings are for glDrawPixels() calls. I'd be very interested in suggestions on how to get the highest glDrawPixels() performance, my stereo movie player is doing nothing else but writing 24 bit images to the left and right buffers using glDrawPixels().

            Mono     Stereo     Comments
4D51T       21.3      5.5        800x600 full screen
350         52.0     27.5        800x600 window      no   FlipVSync
350         22.1     11.0       1280x992 full screen no   FlipVSync
350         42.5     21.2        800x600 window      with FlipVSync
350         21.2     10.5       1280x992 full screen with FlipVSync

Playing digital movies in mono and stereo using my movie player with various compressors.

                                 no FlipVsync      with FlipVsync
                  4D51T          350                   350
               mono   stereo     mono              mono   stereo
 8 grey         17      4         36               28     14
 9 YCC          16      3         30               28     14
16 colour       16      4         31               28     10
24 colour       18      5         37               28     14

Projector details

Tested stereo resolutions on our 3 gun RGB projector, a NEC XG110LC with fast green phosphor installed.

Monitor Details

Tested stereo resolutions on a Compaq P110 21 inch monitor. As it turns out, this is identical to the NEC projector above.

QUAD strip bug

Incorrect rendering when using QUAD_STRIPs. The screen shots below show the strange behaviour on the PS350 and expected behaviour on the 4D51T. The exact polygons that get clipped (not drawn) varies as the view changes with respect to the stripes. Note, the bands of different green shades are due to the glColour() routines intentionally moved outside the inner j loop.

Here's the source for the plane.

   glNewList(1,GL_COMPILE);

   /* Ground plane */
   glNormal3f(0.0,1.0,0.0);
   for (i=-10;i<10;i++) {
      glColor3f(0.0,(i+10)/20.0,0.0);
      glBegin(GL_QUAD_STRIP);
      for (j=-10;j<=10;j++) {
         glVertex3f((float)i,0.0,(float)j);
         glVertex3f((float)i+1,0.0,(float)j);
      }
      glEnd();
   }

   glEndList();

State	PS350	4D51T
Wireframe glPolygonMode(GL_FRONT_AND_BACK,GL_LINE);
Shaded, no lights glPolygonMode(GL_FRONT_AND_BACK,GL_FILL); glDisable(GL_LIGHTING);
Shaded, lights glPolygonMode(GL_FRONT_AND_BACK,GL_FILL); glEnable(GL_LIGHTING);

Latest digital movie timings

The mono and stereo precomputed movie frame rates for the PS350 on Alphix are given below. These all relate to when the movie is cached, so this is an indication of the processing/memory/bus/card/update peak performance.

Mode               9 bit image        24 bit image
----------         -----------        ------------
non-stereo          34/35 fps           43/44 fps
    stereo          15/16 fps           19/20 fps

Things to note

• The stereo rates and pretty much half the non-stereo rates. This is an indication of well written drivers, it isn't the case for many stereo drivers/cards including the 4D51T.

• The difference in frame rates between the 9 and 24 bit images is because there is more processing going on the decode the 9 bit images. I don't quite understand yet why the stereo drop isn't greater than the non-stereo drop.

• I'm syncing to the vertical retrace (prevents tearing) so there is a limit to the non-stereo playback. It is synced to integer multiples of 0.01s (100Hz).

Determining stereo capabilities

While testing the drivers for Tru64V5, it was uncovered that the method of detecting stereo capability was faulty. I was using something like:

   glGetBooleanv(GL_STEREO,&ans);
   if (!stereo)
      glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB | GLUT_DEPTH);
   else
      glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB | GLUT_DEPTH | GLUT_STEREO);

This is not the right way! glGetBooleanv() doesn't make sense until a visual has been created.

PS350 and 4D51T

When polygons are clipped to the bottom and left border of the view frustum they result in a visible edge running up the clipped edge. This doesn't happen on a variety of other OpenGL boards/drivers, eg: TNT and GeForce in Linux machines. It DOES happen with the current drivers for the 4D51T and PS350.

No border

This only "looks" ugly when using a single window but it is a serious problem for multiwall displays where the walls need to meet perfectly.

This has been fixed in "PTR 93-5-183". Evaluation drivers have been installed locally and I've demonstrated the problem no longer occurs on both the PS350 and 4D51T.

4D51T

This rather serious bug would be easy to miss if one only ever dealt with projected images. It is more obvious if one uses buffer dumps for printing and is a disaster if one renders pieces to a larger viewport in order to create high resolution images or perform antialiasing.

	See the one pixel black line at the bottom these right buffer images. The line is actually in the clear colour....so the buffer can be written to.
	This may in fact be related to the last problem with an additional edge being added to wireframe objects, except that happens for both left and right eye buffers.

This does indeed seem to have been fixed along with the above patch.