Xorg - 100% CPU usage with indirect rendering and some other Questions.
Lyssa Rabies
rabid.zombie.squirrel at gmail.com
Wed Jan 11 04:57:29 PST 2012
Hello,
i'm a real fan of X11 and its network transparency. I make heavy use of
this feature, but i got in some trouble. Let me tell a little bit about my
system.
I have jailed some services inside Linux Containers(LXC), so i can simulate
upgrades, move containers to other hosts, to improve security and try out
new software in a safe environment.
I'm using different versions of a desktop environment, so i can get a
closer look what would be new and what could make troubles. I also can
migrate back to a working desktop environment in under one minute if
something should go really wrong. All i use for this functionality is LXC
and Xorg. Another cool thing is, i can use a multi-monitor Setup, without
troubles.
And now, lets take a closer look at my problems. Sometimes i need OpenGL
applications, so i use indirect rendering. It is not slow, Xorg just takes
100% of my CPU. IIn this case it's not over a real network, it goes over a
bridge and an ethernet device created by the "veth" modul. And even if I'd
send it over 1Gbit, or 10 Gbit ethernet, it should not use 100% CPU, right?
I would understand if it's damn slow, because of the network
bottleneck.Maybe i should use VirtualGL, but then I'd need to give the
container acces to the hardware? I hope ayone knows a solution. Hmm, are
there some hardware-accelerated web-browsers?
Well, this was problem number one, let's get to problem number two. I need
hardware-acceleration for videos. Is there any way to use VAAPI(used by
this drivers: VDPAU, XVBA(or i'm wrong?)) over the network?
Used Hardware and drivers:
- NVS 285 with nVidia Legay Driver(173.14.31)
- nVidia GT 520 with 290.10 Driver
I have tried Xorg 1.11.2.902 and with the legacy driver i have used Xorg
1.10.4. The Distribution is a 64bit Debian Squeeze with some parts from
backports and testing.
kind regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20120111/2f25b2ce/attachment.html>
More information about the xorg
mailing list