I have completed all of the device-independent support (both client-side & server-side) for SGI_make_current_read. I wanted to update a couple drivers to support this extension before committing it. I was able to update the MGA driver without any problems. The Radeon (r100) driver is a totally different story.
To test things, I've been using a modified version of our favorite glxgears (patch attached) that uses two windows. The usual gears are rendered into one window, then the contents of that window are used as a texture for a single quad in the other window. The test can run properly when either SGI_make_read_current, GLX 1.3, or plain GLX 1.1 (i.e., no extensions) is supported. On the Radeon, this test fails even in GLX 1.1 mode.
In GLX 1.1 mode, the first window is empty (all black), but the second window, that uses the contents of the first as a texture, was drawn correctly. I tracked this down to a problem in radeonCopyBuffer (radeon_ioctl.c, line 807). Even though a __DRIdrawablePrivate is passed into this function, it uses the drawable stored in the current context. Note the uses of rmesa->dri.drawable. I investigated a bit further and discovered that the r200 & r128 drivers all have this problem.
I made the obvious fix to radeonCopyBuffer and tried again. There are now three different, probably unrelated problems.
1. When the first window is moved around, parts of its contents get left behind on other windows and on the desktop. Moving the second window around does not have this problem.
Off the top of my head... There's a macro to the effect of VALIDATE_DRAWABLE which needs to be called to ensure that the cliprect list for a drawable is up to date before rendering. I'd look in that area.
2. When a window partially obstructs the first window, the texture used for the second window is clipped. That is, the part of the texture that corresponds to the obscured part of the first window is black. I suspect this is just the nature of having a single back-buffer.
That's correct. The OpenGL spec says that the contents of the color/depth/stencil/etc buffers may be undefined when regions are obscured or off-screen.
3. When the test is run with both -twowindow and -ztrick, the texture used in the second window is always all black. For some reason, on my system, -ztrick does not work in indirect mode. If I change the drawing of the background polygon to use glColor3f & glVertex3f directly instead of a vertex list, it works. I have not investigated this yet. Using -ztrick by itself on the R100 works fine.
By "vertex list" do you mean display list? Perhaps some state isn't getting validated before the list is executing. Try putting a glFlush() before glCallList and see what happens.
I haven't tried any of this on an R200 yet, and I don't have access to a Rage128. I expect there's some state that isn't being properly updated when the drawable changes, but it's not obvious to me what it is.
BTW, I think I'd like to see glxgears restored to its original, unextended state. Then, exercise these extensions (and swap control, etc) in new variants of glxgears (like swaprate.c and/or readbuffer.c). I'm still not convinced the inttypes.h problem is solved and I'd like to keep glxgears simple/portable.
-Brian
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
