> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Ian Romanick > Sent: Friday, August 01, 2003 8:09 PM > To: DRI developer's list > Subject: Re: [Dri-devel] SGI_make_current_read is in CVS > > > Ian Romanick wrote: > > > As I mentioned in a couple earlier threads, there are some problems with > > enabling this extension in a couple different drivers. Because of that > > I have not committed any device-dependent code. Attached to this > > message are the patches to the Radeon and MGA drivers to enable > > SGI_make_current_read. I expect similar patches will be needed for the > > other drivers. The MGA patch seems okay, but I have not had a chance to > > test it much. The Radeon patch has several problems with both > > xdemos/wincopy from Mesa and my patched glxgears (see the previous > > thread for that patch). > > I took a quick at this problem again last night. I'm a bit confused by > spantmp.h and how it interacts with Mesa. The generated functions get > used, for example, by _mesa_read_rgba_span. This function gets used in > all the expected places: CopyTexImage, ReadPixels, etc. However, it > also gets used by _mesa_blend_span and a few other places that use the > ctx->DrawBuffer. > > The problem is that the information about which buffer is needed (i.e., > read or draw) is NOT passed into swrast->Driver.ReadRGBASpan. How does > even the software rasterizer work correctly? Won't there be problems > with alpha blending if the read-drawable is set to something different > from the draw-drawable?
I had this very same thought in my mind, and was told by you and Brian on the Mesa list that the driver maintains it's own "current buffer" for use with the software rasterizer. Before Mesa calls one of these functions, it checks to see if the target buffer is different to the current buffer (although quite how is beyond me, it DOES), then calls swdd->SetBuffer() with the new one. The software rasterizer (or your driver, or whatever) takes this and uses it as the target buffer for the next round of functions, and therefore never has to know which buffer it's *actually* writing to. Thus, we get around having to pass through a buffer every time. Since all of the functions which use this method are usually offshoots of the swrast driver and templates, it makes sense, until you replace it with a fully hardware system, at which point it becomes confusing, I think. Is that what you mean, or..? I definitely thought EXACTLY that last paragraph while I was coding it the "wrong" way, but instantly thought what an idiot I was when the SetBuffer() method came out being smaller shorter simpler more readable and easier to debug. So.. was I right to be that idiot after all? :/ -- Matt Sealey <[EMAIL PROTECTED]> ------------------------------------------------------- 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/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
