You don't have to copy from the back buffer to the front buffer until glFlush() or glFinish() are called. That's assuming that glReadBuffer(GL_FRONT); glReadPixels(...) grabs pixels from the back color buffer. If that's not true, you'd have to do the buffer copy before each glReadPixels().
-Brian
Felix Kühling wrote:
Hi Marcin,
Also CCing to Alex, he probably knows more about this.
Currently the driver looks like it's not supposed to render to the front buffer at all. When single buffering is used, the driver draws to the back buffer and copies it over to the front buffer after processing a Mesa vertex buffer. I have no idea if this is GL compliant. Anyway, it seems that frequent copying from the back buffer to the front buffer is a big performance problem.
Anyway, the reason is that accelerated 3D rendering only works with tiled memory but the front buffer is linear.
Software fallbacks draw to tiled surfaces, which map linear or tiled memory. If I understand it correctly it shouldn't make any difference whether the underlying memory is linear or tiled (as long as the tiled surface registers are setup correctly).
It seems that the front buffer surface uses a different line pitch than the back buffer. I don't know why that is. Alex, can this be changed easily or would it require big changes in the 2D driver?
Regards, Felix
On Tue, 23 Mar 2004 11:18:46 +0100 Marcin Krotkiewski <[EMAIL PROTECTED]> wrote:
Hi again,
I think this is a problem with software fallbacks drawn to the front buffer. It's definitely a driver bug. As a workaround try drawing to the back buffer and call glXSwapBuffers when you're done with a frame. The worst thing that would happen here is that the window remains black (or whatever your clear color is). ;-)
If you want to try to fix the bug take a look at savagespan.c in the 3D driver in the Mesa source code (src/mesa/drivers/dri/savage/savagespan.c).
I modified savagespan.c a bit. This line helped:
static void savageDDSetBuffer(GLcontext *ctx, GLframebuffer *buffer, GLuint bufferBit) { savageContextPtr imesa = SAVAGE_CONTEXT(ctx); char *map;
assert( (bufferBit == FRONT_LEFT_BIT) || (bufferBit == BACK_LEFT_BIT) );
map = (bufferBit == FRONT_LEFT_BIT) ? (char*)imesa->apertureBase[TARGET_FRONT] : (char*)imesa->apertureBase[TARGET_BACK]; + map = (char*)imesa->apertureBase[TARGET_BACK];
Though I do not think this is a solution, it might help you track down the bug... I'll let you know if I find anything else ;)
Cheers
Marcin
I'm not yet ready to start fixing bugs in the driver. There is at least one big chunk of work that I'm going to tackle in the next couple of weeks. Later on you could help improve the driver by sending bug reports with short OpenGL example programmes that demonstrate the problem. Usually this helps a lot in tracking down 3D driver bugs.
Cheers,
Marcin Krotkiewski
Regards, Felix
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
