Re: [gentoo-amd64] Gentoo AMD64 + Xen + Ati drivers

[Florent Ouchet]

Hello,

Thanks for these useful advises, I used VMWare for months (and then 
VirtualBox few months), I want to give Xen the same chance. The best 
option seems to be the installation of a second domain to locally handle 
display, IMO this configuration could be highly unstable if either Dom0 
or "Dom1" starts tripping.

I'll try to use flgrx drivers again on next time kernel-xen source get 
updated (current version if 2.6.20), I'll report back here; Two 
open-source drivers are available for radeon video cards:
 - xf86-video-ati is not able to drive my video card (no matching device)
 - I give a try to the new radeonhd driver which currently gives better 
performance than vesa legacy driver.

Best regards,

Florent


Beso a écrit :
> what i could tell you is that xen is a little behind with the sources,
> but still if configured in the right way there should be no problem in
> running a box. you just have to remember that with xen you'll need a
> "base" system, then another system to run on this base with reduced
> priviledges and assigned stuff. so you'll just need a base gentoo
> (stage3 should be fine), then you should configure xen to have another
> stage3 with installed apps. the xen problem is that you'll need 2
> linuxes to run one linux. but you'll be allowed to assign processors
> fragments or ram portions in the way you like. if you don't really
> need xen (you would run at least 2 different systems like using one
> linux i686 one amd64 or one linux and one windows - which should run
> well since you have vt) i think that using it would be a waste of
> time. also there are tools that let you install windows in boxes, like
> vmware and such (they're very good and fast and don't put you in the
> situation to use xen when xen is way back with kernel support and a
> lot of the new stuff in new pcs is supported only from the 2.6.21 or
> later kernel like the jmicron controller used in asus mobos). so my
> advice is avoid using xen unless it is really, really and i mean
> really necessary (you'll need 2 systems and a lot of configuration to
> run a single linux box that is slower than a native one).
>
> for the radeon driver, always use the ~amd64/~x86. always, since the
> driver is updated every month and has new things. for example the
> latest portage 8.433 has aiglx support support for the latest xorg and
> xorg-server (even if compiz won't work with xorg-server-1.4) and it
> has a great performance boost. also the new radeon has a hidden option
> to be added into the device section for enabling a render:
> Option "TexturedXrender" "true"
> it seems that this has a performance boost with rendering. for ati,
> you'll also have to control that you have the following files in
> /usr/lib/
> libGL.so.1, libGL.so.1.2. if one of them is missing create a symlink
> to the other libGL.so.x. this is due to a soname bug present in the
> latest fglrx releases. also be aware that there's a memory leak bug
> and apps like glxgears, amarok, firefox or others that use opengl
> would continue to suck out system memory. stay tuned to see if this
> happens and restart xorg when the system ram has reached a critical
> limit like 85-90%.
> or you may want to try the xf86 ati drivers for r500 (your chipset)
> because airlied, who is the main dev for the r500/600 radeon driver
> now works for red hat, has added some cool features like radeon
> modesetting and other stuff in the latest releases and you should be
> able to get a good working driver. you'll just have to add radeon
> support to xorg and use the radeon driver from ~amd64/~x86 branch.
> with ati these days is almost necessary to use this branch since the
> new releases add a lot of new features and fixes due to the recent
> amd/ati releasing specs and helping devs. i also would say you to
> remove the fbdev and all framebuffer ati modules or so from kernel
> since they're buggy and won't work correctly. also fb is useless if
> you use vesa or other stuff.
> is you use the fglrx then you'll also need to add the following stuff
> to the device section of your xorg.conf:
>   Option        "RenderAccel" "true" <--- needed for rendering stuff:
> forces sw rendering where hw doesn't work.
>   Option        "AllowGLXWithComposite" "true" <--- needed for
> compiz/beryl
>   Option        "HWCursor" "On" <---- needed to fix a bug with the
> mouse cursor
>   Option       "OpenGLOverlay" "off" <---- disables opengl overlay and
> doesn't work with Xv enabled
>   Option        "VideoOverlay" "on" <--- enables Xv overlay doesn't
> work with opengloverlay enabled
>   Option       "no_dri" "no" <---- use dri
>   Option       "UseInternalAGPGART" "no" <---- this is needed for some
> agpgart issues
>   Option       "FSAAEnable" "no" <---- disables fsaa since it is buggy
> on linux
>   Option       "BlockSignalsOnLock" "on" <----- needed to a have a
> stable driver
>   Option       "Capabilities" "0x00000000" <---- set capabilities to
> default since some cards are buggy with non default capabilities
>   Option       "mtrr" "off" <---- disables mtrr
>   Option        "XAANoOffscreenPixmaps" "true" <---- needed to fix the
> watermark issue of the latest fglrx releases
>   Option       "UseFastTLS" "0" <---- if you use wine don't set this
> to higher than 1.
>
> also for a working compiz you'll need this section:
>
> Section "Extensions"
>   Option        "DAMAGE" "true"
>   Option        "RENDER" "true"
>   Option        "Composite" "Enable"
> EndSection
>
> this is the working configuration for a fglrx running with compiz. if
> you experience issue with compiz then set the compiz setting from
> "texturefrompixmap" rendering to "force copy".
> --
> dott. ing. beso


-- 
gentoo-amd64@g.o mailing list