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 space. The order of events as Qt prepares to show the application is something like this: 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 driver. I really appreciate the work you guys have put into this driver. Keep up the good work. Thanks, Allen ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
