Re: Xrender transforms...

2003-08-11 Thread Havoc Pennington
On Mon, Aug 11, 2003 at 10:59:19AM +1000, Carsten Haitzler wrote: 
 to the best of my knowledge, no. i remember it being discussed, but keith was
 very particular on a client being able to depend on the exact output of render
 so software and hardware/render routines could match. i can't find anything in
 the api that seems to indicate that you can hint saying ok - no need to be
 exact. close enough is good enough unless you mean the scaling filters (which
 have generic names like fast good best as well as bilienar and
 nearest), but that's about it.

Reading the spec, what I'm thinking of is Precise vs. Imprecise
polygon mode.

   When rasterized in Precise mode, the pixelization will match this
   specification exactly.
 
   When rasterized in Imprecise mode, the pixelization may deviate
   from this specification by up to 1/2 pixel along any edge subject
   to the following constraints: ...

etc. I guess you are talking about image operations though so 
nevermind. ;-)

The Fast, Good, and Best filter aliases as you say do seem to
allow pretty much any filter routine you want, at least.

Havoc





___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


Re: Xrender transforms...

2003-08-11 Thread Havoc Pennington
On Mon, Aug 11, 2003 at 09:02:32AM +1000, Carsten Haitzler wrote: 
 though i've said it before, xrender really should be an easily accessible 2d
 subset of opengl and pixel-exact rendering as it defines limits the ability to
 accelerate it - either with tricks in software (by losing 1 bit of precision you
 can double the speed in some cases), or with hardware. what people want to see
 IMHO is fast redraw of blended/scaled objects on things like the desktop or
 within web browsers etc. but if it isn't fast there's going to be a big
 resistance in migrating to use it.

I thought render gave the client the option of requesting or
explicitly disabling pixel-exact rendering, according to what the
client needs.

Havoc


___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


sparc pci patch

2003-08-11 Thread Warren Turkal
Here is a patch for sparc and PCI.

--- xc/programs/Xserver/hw/xfree86/os-support/bus/Imakefile~2002-10-30
10:03:18.0 +0900
+++ xc/programs/Xserver/hw/xfree86/os-support/bus/Imakefile 2002-11-18
09:49:56.0 +0900
@@ -18,8 +18,8 @@
 
 XCOMM Sparc SBUS driver and generic Linux PCI driver
 
-PCIDRVRSRC = linuxPci.c
-PCIDRVROBJ = linuxPci.o
+PCIDRVRSRC = sparcPci.c linuxPci.c
+PCIDRVROBJ = sparcPci.o linuxPci.o
 SBUSDRVSRC = Sbus.c
 SBUSDRVOBJ = Sbus.o
 
-- 
Treasurer, GOLUM, Inc.
http://www.golum.org

___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


Re: Xrender transforms...

