[SOLVED] Confused about Mobility Radeon HD 3200

Question

I've always found hard to find good information about this card - some sources, even, contradict themselves. All what I know is that it is an integrated graphics card and that it features the RS780M chipset. These are some tips I've got from the system logs:
grep -i r600 /var/log/Xorg.0.log
[ 23.353] (II) RADEON(0): [DRI2] DRI driver: r600
[ 23.353] (II) RADEON(0): [DRI2] VDPAU driver: r600
[ 24.099] (II) AIGLX: Loaded and initialized r600
dmesg | grep -i radeon
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-linux-hf root=UUID=ab92c2db-22b5-4fcb-a33f-2efe3f3f104c ro radeon.modeset=1 radeon.benchmark=0 radeon.tv=0 radeon.pm=0 init=/usr/lib/systemd/systemd quiet
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-linux-hf root=UUID=ab92c2db-22b5-4fcb-a33f-2efe3f3f104c ro radeon.modeset=1 radeon.benchmark=0 radeon.tv=0 radeon.pm=0 init=/usr/lib/systemd/systemd quiet
[ 1.463857] [drm] radeon kernel modesetting enabled.
[ 1.464337] radeon 0000:01:05.0: VRAM: 256M 0x00000000C0000000 - 0x00000000CFFFFFFF (256M used)
[ 1.464340] radeon 0000:01:05.0: GTT: 512M 0x00000000A0000000 - 0x00000000BFFFFFFF
[ 1.464779] [drm] radeon: 256M of VRAM memory ready
[ 1.464781] [drm] radeon: 512M of GTT memory ready.
[ 1.472494] radeon 0000:01:05.0: WB enabled
[ 1.472499] radeon 0000:01:05.0: fence driver on ring 0 use gpu addr 0x00000000a0000c00 and cpu addr 0xffff8800374a5c00
[ 1.472502] radeon 0000:01:05.0: fence driver on ring 3 use gpu addr 0x00000000a0000c0c and cpu addr 0xffff8800374a5c0c
[ 1.472570] [drm] radeon: irq initialized.
[ 1.472672] radeon 0000:01:05.0: setting latency timer to 64
[ 1.504277] [drm] radeon atom DIG backlight initialized
[ 1.504279] [drm] Radeon Display Connectors
[ 1.504311] [drm] radeon: power management initialized
[ 2.344989] fbcon: radeondrmfb (fb0) is primary device
[ 2.441483] radeon 0000:01:05.0: fb0: radeondrmfb frame buffer device
[ 2.441486] radeon 0000:01:05.0: registered panic notifier
[ 2.441502] [drm] Initialized radeon 2.30.0 20080528 for 0000:01:05.0 on minor 0
I also found good (?) information, or at least a clearly-explained article, here. After reading it, UVD appears as the AMD's counterpart of NVIDIA's VDPAU for video acceleration.
What I'm not sure about, is:
-  Does it support video acceleration? I'd like to offload video processing to the GPU, but am not sure if my card and the open-source drivers support it or not. Wikipedia's article about VDPAU states it comes from NVIDIA, but then it says it has an open-source implementation.
-  What has gallium to do with it? What gallium drivers should I enable in mesa? And what about DRI drivers?
I configured mesa as follows:
./configure --prefix=/usr \
--sysconfdir=/etc \
--with-dri-driverdir=/usr/lib/xorg/modules/dri \
--with-gallium-drivers=r600 \
--with-dri-drivers=radeon \
--with-llvm-shared-libs \
--enable-gallium-llvm \
--enable-egl \
--enable-gallium-egl \
--with-egl-platforms=x11,drm \
--enable-shared-glapi \
--enable-gbm \
--enable-glx-tls \
--enable-dri \
--enable-glx \
--enable-osmesa \
--enable-texture-float \
--enable-xa \
--enable-vdpau
Not sure if I missed something, though.
I am very confused about how Linux manages graphics, and what all those layers are for. DRM, DRI, VDPAU, VA-API, gl, gl3, xv, xvmc... it's a mess!
Thanks in advance.
Last edited by Kalrish (2013-06-16 17:54:04)

Answer 1

The feature matrix might help. The easy part to answer is that the 3D driver is split into two parts: DRM which is part of the kernel and DRI which is in userspace and comes from the mesa package.
Xv is an Xserver extension supported by pretty much all drivers. Found in the DDX (xf86-video-*), it uses features of the card to speed up the display of video (but not decoding). It can either do this by using the "video overlay" or creating a shader.
Now if you want to use Xv but also offload decoding to the card, you need a video acceleration API. The ones to choose from are XvMC, VA-API, VDAPU in increasing order of feature support. They were developed by Xorg, Intel, Nvidia respectively but anyone is free to implement them. I don't think it's correct to call UVD a counterpart of VDPAU. UVD is a bunch of registers on newer AMD cards. And if you sent bits to those registers in the right way, you can implement VDPAU.
The other way to implement VDPAU (say if the documentation for UVD registers was not released) is to use gallium. There is a gallium state tracker which can still do it at the expense of being slower. It is a hack whereby you convert video frames to polygon textures and make the OpenGL part of the card think that it's calculating part of a 3D scene when really it's decoding video.