[Fwd: xorg Digest, Vol 36, Issue 4]
Regina
regina.apel at gmx.de
Thu Jul 3 02:35:20 PDT 2008
-------- Original-Nachricht --------
Betreff: xorg Digest, Vol 36, Issue 4
Datum: Tue, 01 Jul 2008 09:35:54 -0700
Von: xorg-request at lists.freedesktop.org
Antwort an: xorg at lists.freedesktop.org
An: xorg at lists.freedesktop.org
Send xorg mailing list submissions to
xorg at lists.freedesktop.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freedesktop.org/mailman/listinfo/xorg
or, via email, send a message with subject or body 'help' to
xorg-request at lists.freedesktop.org
You can reach the person managing the list at
xorg-owner at lists.freedesktop.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of xorg digest..."
Today's Topics:
1. ati-6.9.0 unstable dualhead (Sebastian Glita)
2. Re: radeon EXA performance questions (Ross Vandegrift)
3. Re: Resolution indpendence (Glynn Clements)
4. Re: The way to go with new 3D drivers (Jerome Glisse)
5. RE: The way to go with new 3D drivers (Shachar Kaufman)
6. Re: The way to go with new 3D drivers (Jerome Glisse)
7. RE: EXA Migration (Shachar Kaufman)
8. Re: Further notes on 7.4 (Dan Nicholson)
----------------------------------------------------------------------
Message: 1
Date: Tue, 1 Jul 2008 08:45:49 -0700 (PDT)
From: Sebastian Glita <glseba at yahoo.com>
Subject: ati-6.9.0 unstable dualhead
To: xorg at lists.freedesktop.org
Message-ID: <516424.24130.qm at web57006.mail.re3.yahoo.com>
Content-Type: text/plain; charset=us-ascii
I'm using dualhead an ASUS with ATI Radeon Xpress 1100 200M against a Belinea SVGA monitor.
The latest version now of xf86-video-ati drives the second monitor in an unstable state of shivering, trembling, flickering very fast (or something like that).
Here is the relevant part from /etc/X11/xorg.conf:
<<<
#
Section "Module" #
Load "xaa" #
Load "GLcore" #
Load "glx" #
Load "dri" #
Load "dbe" #
Load "vbe" #
SubSection "extmod" #
Option "omit XFree86-DGA" #
EndSubSection #
Load "bitmap" #
Load "type1" #
Load "freetype" #
Load "record" #
Load "evdev" #
Load "fbdevhw" #
Load "vgahw" #
Load "int10" #
EndSection #
#
Section "Monitor" #
Identifier "LCD 15.4'' WXGA" #
# Option "Enable" "true" #
Option "DPMS" "on" #
# Option "Rotate" "normal" #
# Option "Gamma" "1.0" #
#
HorizSync 28.0 - 96.0 #
VertRefresh 50.0 - 75.0 #
EndSection #
#
Section "Monitor" #
Identifier "VGA 17'' Belinea" # 10 30 75 (12 17 26) #
Option "DPMS" "on" #
Option "Enable" "false" #
Option "Ignore" "false" #
## Option "Rotate" "inverted" #
## Option "Gamma" "1.0" #
#
HorizSync 31.5 - 64.3 #
VertRefresh 50.0 - 90.0 #
#
## Modeline "1024x768x84.9" 94.50 1024 1096 1200 1376 768 771 775 809 -hsync +vsync
EndSection #
#
Section "Device" #
Identifier "RC410 [ATI Radeon Xpress 200M]" #
Driver "radeon" #
# Chipset "ATI Radeon XPRESS 200M 5A62 (PCIE)" #
ChipID 0x5A62 #
BusID "PCI:1:5:0" #
#
Option "Monitor-LVDS" "LCD 15.4'' WXGA" #
Option "Monitor-VGA-0" "VGA 17'' Belinea" #
#
# sw_cursor is needed for some ati and radeon cards #
## Option "SW_cursor" "true" #
Option "DynamicClocks" "on" #
#
#0 Option "NoAccel" #
Option "RenderAccel" "on" #
Option "AccelMethod" "XAA" #
Option "XAANoOffscreenPixmaps" "true" #
#
Option "BusType" "PCIE" #
Option "DDCMode" "off" #
Option "VGAAccess" "on" #
#
Option "UseInternalAGPGART" "yes" #
Option "GARTSize" "64" #
Option "AGPMode" "4" #
Option "AGPFastWrite" "1" #
#
Option "EnablePageFlip" "1" #
Option "ColorTiling" "1" #
Option "SubPixelOrder" "RGB" #
#
#! Option "DRI" "false" #
#
Option "NoMTRR" "true" #
#! Option "ModeDebug" "false" #
Option "Backingstore" "on" #
EndSection #
>>>
Until the problem can be fixed, I've switched back to =x11-drivers/xf86-video-ati-6.8.0-r1.
Thanks,
Sjeba
------------------------------
Message: 2
Date: Tue, 1 Jul 2008 11:53:29 -0400
From: Ross Vandegrift <ross at kallisti.us>
Subject: Re: radeon EXA performance questions
To: Michel D?nzer <michel at tungstengraphics.com>
Cc: xorg at lists.freedesktop.org
Message-ID: <20080701155329.GB6348 at kallisti.us>
Content-Type: text/plain; charset=iso-8859-1
On Tue, Jul 01, 2008 at 05:32:33PM +0200, Michel D?nzer wrote:
> On Tue, 2008-07-01 at 11:26 -0400, Ross Vandegrift wrote:
> > I converted my workstation at the office to use EXA instead of XAA
> > on a Radeon RV380. Many operations are clearly faster, and everything
> > seems quite stable. I'm not using any compositing manager, just E17
> > for normal 2D desktop work.
>
> Which E17 rendering backend is enabled, does switching between them make
> any difference?
I'm currently using Software, as it's the default. I just tried switching to
XRender but performance seemed identical.
> > Here's the device options I've enabled, and it's helped performance
> > somewhat:
> > Driver "radeon"
> > Option "AccelMethod" "EXA"
> > Option "AccelDFS" "1"
> > Option "EnablePageFlip" "1"
> > Option "ColorTiling" "1"
> > Option "FBTexPercent" "0"
>
> Note that the Mesa r300 driver won't work correctly without any video
> RAM reserved for textures.
Yea - I saw that in the documentation. Since I don't use Mesa (or any
GL at all) on this system, I figured I'd do that to give EXA as much
memory as possible for off-screen stuff. Is that faulty reasoning?
> > Option "MigrationHeuristic" "greedy"
>
> Which version of the driver and xserver? With current versions this
> option shouldn't be necessary in general.
That was only a slightly educated guess :)
My Xorg.0.log reports Xserver 1.4.0.90, and radeon module 4.3.0.
If I get the time today, I'll try upgrading the Xorg in Debian
unstable.
--
Ross Vandegrift
ross at kallisti.us
"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
------------------------------
Message: 3
Date: Tue, 1 Jul 2008 17:04:44 +0100
From: Glynn Clements <glynn at gclements.plus.com>
Subject: Re: Resolution indpendence
To: xorg at lists.freedesktop.org
Message-ID: <18538.21916.60547.979042 at cerise.gclements.plus.com>
Content-Type: text/plain; charset=us-ascii
Felix Miata wrote:
> AFAICT, the technology exists for displays to be double or more the
> resolution the average user has now, but the systems they're expected to be
> used with are dependent on anachronisms like 96 DPI, choices between two tiny
> bitmap icon size groups, and apps designed as if they were intended for print
> media of fixed dimension instead of computer display screens of widely
> varying size and resolution. Few would now buy those much higher resolutions
> due to the tininess of objects that would result from their use encumbered by
> those legacies. If the desktops could accommodate the same resolution laser
> printers started with (300 or more), the increments would be too small to
> matter, and scaling would bother few, or maybe no one.
Once you get up to double the size, you can get around the problems
quite easily, i.e. anything that isn't inherently scalable can just be
scaled by 2:1.
The problem is at the intermediate level, i.e. what you do with a 125
dpi monitor when everything is designed for 92 dpi. 125 dpi is still
low enough that rasterised vectors (outline fonts, SVG icons) are a
poor substitute for hand-crafted bitmaps, and scaling by
one-point-something factors is even worse.
> > So long as display resolutions remain low enough that you have UI
> > elements which are only a few pixels in size, the fact that you
> > ultimately have to rasterise whole pixels means that you can't just
> > operate entirely in physical units, in the same way that you can with
> > a 300+dpi laser printer.
>
> Right, so desktop environments need to make some big changes to permit
> display devices with enough resolution to be feasible. So, this thread isn't
> so much about whether people know the conflicts exist so much as it is the
> posture of those trying to make the best of what is vs. those trying to push
> capabilities up to a reasonable ought-to-be. I doubt anyone would complain if
> the average was 300. The problems are many in dealing with the gap between
> current reality and goodness, how to eliminate that gap, and living with and
> minimizing the pain of the under construction mess in the meantime.
Exactly. Displays are at the point where the limiting factor is often
physical size rather than pixel size, but it's going to be a while
before we get to the point that the limiting factor will *always* be
physical size.
In the meantime, trying to operate in fixed sizes is going to cause
problems. Fixed pixel sizes will result in elements which are
physically too small on high-resolution displays. Operating in fixed
physical sizes will result in elements which are too crudely rendered
on low-resolution displays.
Doing something in between is going to require some sophistication
from toolkits and applications, e.g. "negotiating" dimensions rather
than pulling a number from somewhere and treating it as an absolute.
> > Well, you *can*, but the artifacts are going to look a lot worse.
>
> Maybe to people with your 15/15 vision,
Or to people who buy low-end computers and only replace them once per
decade. Don't underestimate the size of that population. Also, bear in
mind that monitors tend to get replaced less often than computers; my
"spare" monitor (17", 1280x1024) was bought in 1995, and still works.
IOW, what is "current" isn't reflected by what's leaving the stores so
much as by what's going into the trash. Now, if you're a commercial
vendor, there may be rewards available for forcing people to discard
functional hardware prematurely. I don't see how that applies to us,
though.
--
Glynn Clements <glynn at gclements.plus.com>
------------------------------
Message: 4
Date: Tue, 1 Jul 2008 18:12:58 +0200
From: Jerome Glisse <glisse at freedesktop.org>
Subject: Re: The way to go with new 3D drivers
To: "Shachar Kaufman" <shachar.kaufman at gmail.com>
Cc: xorg at lists.freedesktop.org
Message-ID: <20080701181258.981dbd77.glisse at freedesktop.org>
Content-Type: text/plain; charset=US-ASCII
On Tue, 1 Jul 2008 18:04:42 +0300
"Shachar Kaufman" <shachar.kaufman at gmail.com> wrote:
> Having a DDX with XAA/EXA support which makes me comfortable, it's time to
> move on to the next step. I'd like to give my simple graphics hardware
> OpenGL acceleration support under Linux/Xorg. What would be the way to go
> about this today?
>
>
>
> Naturally I am looking at MESA to start off with, but am confused which
> driver(s) to use as an up-to-date reference which is also readable. I read
> about Gallium3D (Nouveau seems like a very active project), I also looked at
> the sources for current stable DRI drivers (Radeon, iXXX) as well as the
> OSMESA and X11 drivers.
If your hw support pixel shader then gallium should fit your need, if
it doesn't then you want to use mesa. There is not much other documentation
than what is on dri.freedesktop.org and the source code.
Cheers,
Jerome Glisse
------------------------------
Message: 5
Date: Tue, 1 Jul 2008 19:26:37 +0300
From: "Shachar Kaufman" <shachar.kaufman at gmail.com>
Subject: RE: The way to go with new 3D drivers
To: "'Jerome Glisse'" <glisse at freedesktop.org>
Cc: xorg at lists.freedesktop.org
Message-ID: <486a5ac0.02a1660a.5aec.ffffae17 at mx.google.com>
Content-Type: text/plain; charset="us-ascii"
> If your hw support pixel shader then gallium should fit your need, if
> it doesn't then you want to use mesa. There is not much other
documentation
> than what is on dri.freedesktop.org and the source code.
I'm not sure if I want to start off immediately with OpenGL 2.x but probably
something simpler like ES 1.x. Does this really mean I should stay away from
Gallium? I am also concerned Gallium might be too hot for my purposes still
(couldn't get a picture of how stable or fast it is compared with MESA/DRI).
Should I decide to go with MESA/DRI, which driver(s) would you recommend as
a reference?
------------------------------
Message: 6
Date: Tue, 1 Jul 2008 18:31:23 +0200
From: Jerome Glisse <glisse at freedesktop.org>
Subject: Re: The way to go with new 3D drivers
To: "Shachar Kaufman" <shachar.kaufman at gmail.com>
Cc: xorg at lists.freedesktop.org
Message-ID: <20080701183123.776a43ba.glisse at freedesktop.org>
Content-Type: text/plain; charset=US-ASCII
On Tue, 1 Jul 2008 19:26:37 +0300
"Shachar Kaufman" <shachar.kaufman at gmail.com> wrote:
> > If your hw support pixel shader then gallium should fit your need, if
> > it doesn't then you want to use mesa. There is not much other
> documentation
> > than what is on dri.freedesktop.org and the source code.
>
> I'm not sure if I want to start off immediately with OpenGL 2.x but probably
> something simpler like ES 1.x. Does this really mean I should stay away from
> Gallium? I am also concerned Gallium might be too hot for my purposes still
> (couldn't get a picture of how stable or fast it is compared with MESA/DRI).
>
> Should I decide to go with MESA/DRI, which driver(s) would you recommend as
> a reference?
>
>
Well gallium driver if you have an hw capable of pixel shader are easier
to write than mesa driver from my pov. If you don't have pixel shader than
you can take a look at radeon directory in mesa or intel directory.
Out of curiosity what is the hw you are playing with ?
Cheers,
Jerome Glisse
------------------------------
Message: 7
Date: Tue, 1 Jul 2008 19:32:06 +0300
From: "Shachar Kaufman" <shachar.kaufman at gmail.com>
Subject: RE: EXA Migration
To: 'Michel D?nzer <michel at tungstengraphics.com>'
Cc: xorg at lists.freedesktop.org
Message-ID: <486a5c09.06e2660a.6a50.ffffb7ed at mx.google.com>
Content-Type: text/plain; charset="UTF-8"
> No straightforward way I'm afraid[0]. It sounds like what you'd want is
> a variation of "always" which doesn't move pixmaps out of video RAM for
> fallbacks, which should be easy to add.
But this wouldn't allocate pixmaps in vram? That is, pixmaps would still be allocated in system ram and on the first operation - migrated, never to return. I would like to avoid the first transfer as well.
> [0] With current EXA, you could plug in your own allocation/migration
> logic via the CreatePixmap hook and friends, but that seems like
> overkill here...
That sounds more like it. Suppose I imitate default CreatePixmap behavior in the appropriate EXA hook, except that allocation would be in vram. How would I then hook into migration logic?
------------------------------
Message: 8
Date: Tue, 1 Jul 2008 09:35:36 -0700
From: "Dan Nicholson" <dbn.lists at gmail.com>
Subject: Re: Further notes on 7.4
To: "Daniel Stone" <daniel at fooishbar.org>, "Adam Jackson"
<ajax at nwnk.net>, xorg at lists.freedesktop.org
Message-ID:
<91705d080807010935h166df197k2b66e2d68b046ee6 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Jun 30, 2008 at 3:33 PM, Daniel Stone <daniel at fooishbar.org> wrote:
> On Mon, Jun 30, 2008 at 03:22:25PM -0700, Dan Nicholson wrote:
>
>> - imake/xorg-cf-files: Sadly, some 3rd party X packages still use imake.
>
> Right, but the ones which still use a bizzare build system will probably
> require other weird crap, so if it's well documented how to get a
> functioning imake setup installed, that shouldn't be a problem. There's
> nothing stopping distributions carrying them, since they never change,
> making it trivial for 99% of our users.
I remembered a good reason why these should still be installed. Tons
of autotooled X programs (certainly in GNOME) use the autoconf macros
AC_PATH_X or AC_PATH_XTRA to find the X installation. These use xmkmf
to find it or fall back to a lame non-multilib-aware search path when
xmkmf is not available. See _AC_PATH_X_XMKMF and _AC_PATH_X_DIRECT in
/usr/share/autoconf/autoconf/libs.m4. In the modern world, all these
programs should be using pkg-config to find the X libraries they need,
but it'll be a while till that's widespread.
--
Dan
------------------------------
_______________________________________________
xorg mailing list
xorg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
End of xorg Digest, Vol 36, Issue 4
***********************************
More information about the xorg
mailing list