2003-08-11 Thread The Rasterman
On Sun, 10 Aug 2003 14:27:13 +1000 Carsten Haitzler (The Rasterman)
(B[EMAIL PROTECTED] babbled:
(B
(B Would I be correct in the assumption that the only accelerated path for
(B xrender is the identity transform (1:1 scale)? all other transforms are done
(B in software? (my initial tests here with xfree86 4.3.0  nvidia's latest
(B drivers(as of about a month ago) seem to indicate as much...) (and yes... my
(B drivers are using acceleration... GL definitely is). ?
(B
(BI've put together a benchmark suite so you can have a go at making the drivers
(Bactually beat the CPU at rendering graphics via XRender :)
(B
(Bhttp://www.rasterman.com/files/render_bench.tar.gz
(Band
(Bhttp://www.rasterman.com/files/imlib2-1.1.0.tar.gz
(B(which is required to load the sample images and compare against).
(B
(Bhere is the output of running the benchmark here (24bpp, XFree86 4.3.0, Nvidia
(BGeforce4 4400ti, Kernel 2.4.20, 1.7Ghz Athlon, NVAGP=0 to stop random X
(Blockups/hangs) note: the longer something takes, the slower it is :)
(B
(BAs you can see from it Xrender even though (in theory) accelerated, is markedly
(Bslower than client-side code to do the same (and admittedly common operations).
(BEither I've done something terribly wrong using Xrender and triggered the
(Bslowest path imaginable... or this could help identifying parts of drivers to
(Boptimize :)
(B
(BAvailable XRENDER filters:
(Bnearest
(Bbilinear
(Bfast
(Bgood
(Bbest
(BSetup...
(B*** ROUND 1 ***
(B---
(BTest: Test Xrender doing non-scaled Over blends
(BTime: 12.445 sec.
(B---
(BTest: Test Xrender (offscreen) doing non-scaled Over blends
(BTime: 10.056 sec.
(B---
(BTest: Test Imlib2 doing non-scaled Over blends
(BTime: 0.332 sec.
(B*** ROUND 2 ***
(B---
(BTest: Test Xrender doing 1/2 scaled Over blends
(BTime: 6.480 sec.
(B---
(BTest: Test Xrender (offscreen) doing 1/2 scaled Over blends
(BTime: 6.462 sec.
(B---
(BTest: Test Imlib2 doing 1/2 scaled Over blends
(BTime: 0.145 sec.
(B*** ROUND 3 ***
(B---
(BTest: Test Xrender doing 2* smooth scaled Over blends
(BTime: 125.867 sec.
(B---
(BTest: Test Xrender (offscreen) doing 2* smooth scaled Over blends
(BTime: 125.898 sec.
(B---
(BTest: Test Imlib2 doing 2* smooth scaled Over blends
(BTime: 2.810 sec.
(B*** ROUND 4 ***
(B---
(BTest: Test Xrender doing 2* nearest scaled Over blends
(BTime: 103.294 sec.
(B---
(BTest: Test Xrender (offscreen) doing 2* nearest scaled Over blends
(BTime: 103.300 sec.
(B---
(BTest: Test Imlib2 doing 2* nearest scaled Over blends
(BTime: 2.049 sec.
(B*** ROUND 6 ***
(B---
(BTest: Test Xrender doing general nearest scaled Over blends
(BTime: 186.092 sec.
(B---
(BTest: Test Xrender (offscreen) doing general nearest scaled Over blends
(BTime: 186.248 sec.
(B---
(BTest: Test Imlib2 doing general nearest scaled Over blends
(BTime: 5.273 sec.
(B*** ROUND 7 ***
(B---
(BTest: Test Xrender doing general smooth scaled Over blends
(BTime: 270.536 sec.
(B---
(BTest: Test Xrender (offscreen) doing general smooth scaled Over blends
(BTime: 270.789 sec.
(B---
(BTest: Test Imlib2 doing general smooth scaled Over blends
(BTime: 8.170 sec.
(B
(B
(B-- 
(B--- Codito, ergo sum - "I code, therefore I am" 
(BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
$B7'<*(B - $Bhttp://XFree86.Org/mailman/listinfo/devel

Re: patch for ia64 page size

2003-08-11 Thread Ian Romanick
Jakub Jelinek wrote:

On Sun, Aug 10, 2003 at 07:06:58PM -0500, Warren Turkal wrote:

@@ -1003,6 +993,8 @@
   break;
}
+r128_drm_page_size = getpagesize();
+
sysconf (_SC_PAGESIZE)
is the standardized way of querying page size.
I seem to recall some discussion about this a few months ago.  There are 
some portability issues with both getpagesize and sysconf(_SC_PAGESIZE). 
 Because of that, XFree86 has a wrapper function called 
xf86getpagesize.  There also seems to be a #define that aliases 
getpagesize to xf86getpagesize, so I'm not sure if the wrapper should be 
used or if getpagesize should be used.  Either way, I'm sure that 
sysconf(_SG_PAGESIZE) should *not* be used directly.

___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


patch for ia64

2003-08-11 Thread Warren Turkal
This patch makes the radeon driver treat ia64 as a non-legacy architecture.

This patch by Alex Williamson.

xc/programs/Xserver/hw/xfree86/drivers/ati/Imakefile assumes ia64
should behave the same as i386 and allows random probing or I/O
port space.  In moving away from the legacy model, I believe we
should change this to set ATIAvoidCPIO to YES.  Systems that do
no provide a legacy I/O port range may otherwise machine check.

--- xc-old/programs/Xserver/hw/xfree86/drivers/ati/Imakefile2003-07-25
06:04:31.0 -0500
+++ xc/programs/Xserver/hw/xfree86/drivers/ati/Imakefile2003-08-07
04:35:24.0 -0500
@@ -82,7 +82,6 @@
  * ATIAvoidNonPCI necessarily implies ATIAvoidCPIO.
  */
 #if defined(i386Architecture) || \
-defined(ia64Architecture) || \
 defined(AMD64Architecture) || \
 defined(AlphaArchitecture)
 # ifndef ATIAvoidCPIO
-- 
Treasurer, GOLUM, Inc.
http://www.golum.org

___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


Re: patch to include some kernel info in banner

2003-08-11 Thread Daniel Stone
On Sun, Aug 10, 2003 at 09:04:42PM -0600, Marc Aurele La France wrote:
 On Mon, 11 Aug 2003, Daniel Stone wrote:
  On Sun, Aug 10, 2003 at 04:57:14PM -0500, Warren Turkal wrote:
   This patch puts the kernel version in the banner, on Linux, and also whether
   or not it's tainted (providing it's a sufficiently recent kernel). Thanks
   to Mike Harris for this patch (slightly altered to remove RH_CUSTOM, etc).
 
  Please do not accept this Linux-specific hack of a patch; I merged it to Debian,
  and Mike asked me not to send it upstream.
 
 Granted, as the patch stands.  However, I don't mind doing the minimal
 fixing up for inclusion, as this information would be extremely useful in
 some logs.

Feel free to make it more generic and include it - that would definitely be cool.

 Why the extra symbol, if I may ask, instead merely using defined(linux)?

I don't know, I just grabbed it off Mike and did
s/RH_CUSTOM/KERNEL_VERSION_IN_BANNER/; I think RH_CUSTOM is a catch-all for Red
Hat's whacky stuff.

-- 
Daniel Stone  [EMAIL PROTECTED]
http://www.debian.org - http://www.kde.org - http://www.freedesktop.org
Configurability is always the best choice when it's pretty simple to implement
  -- Havoc Pennington, gnome-list


pgp0.pgp
Description: PGP signature