On Mon, 8 Jul 2002, Brian Paul wrote: > Leif Delgass wrote: > > On Mon, 8 Jul 2002, Leif Delgass wrote: > > > > > >>On Mon, 8 Jul 2002, Brian Paul wrote: > >> > >>>The driver should assume the second case. swrast->Driver.SetReadBuffer() > >>>will get called for the first case, as needed. > >> > >>I missed this comment before. If we assume the second case, we'd change > >>the ReadBuffer (mmesa->readOffset in the driver) whenever > >>ctx->Driver.SetDrawBuffer() is called, right? And you're saying that > >>swrast->Driver.SetReadBuffer() will be called to change to the real > >>ReadBuffer for glReadPixels, right? Would Mesa then call > >>ctx->Driver.SetDrawBuffer() again to set the state back to ReadBuffer = > >>DrawBuffer for software rendering? > > > > > > I just tried making the driver set readOffset/Pitch = drawOffset/Pitch in > > SetDrawBuffer and it seems to work so far. If I put a glReadPixels into > > Graham's test program after the glDrawBuffer(GL_FRONT), the ReadBuffer is > > changed to GL_BACK before the ReadPixels and then changed back to GL_FRONT > > afterwards by Mesa! It looks to me like all the DRI drivers should be > > doing this. I understand why they don't, because it seems > > counter-intuitive. I'll have to do some more testing, but this just might > > solve the problem without any changes in Mesa. I think it's just a case > > of the hardware drivers not understanding Mesa's assumptions and > > behavior here. > > Wouldn't be the first time. :( > > I spent a little time on cleaning this up in Mesa 4.1 this morning and > have already found a much more elegant way of managing read/draw buffers. > For the purposes of software fallbacks the driver only needs to implement > one function to select the proper color buffer. I'll finish this up > tonight and check it in. > > Sorry for the headache.
No headache at all. I'm happy to squash a bug that's puzzled me from day one!! I was making the mistake of trusting the other drivers to be doing the right thing. ;) I only wish this had fixed the glean readback errors with blendFunc and logicOp, but the hunt continues for that. I've checked my fix of setting the readOffset/Pitch in the driver's SetDrawBuffer into the mach64 branch, but I think all the other drivers probably share this problem. Thanks for your help. -- Leif Delgass http://www.retinalburn.net ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
