Re: 4.4.99.902: s3 fails some of xtests
On Fri, Mar 04, 2005 at 08:40:55AM +0100, N?meth M?rton wrote: Mark Vojkovich ?rta: 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. I've tested the two settings using xtest 4.0.10 at color depth 16. Here are my results: pXAA-ScreenToScreenCopyFlags = ROP_NEEDS_SOURCE; = the XCopyArea tests passed pXAA-ScreenToScreenCopyFlags = NO_TRANSPARENCY; = the XCopyArea tests fails the following tests: - GXclear (6) - GXinvert (16) - GXset (21) Is there any need to set the ROP_NEEDS_SOURCE on S3 Trio64V+ and not on the other S3 chips or the ROP_NEEDS_SOURCE will work on all S3 cards? s3virge have an other driver, and uses NO_TRANSPARENCY already. (What does ROP mean, anyway?) NMarci I'll commit the patch. Thanks for following it up. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: 4.4.99.902: s3 fails some of xtests
Nmeth Mrton wrote: I've tested the two settings using xtest 4.0.10 at color depth 16. Here are my results: pXAA-ScreenToScreenCopyFlags = ROP_NEEDS_SOURCE; = the XCopyArea tests passed pXAA-ScreenToScreenCopyFlags = NO_TRANSPARENCY; = the XCopyArea tests fails the following tests: - GXclear (6) - GXinvert (16) - GXset (21) Is there any need to set the ROP_NEEDS_SOURCE on S3 Trio64V+ and not on the other S3 chips or the ROP_NEEDS_SOURCE will work on all S3 cards? I don't know about ALL, but the Trio 32/64 family share the same graphics engine. There is certainly no danger in leaving that flag set for everyone. I believe the fallback is to use a solid fill, and that's probably the right answer in every case for those ROPs. The ViRGE and the Savage also have this problem, but as you note, they are in different drivers. (What does ROP mean, anyway?) Raster operation. That's the Windows term for a function that describes how to merge to pixel streams. (Actually, for all I know, the term might pre-date Windows. X uses the more mnemonic word function.) -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: 4.4.99.902: s3 fails some of xtests
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
Re: 4.4.99.902:
The very latest from the CVS works like a charm for me and my 810. Thanks ;-) ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: 4.4.99.902: s3 fails some of xtests
Mark Vojkovich rta: On Wed, 2 Mar 2005, Tim Roberts wrote: Nmeth Mrton 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. I've tested the two settings using xtest 4.0.10 at color depth 16. Here are my results: pXAA-ScreenToScreenCopyFlags = ROP_NEEDS_SOURCE; = the XCopyArea tests passed pXAA-ScreenToScreenCopyFlags = NO_TRANSPARENCY; = the XCopyArea tests fails the following tests: - GXclear (6) - GXinvert (16) - GXset (21) Is there any need to set the ROP_NEEDS_SOURCE on S3 Trio64V+ and not on the other S3 chips or the ROP_NEEDS_SOURCE will work on all S3 cards? s3virge have an other driver, and uses NO_TRANSPARENCY already. (What does ROP mean, anyway?) NMarci P.S.: My hardware is: chip: - S3 Trio64V+ P1E3BF 86C765 9650 MB851 TAIWAN VGA BIOS: - Phoenix S3 TRIO64V+ Enhanced VGA BIOS. Version 1.02-02 Copyright 1987-1992 Phoenix Technologies Ltd. Copyright 1992-1995 S3 Incorporated. All Rights Reserved lspci -v: - :00:09.0 VGA compatible controller: S3 Inc. 86c764/765 [Trio32/64/64V+] (rev 54) (prog-if 00 [VGA]) Flags: medium devsel, IRQ 10 Memory at e000 (32-bit, non-prefetchable) [size=64M] --- xc/programs/Xserver/hw/xfree86/drivers/s3/s3_accel.c.orig 2005-03-03 16:22:32.0 +0100 +++ xc/programs/Xserver/hw/xfree86/drivers/s3/s3_accel.c2005-03-04 08:36:04.0 +0100 @@ -567,6 +567,7 @@ pXAA-SetupForScreenToScreenCopy = S3SetupForScreenToScreenCopy; pXAA-SubsequentScreenToScreenCopy = S3SubsequentScreenToScreenCopy; + pXAA-ScreenToScreenCopyFlags = ROP_NEEDS_SOURCE; pXAA-SetupForColor8x8PatternFill = S3SetupForColor8x8PatternFill; pXAA-SubsequentColor8x8PatternFillRect = S3SubsequentColor8x8PatternFillRect;
Re: 4.4.99.902: s3 fails some of xtests
Nmeth Mrton 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? I have a Trio64V+ manual. The graphics engine is basically the same as the 8514/A. I'll take a look at the source and see if anything looks funny. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: 4.4.99.902: s3 fails some of xtests
Nmeth Mrton 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. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
