Mesa 7.1 Released, X.Org 7.4 Coming!

[RealNC]

I am using this on an R580. 3D works; I'm using Google Earth and Compiz. Actually, Compiz works much better with the open source radeon driver than it does with fglrx! There's no insane "lag" when maximizing windows or switching desktops, everything is fluid and instant.

Note: be sure to activate EXA though since XAA is the default.

However, Xv is tearing badly (just like with fglrx). Fortunately, Gl video with vsync works.

Wine doesn't work and most "advanced" games don't work either.

[bridgman]

mityukov, you should be able to play video (using Textured Video) with the open source drivers under Compiz without flicker. 3D apps will still flicker until Redirected Direct Rendering, which is what requires DRI2. One day when I have free time I'll try to find out why we can't run 3D flicker-free today by forcing the 3D rendering to go through the indirect (AIGLX) path rather than the direct (DRI) path.

For video playback under Compiz, the general consensus seems to be that the real solution is to have Compiz impose sync-to-vblank during the compositing process (which uses OpenGL so should already have the ability to vsync) but I don't know if anyone is actually working on that yet. I don't know if Compiz syncs to vblank today. There seems to be an option for it but not sure if it actually works.

For video playback without Compiz, the 'missing link" is access to vsync in the X server via DRI which (if I understand correctly) is not there yet. Doesn't seem like a huge deal to implement but it's possible the devs see the Compiz route as making more sense long term. Not sure.

[RealNC]

For video playback under Compiz, the general consensus seems to be that the real solution is to have Compiz impose sync-to-vblank during the compositing process (which uses OpenGL so should already have the ability to vsync) but I don't know if anyone is actually working on that yet. I don't know if Compiz syncs to vblank today. There seems to be an option for it but not sure if it actually works.

It doesn't. Works with Xgl, not with AIGLX.

[bridgman]

Makes sense. Now that the coffee has started to take effect, I guess it's the same problem - only the direct rendering path (XGL) has vsync capabilities but the indirect (via X server) path does not - and Compiz uses the indirect path unless you're running with XGL.

I guess that means the X server needs vsync capability either way. From an architect's point of view that is good (nice and consistent) but from a developers point of view it sucks (somebody has to actually implement it and make it work ).

[ferreira]

VSync works on nvidia's AIGLX implementation too...

[Extreme Coder]

Why X11 overlay? I thought Radeon os-driver, already provide good support for Xv (via TextureVideo)?

http://wiki.x.org/wiki/RadeonFeature


In general, I think I can live without OpenGL 2/3 for now. Just let 2D(EXA), Desktop Effects and Video playback work flawlessly. ;-)

I understand, that Video/3D apps will flicker in Window mode, when Desktop Effects on, till somebody implement DRI2.. But I'm expecting that there are no reasons no to play them played correctly in the following cases:
- Desktop Effects: OFF -- Video/3D to be played correctly in both Window/Fullscreen mode;
- Desktop Effects: ON -- Video/3D to be played correctly in Fullscreen mode.

Can we really expect something like this?



And finally: what about AIGLX? Isn't that required for normal functioning of Compiz-like WMs on ATI/AMD cards? Or, this is a part of Xorg (how to check fo which Cards 7.4 has hardware-accelerated AIGLX)?


P.S.: please forgive me so many questions. I liked the news too much, and can't stop myself :-p

Thanks for the link.
It seems RS690 & R500 (the two cards I have), have most things working, mainly some 3D stuff and GLSL missing. Hopefully they'll be implemented sometime soon.

@bridgman: So if I get this Mesa release, will I be able to use Xv video with compiz, no flicker?

[bridgman]

Mesa shouldn't actually affect your Xv playback - you just need recent radeon, or very recent radeonhd, plus a recent DRM. The Xv code is all in the X driver (radeon/radeonhd) which in turn uses DRM to push 3d engine commands to the GPU.

[mityukov]

Mesa shouldn't actually affect your Xv playback - you just need recent radeon, or very recent radeonhd, plus a recent DRM. The Xv code is all in the X driver (radeon/radeonhd) which in turn uses DRM to push 3d engine commands to the GPU.

Oops, I thought that "X driver" is a part of Mesa (its HW branch)..
The more I read about all this stuff, the more it's mixing in my head. %)

What about AIGLX? Which of X component is responsible for it? And will the installation of today's Mesa and forthcoming X.Org 7.4 bring AIGLX support?

(there were some notes in the concurrent topic [Installing open-source radeon/radeonhd driver], that AIGLX (and therefore Compiz) "is not supported when using mesa 7.1 packages unless you also upgrade your xserver"..

Xserver and Xorg are different pieces of X, right?

[RealNC]

Xserver and Xorg are different pieces of X, right?

Xserver is one of the packages of Xorg. In other words, Xorg is a collection of packages and Xserver is one of them.

[bridgman]

Let's see...

The X server is the "framework" which includes a lot of common code. In the simplest case it loads a single X driver, which controls the graphics chip. Applications (called clients in X-speak) talk to a library (XLib or XCB) which sends commands to the X server. The X server then calls the X driver to set modes and do simple 2D drawing.

So far we are only using the X driver, not the DRM driver or the Mesa driver.

Getting a bit fancier, the application can make calls to the lib for things like accelerated video playback or 3D drawing. Video playback is handled by the X driver, which in turn may load and use a DRM driver (aka kernel driver), in which case the X driver will normally talk through the DRM driver to control the chip. I'll explain why in a bit.

3D drawing is done by having the X server call the Mesa, or 3D driver. Mesa can either do software rendering (using the CPU) or hardware-accelerated rendering if the right driver code is included. When Mesa is doing hardware accelerated rendering it normally goes through the DRM driver as well.

So far all of the drawing is what we call "indirect", where the app calls a lib, which sends commands to the server, which then calls the appropriate drivers (X driver for 2d & video, Mesa for 3D) to do the actual drawing. When we draw 3D this way with hardware acceleration, we call it AIGLX, or Accelerated Indirect GL through X.

Now, AIGLX is relatively recent. Before AIGLX, drawing 3D through the X server was normally pretty slow because it was done in software. The normal way to get 3D acceleration was via the "direct rendering infrastructure", or DRI. In this case the application calls went directly to the Mesa driver, bypassing the X server. Mesa then called the DRM driver, which coordinated use of the chip between the Mesa driver and the X driver. In this model, 2D and video acceleration went through the X server, the X driver, and the DRM driver, while 3D acceleration went directly to Mesa and then the DRM driver.

OK ? Direct vs Indirect rendering. Three drivers - X driver (xorg/driver/xf86-video-ati aka radeon or xorg/driver/xf86-video-radeonhd), DRM driver (mesa/drm), Mesa driver (mesa/mesa).

To add to the confusion, the DRM and Mesa drivers are not part of Xorg, so they are released independently of Xorg. This worked back when X mostly cared about 2D and video playback, but doesn't work so well today. The obvious answer is to include DRM and Mesa as part of Xorg, but it's not that simple because DRM ends up being integrated into the Linux kernel (or the BSD kernel, or Solaris kernel, or...) so maybe DRM should live in one of those kernel trees instead. This is all being hotly debated today.

Don't even THINK about trying to understand XGL