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_id=1470&alloc_id=3638&op=click
> > --
> > _______________________________________________
> > Dri-users mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/dri-users
>
-------------------------------------------------------
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_id=1470&alloc_id=3638&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
