Re: 4.4.99.902: s3 fails some of xtests

2005-03-03 Thread Mark Vojkovich
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:

2005-03-03 Thread Georgina O. Economou

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: Apple cinema display 20 / 1680x1050

2005-03-03 Thread vng2k
Thank for the reply.
I already tried it but it does not work out.  Should someone out there already
use the same monitor ( Apple cinema display 20 ) and have the setting
parameter available.

I tried to change the parameter but it appear to split the sreen into so many
section or little screen.

Thank




__ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel


Re: 4.4.99.902: s3 fails some of xtests

2005-03-03 Thread Nmeth Mrton

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;