Hi (José and Leif),
I'm testing the Mach64 driver on my laptop, which uses a Rage Mobility P/M
AGP 2x (rev 64). I'm using the binary snapshot from 2002/7/8.The
render/version string is:
Mesa DRI Mach64 20020227 [Rage Pro] AGP 2x x86/MMX/SSE 1.2 Mesa 4.0.3
You guys have done some really outstanding work on this driver. I almost
don't want to complain, but here goes.
I have a couple of problems with my own OpenGL application when using the
Mach64 driver (see http://lignumCAD.sf.net if you're interested). I've
distilled my problems down to a few simple examples (see
http://www.lignumcomputing.com/mach64/examples.tar.gz . You should be able to
just do a "make" to compile them. When running, press Esc to exit). You may
even be able to tell me what's going on without looking at the examples.
1. stipple.c: This program draws two vertical and two horizontal lines. The
second vertical and horizontal lines are drawn with GL_LINE_STIPPLE enabled.
Even though the end vertices of each pair of lines are the same, for some
values of the model view matrix, the stippled lines do not fall on top of the
solid lines. The initial value of the model view matrix translation in
stipple.c usually yields non-coincident lines. I have noticed, though, that
depending on where on the screen the window appears, the lines may or may not
be coincident. In any event, if you pan the view around using the arrow
keys, you can generally find some positions where they don't line up.
Perhaps this is just an effect of (the lack of) OpenGL invariance. With
software Mesa or LIBGL_ALWAYS_INDIRECT=1, they always line up. I also tried
the TDFX driver on a Voodoo 3500; this driver does not even seem to draw
non-stippled lines properly. (Maybe someone could try stipple.c or the
samples/line program in the Mesa distribution and let me know if the TDFX
driver works properly for them.)
2. clipping.c: In this program, a cube is drawn using a flat shaded quad
strip with different colors for each pair of vertices. If a face of the cube
is clipped by an edge of the X window, then the triangles which the quad is
decomposed into are not drawn in the correct color. You can rotate the cube
around with the left mouse button to see the effect on different faces. You
can zoom in and out with the middle mouse button. Once the cube is entirely
inside the window, it is drawn properly. I think this may be related to a
problem mentioned on Leif's status page. (It works OK with Mesa, with
indirect rendering and with the TDFX driver.)
3. texture.c: In my application, I originally had 2D textures specified with
an internal format of GL_RGBA. When I moved from my desktop machine, which
was running at 24 BPP, to the laptop, which is 16 BPP, I noticed a kind of
"posterization" effect on the textures, as though the color resolution was
substantially lower than specified. I tried using an internal format of
GL_RGBA8, but I still saw the same effect. However, using GL_RGB or GL_RGB8
yielded much smoother looking textures. This program demonstrates these
differences. I guess this is just the way it is, but again, they all look the
same with Mesa or indirect rendering. The TDFX driver, on the other hand,
shows the same effect as the Mach64 driver.
Additionally, on the Mach64, sometimes a texture will appear to have been
generated from an incorrect image. It looks as if one byte of the texture
image was not been properly transmitted to the graphics hardware. This could
easily be a problem with my machine, so I'd be interested if any body else
sees it. Which texture gets distorted is random; the distortion appears as a
blob of an obviously wrong color.
4. map.c: My main application uses Qt and its OpenGL widget. The OpenGL
widget is drawn inside of a Tabbed widget and you get to different views of
your model by clicking on the various tabs. When the program starts, the Qt
widget layout engine computes the size of the OpenGL widget in the Tab
window. As with most layout systems, the sizes of the laid-out widgets go
through several iterations before all the widgets are happy with their screen
The order of events as Qt prepares to show the application is something like
1. Create the OpenGL widget's parent window (the Tab widget) with some
default size; create the OpenGL widget's window (also with some default size).
2. Create the OpenGL context.
3. Map the parent window.
4. Bind the OpenGL context to the appropriate window.
5. Invoke the resize method of the OpenGL widget with the initial window size
(the resize method usually calls glViewport, etc.).
6. The layout engine massages the size of everything (ultimately using
XMoveResizeWindow to change the window sizes).
7. Map the OpenGL widget's window.
8. Enter the event loop: get ConfigureNotify events on all the windows; in
particular, this invokes the OpenGL widget's resize method again with the new
size of the window computed in step 6. Get Expose events on the OpenGL
widget's window, which invokes the drawing method.
The map.c program distills the Qt process down to a bare bones GLX
application. The program seems to show that there is a problem resizing a
window bound to an OpenGL context which has not been mapped. Rather than
seeing a grid which fills up the window, I usually see just a little bit of
the grid in the lower corner of the window; it is about the size of the
original (default) size of the OpenGL window. If you move the mapping of the
OpenGL's window to immediately after the parent's window mapping (i.e., move
step 7 to after step 3), everything seems to work OK. Mesa and indirect
rendering work without this change. The TDFX driver behaves like the Mach64
I really appreciate the work you guys have put into this driver. Keep up the