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. -Brian ------------------------------------------------------- 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
