[Fwd: xorg Digest, Vol 36, Issue 3]
Regina
regina.apel at gmx.de
Thu Jul 3 02:34:55 PDT 2008
-------- Original-Nachricht --------
Betreff: xorg Digest, Vol 36, Issue 3
Datum: Tue, 01 Jul 2008 08:51:29 -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. Re: [ANNOUNCE] xf86-video-nv 2.1.10 (Rene Rebe)
2. Re: [ANNOUNCE] xf86-video-nv 2.1.10 (Matthew Garrett)
3. The way to go with new 3D drivers (Shachar Kaufman)
4. radeon EXA performance questions (Ross Vandegrift)
5. Re: radeon EXA performance questions (Michel D?nzer)
6. Re: EXA Migration (Michel D?nzer)
7. Error while running Xorg on an ARM platform (Azza Kamal)
8. error while running Xorg on ARM platform (Azza Kamal)
9. Re: Further notes on 7.4 (Adam Jackson)
----------------------------------------------------------------------
Message: 1
Date: Tue, 01 Jul 2008 16:50:15 +0200
From: Rene Rebe <rene at exactcode.de>
Subject: Re: [ANNOUNCE] xf86-video-nv 2.1.10
To: Matthew Garrett <mjg59 at srcf.ucam.org>
Cc: xorg at lists.freedesktop.org, xorg-announce at lists.freedesktop.org
Message-ID: <486A4427.2000504 at exactcode.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Matthew Garrett wrote:
> On Tue, Jul 01, 2008 at 04:32:08PM +0200, Rene Rebe wrote:
>
>> Urgs, now that is dirty. I give it a try nonetheless :-)
>>
>> Who implemented this grave hack? Some thread of problem discussion
>> somewhere?
>
> Me. The copy of the video BIOS in the c000 segment is patched at POST to
> prevent it being reexecuted (as it may make calls into system BIOS code
> that no longer exists), so we need to run the stashed copy. The
> information I have is that this is safe for g80 - it certainly doesn't
> seem reliable on older hardware. No clue about g90 yet.
Now I wish I would have got an older MacBook Pro with ATi
chip, or some Intel one, yuck.
Thank you for all that info, I'll give it a try the next time
I can wreck^Wreboot my book.
Yours,
--
Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
------------------------------
Message: 2
Date: Tue, 1 Jul 2008 15:54:19 +0100
From: Matthew Garrett <mjg59 at srcf.ucam.org>
Subject: Re: [ANNOUNCE] xf86-video-nv 2.1.10
To: Rene Rebe <rene at exactcode.de>
Cc: xorg at lists.freedesktop.org, xorg-announce at lists.freedesktop.org
Message-ID: <20080701145419.GA17104 at srcf.ucam.org>
Content-Type: text/plain; charset=us-ascii
On Tue, Jul 01, 2008 at 04:50:15PM +0200, Rene Rebe wrote:
> Thank you for all that info, I'll give it a try the next time
> I can wreck^Wreboot my book.
I've been working on putting the nouveau BIOS parsing code in-kernel,
which works for my nv44 but seems to fail for just about everyone else
on the planet. The g80 support for the BIOS code isn't complete yet,
though. It'd be nice if nvidia could release this - it seems hard to
imagine that there's any real IP issues involved.
--
Matthew Garrett | mjg59 at srcf.ucam.org
------------------------------
Message: 3
Date: Tue, 1 Jul 2008 18:04:42 +0300
From: "Shachar Kaufman" <shachar.kaufman at gmail.com>
Subject: The way to go with new 3D drivers
To: <xorg at lists.freedesktop.org>
Message-ID: <486a478d.05ae660a.29ba.ffffb6fa at mx.google.com>
Content-Type: text/plain; charset="us-ascii"
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xorg/attachments/20080701/90f9a457/attachment.html
------------------------------
Message: 4
Date: Tue, 1 Jul 2008 11:26:21 -0400
From: Ross Vandegrift <ross at kallisti.us>
Subject: radeon EXA performance questions
To: xorg at lists.freedesktop.org
Message-ID: <20080701152621.GA6348 at kallisti.us>
Content-Type: text/plain; charset=us-ascii
Hi everyone,
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. No need for 3D, though it looks like Xorg
enables AIGLX without a problem.
I've come across some things that are enormously slower than XAA.
For example, inserting a line into the middle of an emacs buffer or
pressing the down arrow on a webpage. Scrolling by large amount is
fast. Dragging a window shows the same effects. It seems to be
moving a rectangle around the screen that's slow.
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"
Option "MigrationHeuristic" "greedy"
Any other tips?
--
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: 5
Date: Tue, 01 Jul 2008 17:32:33 +0200
From: Michel D?nzer <michel at tungstengraphics.com>
Subject: Re: radeon EXA performance questions
To: Ross Vandegrift <ross at kallisti.us>
Cc: xorg at lists.freedesktop.org
Message-ID: <1214926353.22068.138.camel at thor.sulgenrain.local>
Content-Type: text/plain; charset=utf-8
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?
> No need for 3D, though it looks like Xorg enables AIGLX without a problem.
>
> I've come across some things that are enormously slower than XAA.
> For example, inserting a line into the middle of an emacs buffer or
> pressing the down arrow on a webpage. Scrolling by large amount is
> fast. Dragging a window shows the same effects. It seems to be
> moving a rectangle around the screen that's slow.
>
> 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.
> Option "MigrationHeuristic" "greedy"
Which version of the driver and xserver? With current versions this
option shouldn't be necessary in general.
--
Earthling Michel D?nzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
------------------------------
Message: 6
Date: Tue, 01 Jul 2008 17:42:51 +0200
From: Michel D?nzer <michel at tungstengraphics.com>
Subject: Re: EXA Migration
To: Shachar Kaufman <shachar.kaufman at gmail.com>
Cc: xorg at lists.freedesktop.org
Message-ID: <1214926971.22068.146.camel at thor.sulgenrain.local>
Content-Type: text/plain; charset=utf-8
On Tue, 2008-07-01 at 17:50 +0300, Shachar Kaufman wrote:
> On an embedded system I have the GPU memory is actually faster than
> the CPU's main memory. Therefore it would be preferable to have new
> pixmaps allocated in offscreen vram right away and never migrated back
> (and forth).
>
>
>
> Is there a way I can achieve this without touching the server's EXA
> migration code (maybe a xorg.conf parameter or value I am missing)?
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.
[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...
--
Earthling Michel D?nzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
------------------------------
Message: 7
Date: Tue, 1 Jul 2008 15:47:32 +0000
From: Azza Kamal <eng_azza_kamal at hotmail.com>
Subject: Error while running Xorg on an ARM platform
To: <xorg at lists.freedesktop.org>
Message-ID: <BLU122-W111B5639E62EF61E6C3FD3C99E0 at phx.gbl>
Content-Type: text/plain; charset="iso-8859-1"
Hello all,I nearly have successed in cross cmpiling Xorg for ARM platform but unfortunately I got this error when trying to execute Xorg on the target board Fatal server error:xf86EnableIOPorts: Failed to set IOPL for I/O Any one can help please. Your help is very much appreciated.
_________________________________________________________________
Need to know now? Get instant answers with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_messenger_072008
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xorg/attachments/20080701/8fcad958/attachment-0001.htm
------------------------------
Message: 8
Date: Tue, 1 Jul 2008 15:44:32 +0000
From: Azza Kamal <eng_azza_kamal at hotmail.com>
Subject: error while running Xorg on ARM platform
To: <xorg at freedesktop.org>
Message-ID: <BLU122-W33895EBCD5B799B9237256C99E0 at phx.gbl>
Content-Type: text/plain; charset="iso-8859-1"
Hello all,
I nearly have successed in cross cmpiling Xorg for ARM platform but unfortunately I got this error when trying to execute Xorg on the target board
Fatal server error:xf86EnableIOPorts: Failed to set IOPL for I/O
Any one can help please. Your help is very much appreciated.
_________________________________________________________________
Use video conversation to talk face-to-face with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_Refresh_messenger_video_072008
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xorg/attachments/20080701/21c17a58/attachment-0001.htm
------------------------------
Message: 9
Date: Tue, 01 Jul 2008 11:46:17 -0400
From: Adam Jackson <ajax at nwnk.net>
Subject: Re: Further notes on 7.4
To: Hanno B?ck <hanno at hboeck.de>
Cc: xorg at lists.freedesktop.org
Message-ID: <1214927177.24769.155.camel at localhost.localdomain>
Content-Type: text/plain; charset=utf8
On Tue, 2008-07-01 at 16:15 +0200, Hanno B?ck wrote:
> Am Montag 30 Juni 2008 schrieb Adam Jackson:
> > http://cgit.freedesktop.org/xorg/util/modular/tree/module-list.txt
> >
> > While this list still includes most of the input drivers, be aware that
> > most of them are slated for the block, according to the input crew. If
> > you're not evdev/kbd/mouse/vmmouse/void start justifying your existence.
>
> synaptics? ("Justified" by the fact that all of it's features going beyond
> simple mouse moves and clicks, i.e. scrolling, edge-clicks,
> two/three-finger-clicks are not supported by evdev or mouse)
synaptics is already not part of the X.org module set.
- ajax
------------------------------
_______________________________________________
xorg mailing list
xorg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
End of xorg Digest, Vol 36, Issue 3
***********************************
More information about the xorg
mailing list