-----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.
At that point, you can forget about the swrast module entirely. If your hardware is doing all the rasterization, you won't be concered with span reads/write or the SetBuffer function at all.
BUT, you WILL still be concerned with the ctx->Driver.DrawBuffer() and ctx->Driver.ReadBuffer() functions since those will control the target and source color buffers for hardware rendering.
Typically, the hardware driver will still need the swrast module for rendering things that the hardware doesn't support (maybe like smoothed, stippled polygons).
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.
The SetBuffer function is relatively new. The mechanism was actually more complicated a while back.
-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/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
