here's a patch which mainly does 3 things:
- convert sis, mach64, and radeon to spantmp2.
The sis and mach64 drivers got a slight change, previously you could not read back alpha values (always 0xff) and I don't think there was a good reason for that?
IIRC, the mach64 doesn't support destination alpha planes. OpenGL requires that reads of absent alpha planes returns 1.0. I don't know if the SiS chip is the same.
The 3 intel drivers and the s3v are not converted due to their support of a RGB555 format spantmp2 can't handle (actually, the i810 does not support the 555 format in its span functions, the driver elsewhere has support for it, this probably can't be right). tdfx and ffb are not converted since they support a 888 format. gamma is not converted since it performs some unusual always-round-up tricks when using RGB565 format. trident is not converted since it doesn't support span functions yet at all :-).
- remove HW_CLIPLOOP, HW_ENDCLIPLOOP, CLIPPIXEL and CLIPSPAN macros out of the drivers whenever possible, since they are almost always identical. ffb uses very different macros, and some drivers do not use the driDrawable struct for HW_CLIPLOOP (which btw is interesting, I'm not quite sure why some drivers need to handle that differently, I didn't look too much into it but the difference is due to the handling of front and back buffers somehow), so they keep their own definitions hopefully.
There are probably more macro definitions which could be factored out.
- change CLIPSPAN to never return negative number of pixels (only change that once! not a dozen times, which is why I've done that macro definition removal in the first place...).
Does this look sane? Driver source code should get quite a bit smaller overall.
As long as you're looking at the span functions I should tell you that at some point in the future, work on the GL_EXT_framebuffer_object extension will likely require some changes in this area.
I'll elaborate on that in another email when I have things better sorted out. I'm doing initial implementation with the xlib renderer now.
But one thing that seems to be wrong in the r200 driver (for example) (and probably all the other DRI drivers) is the fact that the r200SetBuffer() function ignores its <colorBuffer> parameter.
As it is now, the function ignores that parameter and always assumes that the span functions are going to be reading/writing to the context's current drawing buffer.
The glXMakeContextCurrent and glXMakeCurrentReadSGI functions specify separate 'read' and 'draw' drawables. This allows you to do a glCopyPixels from one window to another, for example. This won't work if the colorBuffer parameter of r200SetBuffer() is ignored.
In general, the span functions are relying too much on the GLcontext state, and not enough on the GLframebuffer state. The pointer to the start of the color/depth/stencil buffer, its width, height, pitch, etc. should be obtained via the GLframebuffer passed to r200SetBuffer.
To do that, I guess GLframebuffer would need to have a pointer back to the corresponding __DRIDrawablePrivate, since we have no way to contain one in the other.
Anyway, I wouldn't change anything right now. Let's wait until the GL_EXT_framebuffer_objects stuff has firmed up.
-Brian
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
