On Wed, 2 Mar 2005, Tim Roberts wrote:
> Németh Márton wrote:
>
> > Hi!
> >
> > I've tested 4.5.0RC2 with xtest 4.0.10, see
> > http://bugs.xfree86.org/show_bug.cgi?id=1557 for details.
> >
> > I've attached a test C program which always produces bad rendering
> > using acceleration, and never if XaaNoScreenToScreenCopy is set
> > (=without acceleration). The results are also attached.
> >
> > Have anyone see souch behaviour?
> >
> > Have anyone programers manual about 86c764/765 [Trio32/64/64V+] chip?
>
>
> Is it really only GXclear, GXinvert, and GXset that fail? If so, the
> diagnosis is pretty easy.
>
> For those three ROPs, it's not really a screen-to-screen blit at all:
> the source surface is not used. Most S3 chips (Savage included) fail if
> you attempt to use a two-operand bitblt command when the source is not
> involved. That's why there is an XAA flag specifically for this case.
>
> The solution is to add
> pXAA->ScreenToScreenCopyFlags = ROP_NEEDS_SOURCE;
> to the S3AccelInitXxx function at the bottom of the file.
>
I don't believe the Trio32/64/64V+ had that problem. That was
specific to the ViRGE. I'm more inclined to believe that this
problem is because it's not setting:
pXAA->ScreenToScreenCopyFlags = NO_TRANSPARENCY;
I don't recall the the S3 driver I wrote a long time ago having
that feature, and you definitely don't want to be using it if you
support transparency during color expansions. The transparent blit
feature is really only for chips that don't have a color expansion
engine for stippling.
If you want to see correct acceleration code for the old S3 chips
you should dig up the old s3 code in the XFree86 3.3.x XF86_SVGA
server. I wrote that years ago.
Mark.
_______________________________________________
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
