--- Leif Delgass <[EMAIL PROTECTED]> wrote: > On Sun, 7 Jul 2002, Brian Paul wrote: > > > The notion of 'current read buffer' is more complicated than one would > > first expect. There are basically two situations in which you need to > > read from a color buffer: > > > > 1. glRead/CopyPixels() and glAccum() > > 2. blending/logicops/masking > > > > In the first case, the source buffer is whatever glReadBuffer() indicates. > > Furthermore, the source for the pixels may be a completely different > window. > > The glXMakeContextCurrent() and glXMakeCurrentRead() functions let you > > specify different drawables (windows) for reading and writing pixels. > That's > > why Mesa's swrast->Driver.SetReadBuffer() takes a GLframebuffer argument. > > > > In the second case, the source buffer is what glDrawBuffer() indicates. > > Mesa considers the second case to be the more common and usually keeps > > the "default read buffer" = "default draw buffer". > > > > So the basic idea is to read spans from whatever the > ctx->Driver.SetDrawBuffer() > > call indicates, until overridden by swrast->Driver.SetReadBuffer(). > > The problem is that the read buffer for these two cases can be different > at a given state, but swrast->Driver.ReadRGBASpan() and friends always > read from the buffer set by swrast->Driver.SetReadBuffer() (unless > SetReadBuffer hasn't been called, in which case the default read buffer is > GL_BACK_LEFT for a double-buffered visual and GL_FRONT_LEFT for a single > buffer visual). This is because the hardware driver doesn't know if these > functions are called by Mesa for the first or second case you mention. > > In Graham's test progam, the visual is double-buffered, so the read buffer > is set by the driver to the back buffer initially. Then > glDrawBuffer(GL_FRONT) is called before the logic ops, but the read buffer > remains GL_BACK. With this state, glReadPixels should read from GL_BACK, > but Mesa software blending/logicops should read from GL_FRONT (the > DrawBuffer). However, looking at s_logic.c, Mesa uses the driver's > ReadRGBASpan/Pixels functions, which can't handle this discrepency. What > I'm saying is that Mesa would have to explicitly call > swrast->Driver.SetReadBuffer() to "fool" the driver to read from the draw > buffer (the "default read buffer" = "default draw buffer" state you > mentioned for the Mesa swrast functions). This problem probably hasn't > been noticed in other drivers because they use fewer software fallbacks > than mach64, and drawing on the back buffer is the common case.
Heres a random thought. Assuming that 1. Mesa indirect, pure software is all fine which it seems to be, it can still present double-buffering, and presumably gets the correct read buffer. 2. The problem then lies in the less tested path of hooking into the hw driver specific part (esp with a card with heavy software fallback?). In which case its more in the Mesa part. Or theres an assumption which doesn't hold true on the mach64 requiring some workaround. Which is what I think Leif is saying. Then wouldn't trying the same thing on a different DRI driver show a) the same problem - indicating the Mesa part or b) work fine - indicating something wrong in mach64? I'm thinking of maybe the new s3 virge driver. It supports double buffering, and its a simple enough test program not to trip it up. Its surely bound to be a good candidate for software fallbacks. I have one of those in my trusty K6 266 system: VGA compatible controller: S3 Inc. ViRGE/GX2 (rev 04) (prog-if 00 VGA]) Subsystem: Diamond Multimedia Systems Stealth 3D 4000 I just tried getting DRI up and running on it using recent snapshots, but its complaining about unresolved symbols s3v_agp_* which is a bummer, Its not supposed to use AGP so not sure why it wants that - probably my config. I use it as a router, so I'm not too worried but I'd have liked to have seen what it did in this case. Maybe its worth trying the same thing on one of these if someone has it working? Don't have time for a make World effort right now, sadly. cheers, Graham ps - Brian, I think Mesa is wonderful - big thank you. > So it looks to me like there isn't anything I can do to fix this problem > from the hardware driver end. Am I missing something or is this really a > Mesa bug? > > -- > Leif Delgass > http://www.retinalburn.net > > __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com ------------------------------------------------------- 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
