Re: [Dri-devel] Re: [Dri-users] Problems with savage and DRI
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
Re: [Dri-devel] Re: [Dri-users] Problems with savage and DRI
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. No, it's not. Keith --- 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
Re: [Dri-devel] Re: [Dri-users] Problems with savage and DRI
Brian Paul wrote: 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(). Thats a reasonable optimization, but the basic technique is flawed -- it's probably possible to get the correct behaviour of a single-buffered visual in this way, but it's not going to be compliant at all for a double-buffered visual where the app is switching between drawing to the front & back buffers. Keith --- 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
Re: [Dri-devel] Re: [Dri-users] Problems with savage and DRI
Keith Whitwell wrote: Brian Paul wrote: 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(). Thats a reasonable optimization, but the basic technique is flawed -- it's probably possible to get the correct behaviour of a single-buffered visual in this way, but it's not going to be compliant at all for a double-buffered visual where the app is switching between drawing to the front & back buffers. Right. I thought we were just talking about the single-buffer scenario though. -Brian --- 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
Re: [Dri-devel] Re: [Dri-users] Problems with savage and DRI
On Tue, 23 Mar 2004 08:16:49 -0800 (PST) Alex Deucher <[EMAIL PROTECTED]> wrote: > > --- Felix K_hling <[EMAIL PROTECTED]> wrote: [snip] > > 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). > > That's my understanding as well, but I could be wrong. Also, tiling > the front buffer results in lower performance. I'm not sure why. It > might have just been due to the way the code was initially architected. > your changes to the 3d driver may have fixed that. Don't know which changes that would be. The only thing where the tiling of the front buffer would make a difference for normal double buffered rendering is on buffer swaps. The swapping didn't change. So possibly blitting to a linear frame buffer is faster than blitting to a tiled one. Anyway, from Keith's comments about double-buffered visuals where the app switches between rendering to front and back buffer, it sounds like we really want to have a tiled front buffer. > > > > > 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? > > The pitch is different because of alignment requirements. I think I > tried changing the front pitch to match the others and it didn't seem > to break anything as I recall, so perhaps we can get away with it. If it really needs a different pitch it shouldn't be too hard to adjust savagespan.c. > Unfortunately, tiling of the front buffer broke when I ported S3's > changes to Tim's code. I'm not sure what the problem is as the set up > is pretty much identical. I never really dug into it too much since > linear seemed to work fine for most things. However, back when we were > using S3's driver and tiling worked, drawing to the front buffer was > still broken (looked the same whether the front buffer was tiled or > not). > > Alex > [snip] --- 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
Re: [Dri-devel] Re: [Dri-users] Problems with savage and DRI
--- Felix Kühling <[EMAIL PROTECTED]> wrote: > On Tue, 23 Mar 2004 08:16:49 -0800 (PST) > Alex Deucher <[EMAIL PROTECTED]> wrote: > > > > > --- Felix K_hling <[EMAIL PROTECTED]> wrote: > [snip] > > > 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). > > > > That's my understanding as well, but I could be wrong. Also, > tiling > > the front buffer results in lower performance. I'm not sure why. > It > > might have just been due to the way the code was initially > architected. > > your changes to the 3d driver may have fixed that. > > Don't know which changes that would be. The only thing where the > tiling > of the front buffer would make a difference for normal double > buffered > rendering is on buffer swaps. The swapping didn't change. So possibly > blitting to a linear frame buffer is faster than blitting to a tiled > one. Anyway, from Keith's comments about double-buffered visuals > where > the app switches between rendering to front and back buffer, it > sounds > like we really want to have a tiled front buffer. I'll try and get tiling working again. > > > > > > > > > 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? > > > > The pitch is different because of alignment requirements. I think I > > tried changing the front pitch to match the others and it didn't > seem > > to break anything as I recall, so perhaps we can get away with it. > > If it really needs a different pitch it shouldn't be too hard to > adjust > savagespan.c. it should only have a different pitch if you are using linear vs. tiled for the front buffer. With a tiled front buffer the pitch should be the same. > > > Unfortunately, tiling of the front buffer broke when I ported S3's > > changes to Tim's code. I'm not sure what the problem is as the set > up > > is pretty much identical. I never really dug into it too much > since > > linear seemed to work fine for most things. However, back when we > were > > using S3's driver and tiling worked, drawing to the front buffer > was > > still broken (looked the same whether the front buffer was tiled or > > not). > > > > Alex > > > [snip] __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html --- 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
Re: [Dri-devel] Re: [Dri-users] Problems with savage and DRI
--- Felix Kühling <[EMAIL PROTECTED]> wrote: > On Tue, 23 Mar 2004 08:16:49 -0800 (PST) > Alex Deucher <[EMAIL PROTECTED]> wrote: > > > > > --- Felix K_hling <[EMAIL PROTECTED]> wrote: > [snip] > > > 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). > > > > That's my understanding as well, but I could be wrong. Also, > tiling > > the front buffer results in lower performance. I'm not sure why. > It > > might have just been due to the way the code was initially > architected. > > your changes to the 3d driver may have fixed that. > > Don't know which changes that would be. The only thing where the > tiling > of the front buffer would make a difference for normal double > buffered > rendering is on buffer swaps. The swapping didn't change. So possibly > blitting to a linear frame buffer is faster than blitting to a tiled > one. Anyway, from Keith's comments about double-buffered visuals > where > the app switches between rendering to front and back buffer, it > sounds > like we really want to have a tiled front buffer. > I fixed tiled mode today. I'll be checking in a fix tomorrow. I need to clean up my tree, isolate the changes, and make sure I didn't break savage4. Alex __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html --- 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
Re: [Dri-devel] Re: [Dri-users] Problems with savage and DRI
On Thu, 25 Mar 2004 20:38:43 -0800 (PST) Alex Deucher <[EMAIL PROTECTED]> wrote: > > --- Felix K_hling <[EMAIL PROTECTED]> wrote: [snip] > > > > Don't know which changes that would be. The only thing where the > > tiling > > of the front buffer would make a difference for normal double > > buffered > > rendering is on buffer swaps. The swapping didn't change. So possibly > > blitting to a linear frame buffer is faster than blitting to a tiled > > one. Anyway, from Keith's comments about double-buffered visuals > > where > > the app switches between rendering to front and back buffer, it > > sounds > > like we really want to have a tiled front buffer. > > > > I fixed tiled mode today. I'll be checking in a fix tomorrow. I need > to clean up my tree, isolate the changes, and make sure I didn't break > savage4. I just saw your commit. Nice work (though I havn't tested it yet ;-). Are you going to fix the 3D driver too, to render directly to the front buffer? Or should I look into it? > > Alex > 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-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] Problems with savage and DRI
--- Felix Kühling <[EMAIL PROTECTED]> wrote: > On Thu, 25 Mar 2004 20:38:43 -0800 (PST) > Alex Deucher <[EMAIL PROTECTED]> wrote: > > > > > --- Felix K_hling <[EMAIL PROTECTED]> wrote: > [snip] > > > > > > Don't know which changes that would be. The only thing where the > > > tiling > > > of the front buffer would make a difference for normal double > > > buffered > > > rendering is on buffer swaps. The swapping didn't change. So > possibly > > > blitting to a linear frame buffer is faster than blitting to a > tiled > > > one. Anyway, from Keith's comments about double-buffered visuals > > > where > > > the app switches between rendering to front and back buffer, it > > > sounds > > > like we really want to have a tiled front buffer. > > > > > > > I fixed tiled mode today. I'll be checking in a fix tomorrow. I > need > > to clean up my tree, isolate the changes, and make sure I didn't > break > > savage4. > > I just saw your commit. Nice work (though I havn't tested it yet ;-). > Are you going to fix the 3D driver too, to render directly to the > front > buffer? Or should I look into it? I could try it, but you're probably more familiar with where the changes need to be made. Also how to we want to handle linear mode? should we disable 3D if linear mode is enabled? it works now, but only because the rendering is done to the back buffer. if we want to leave it in, we'll have to add a check in the 3d driver to only render to the back buffer. Alex __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html --- 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
Re: [Dri-devel] Re: [Dri-users] Problems with savage and DRI
On Fri, 26 Mar 2004 10:53:40 -0800 (PST)
Alex Deucher <[EMAIL PROTECTED]> wrote:
>
> --- Felix Kühling <[EMAIL PROTECTED]> wrote:
> > On Thu, 25 Mar 2004 20:38:43 -0800 (PST)
> > Alex Deucher <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > --- Felix K_hling <[EMAIL PROTECTED]> wrote:
> > [snip]
> > > >
> > > > Don't know which changes that would be. The only thing where the
> > > > tiling
> > > > of the front buffer would make a difference for normal double
> > > > buffered
> > > > rendering is on buffer swaps. The swapping didn't change. So
> > possibly
> > > > blitting to a linear frame buffer is faster than blitting to a
> > tiled
> > > > one. Anyway, from Keith's comments about double-buffered visuals
> > > > where
> > > > the app switches between rendering to front and back buffer, it
> > > > sounds
> > > > like we really want to have a tiled front buffer.
> > > >
> > >
> > > I fixed tiled mode today. I'll be checking in a fix tomorrow. I
> > need
> > > to clean up my tree, isolate the changes, and make sure I didn't
> > break
> > > savage4.
> >
> > I just saw your commit. Nice work (though I havn't tested it yet ;-).
> > Are you going to fix the 3D driver too, to render directly to the
> > front
> > buffer? Or should I look into it?
>
> I could try it, but you're probably more familiar with where the
> changes need to be made. Also how to we want to handle linear mode?
Ok, I have the necessary changes ready for committing (see the attached
patch). I havn't found any regressions and pipes is now nice and fast.
drawpix from the Mesa demos works with front and back buffers now that
they both have the same pitch. I don't know any test that switches
between front- and back buffer drawing and draws accelerated primitives
though.
> should we disable 3D if linear mode is enabled? it works now, but only
> because the rendering is done to the back buffer. if we want to leave
> it in, we'll have to add a check in the 3d driver to only render to the
> back buffer.
Good question. The 3D driver would work correctly as long as the
application doesn't try to draw to the front buffer. We could detect
that in savageDDDrawBuffer and fail when it happens.
>
> Alex
>
Felix
--- ./savageioctl.c.~1.7.~ 2004-03-25 01:54:03.0 +0100
+++ ./savageioctl.c 2004-03-26 23:21:03.0 +0100
@@ -71,7 +71,7 @@
pbox->y2 > imesa->savageScreen->height)
continue;
- if ( (pclear->flags & SAVAGE_FRONT) && imesa->IsFullScreen) {
+ if ( pclear->flags & SAVAGE_FRONT ) {
bciptr = savageDMAAlloc (imesa, 8);
WRITE_CMD((bciptr) , 0x4BCC8C00,uint32_t);
WRITE_CMD((bciptr) ,
imesa->savageScreen->frontOffset,uint32_t);
@@ -81,7 +81,7 @@
WRITE_CMD((bciptr) , (height << 16) | width,uint32_t);
savageDMACommit (imesa, bciptr);
}
- else if ( pclear->flags & (SAVAGE_BACK|SAVAGE_FRONT) ) {
+ if ( pclear->flags & SAVAGE_BACK ) {
bciptr = savageDMAAlloc (imesa, 8);
WRITE_CMD((bciptr) , 0x4BCC8C00,uint32_t);
WRITE_CMD((bciptr) , imesa->savageScreen->backOffset,uint32_t);
--- ./savagestate.c.~1.12.~ 2004-03-25 12:28:14.0 +0100
+++ ./savagestate.c 2004-03-26 22:56:08.0 +0100
@@ -642,18 +642,11 @@
case DD_FRONT_LEFT_BIT:
imesa->IsDouble = GL_FALSE;
-if(imesa->IsFullScreen)
-{
-imesa->drawMap = (char *)imesa->apertureBase[TARGET_FRONT];
-imesa->readMap = (char *)imesa->apertureBase[TARGET_FRONT];
-}
-else
-{
-imesa->drawMap = (char *)imesa->apertureBase[TARGET_BACK];
-imesa->readMap = (char *)imesa->apertureBase[TARGET_BACK];
-}
+ imesa->drawMap = (char *)imesa->apertureBase[TARGET_FRONT];
+ imesa->readMap = (char *)imesa->apertureBase[TARGET_FRONT];
+ imesa->regs.s4.destCtrl.ni.offset = imesa->savageScreen->frontOffset>>11;
imesa->NotFirstFrame = GL_FALSE;
-imesa->dirty |= SAVAGE_UPLOAD_BUFFERS;
+imesa->dirty |= SAVAGE_UPLOAD_BUFFERS | SAVAGE_UPLOAD_CTX;
savageXMesaSetFrontClipRects( imesa );
FALLBACK( ctx, SAVAGE_FALLBACK_DRAW_BUFFER, GL_FALSE );
break;
@@ -661,8 +654,9 @@
imesa->IsDouble = GL_TRUE;
imesa->drawMap = (char *)imesa->apertureBase[TARGET_BACK];
imesa->readMap = (char *)imesa->apertureBase[TARGET_BACK];
+ imesa->regs.s4.destCtrl.ni.offset = imesa->savageScreen->backOffset>>11;
imesa->NotFirstFrame = GL_FALSE;
-imesa->dirty |= SAVAGE_UPLOAD_BUFFERS;
+imesa->dirty |= SAVAGE_UPLOAD_BUFFERS | SAVAGE_UPLOAD_CTX;
savageXMesaSetBackClipRects( imesa );
FALLBACK( ctx, SAVAGE_FALLBACK_DRAW_BUFFER, GL_FALSE );
break;
@@ -1838,13 +1832
Re: [Dri-devel] Re: [Dri-users] Problems with savage and DRI
--- Felix Kühling <[EMAIL PROTECTED]> wrote:
> On Fri, 26 Mar 2004 10:53:40 -0800 (PST)
> Alex Deucher <[EMAIL PROTECTED]> wrote:
>
> >
> > --- Felix Kühling <[EMAIL PROTECTED]> wrote:
> > > On Thu, 25 Mar 2004 20:38:43 -0800 (PST)
> > > Alex Deucher <[EMAIL PROTECTED]> wrote:
> > >
> > > >
> > > > --- Felix K_hling <[EMAIL PROTECTED]> wrote:
> > > [snip]
> > > > >
> > > > > Don't know which changes that would be. The only thing where
> the
> > > > > tiling
> > > > > of the front buffer would make a difference for normal double
> > > > > buffered
> > > > > rendering is on buffer swaps. The swapping didn't change. So
> > > possibly
> > > > > blitting to a linear frame buffer is faster than blitting to
> a
> > > tiled
> > > > > one. Anyway, from Keith's comments about double-buffered
> visuals
> > > > > where
> > > > > the app switches between rendering to front and back buffer,
> it
> > > > > sounds
> > > > > like we really want to have a tiled front buffer.
> > > > >
> > > >
> > > > I fixed tiled mode today. I'll be checking in a fix tomorrow.
> I
> > > need
> > > > to clean up my tree, isolate the changes, and make sure I
> didn't
> > > break
> > > > savage4.
> > >
> > > I just saw your commit. Nice work (though I havn't tested it yet
> ;-).
> > > Are you going to fix the 3D driver too, to render directly to the
> > > front
> > > buffer? Or should I look into it?
> >
> > I could try it, but you're probably more familiar with where the
> > changes need to be made. Also how to we want to handle linear
> mode?
>
> Ok, I have the necessary changes ready for committing (see the
> attached
> patch). I havn't found any regressions and pipes is now nice and
> fast.
> drawpix from the Mesa demos works with front and back buffers now
> that
> they both have the same pitch. I don't know any test that switches
> between front- and back buffer drawing and draws accelerated
> primitives
> though.
Patch looks good at a glance. I'll test it tomorrow, but feel free to
commit it in the meantime :)
>
> > should we disable 3D if linear mode is enabled? it works now, but
> only
> > because the rendering is done to the back buffer. if we want to
> leave
> > it in, we'll have to add a check in the 3d driver to only render to
> the
> > back buffer.
>
> Good question. The 3D driver would work correctly as long as the
> application doesn't try to draw to the front buffer. We could detect
> that in savageDDDrawBuffer and fail when it happens.
>
Works for me.
> >
> > Alex
> >
>
> Felix
> > --- ./savageioctl.c.~1.7.~ 2004-03-25 01:54:03.0 +0100
> +++ ./savageioctl.c 2004-03-26 23:21:03.0 +0100
> @@ -71,7 +71,7 @@
> pbox->y2 > imesa->savageScreen->height)
> continue;
>
> - if ( (pclear->flags & SAVAGE_FRONT) && imesa->IsFullScreen) {
> + if ( pclear->flags & SAVAGE_FRONT ) {
> bciptr = savageDMAAlloc (imesa, 8);
> WRITE_CMD((bciptr) , 0x4BCC8C00,uint32_t);
> WRITE_CMD((bciptr) ,
> imesa->savageScreen->frontOffset,uint32_t);
> @@ -81,7 +81,7 @@
> WRITE_CMD((bciptr) , (height << 16) | width,uint32_t);
> savageDMACommit (imesa, bciptr);
> }
> - else if ( pclear->flags & (SAVAGE_BACK|SAVAGE_FRONT) ) {
> + if ( pclear->flags & SAVAGE_BACK ) {
> bciptr = savageDMAAlloc (imesa, 8);
> WRITE_CMD((bciptr) , 0x4BCC8C00,uint32_t);
> WRITE_CMD((bciptr) , imesa->savageScreen->backOffset,uint32_t);
> --- ./savagestate.c.~1.12.~ 2004-03-25 12:28:14.0 +0100
> +++ ./savagestate.c 2004-03-26 22:56:08.0 +0100
> @@ -642,18 +642,11 @@
> case DD_FRONT_LEFT_BIT:
> imesa->IsDouble = GL_FALSE;
>
> -if(imesa->IsFullScreen)
> -{
> -imesa->drawMap = (char
> *)imesa->apertureBase[TARGET_FRONT];
> -imesa->readMap = (char
> *)imesa->apertureBase[TARGET_FRONT];
> -}
> -else
> -{
> -imesa->drawMap = (char
> *)imesa->apertureBase[TARGET_BACK];
> -imesa->readMap = (char
> *)imesa->apertureBase[TARGET_BACK];
> -}
[snip]
I don't think it's used anymore, but FWIW, the fullscreen code in
savage_dri.c is broken for all chips except prosavages/twisters. It's
trivial to fix, but if it's going away...
Also, I think I figured out how to properly support the DVI port on
savage4 cards. It works right now, but like a crt. I should be able
to get expansion and dpms working on it, which will be nice for panels
like mine that don't have their own scaler.
Alex
__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux t
Re: [Dri-devel] Re: [Dri-users] Problems with savage and DRI
On Fri, 26 Mar 2004 14:56:31 -0800 (PST)
Alex Deucher <[EMAIL PROTECTED]> wrote:
>
> --- Felix Kühling <[EMAIL PROTECTED]> wrote:
[snip]
> > --- ./savagestate.c.~1.12.~ 2004-03-25 12:28:14.0 +0100
> > +++ ./savagestate.c 2004-03-26 22:56:08.0 +0100
> > @@ -642,18 +642,11 @@
> > case DD_FRONT_LEFT_BIT:
> > imesa->IsDouble = GL_FALSE;
> >
> > -if(imesa->IsFullScreen)
> > -{
> > -imesa->drawMap = (char
> > *)imesa->apertureBase[TARGET_FRONT];
> > -imesa->readMap = (char
> > *)imesa->apertureBase[TARGET_FRONT];
> > -}
> > -else
> > -{
> > -imesa->drawMap = (char
> > *)imesa->apertureBase[TARGET_BACK];
> > -imesa->readMap = (char
> > *)imesa->apertureBase[TARGET_BACK];
> > -}
> [snip]
>
> I don't think it's used anymore, but FWIW, the fullscreen code in
> savage_dri.c is broken for all chips except prosavages/twisters. It's
> trivial to fix, but if it's going away...
I kept the fullscreen code around because it demonstrates page flipping
with automatic Z clearing. :)
>
> Also, I think I figured out how to properly support the DVI port on
> savage4 cards. It works right now, but like a crt. I should be able
> to get expansion and dpms working on it, which will be nice for panels
> like mine that don't have their own scaler.
Sounds good.
>
> Alex
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-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
