Mesa 7.1 Released, X.Org 7.4 Coming!

[phoronix]

Phoronix: Mesa 7.1 Released, X.Org 7.4 Coming!

Tungsten's Brian Paul has today announced the release of Mesa 7.1. New in this open-source library used by Linux graphics drivers for providing OpenGL support is autoconf-based configuration, assorted DRI driver enhancements, reduced dependencies between the X server and Mesa, GL_EXT_texture_from_pixmap extension for Xlib driver, GLSL (GL Shading Language) support for the Intel 965, and ATI Radeon R500 (X1000) series support...

http://www.phoronix.com/vr.php?view=NjY3Nw

[Extreme Coder]

Ok, I have a few questions:

- Does this release support OpenGL 2, even for a few cards?

- Does it support 3D on X500 cards? And is it usable? Can I run Compiz, or simple 3D games, or video using Xv? And performance?

- does the GL_EXT_texture_from_pixmap extension help in anyway in regards to Compiz/Compositing?

Thanks!

[Nille]

Ok, I have a few questions:

- Does this release support OpenGL 2, even for a few cards?

No the Free Drivers hang on 1.3 from 2001 :( ( and no texture compression is not an argument this is already in 1.3 )

- Does it support 3D on X500 cards? And is it usable? Can I run Compiz, or simple 3D games, or video using Xv? And performance?

I think so

[TechMage89]

Yes mesa 7.1 does support the r500 cards, and they work pretty well. Unfortunately, they only have about OpenGL 1.3 right now, and the 3d performance is about half of what you get with fglrx (2d performance is better, though). In short, r500 cards are easily usable, but the support still lacks features and performance.

OpenGL 2 (and one day, possibly 3) are supposed to come with gallium3D, but gallium has been held up by the DRM rejiggering. Fortunately, it looks like GEM will become the standard, and gallium support can be built on that.

[Extreme Coder]

Yes mesa 7.1 does support the r500 cards, and they work pretty well. Unfortunately, they only have about OpenGL 1.3 right now, and the 3d performance is about half of what you get with fglrx (2d performance is better, though). In short, r500 cards are easily usable, but the support still lacks features and performance.

OpenGL 2 (and one day, possibly 3) are supposed to come with gallium3D, but gallium has been held up by the DRM rejiggering. Fortunately, it looks like GEM will become the standard, and gallium support can be built on that.
Ah.. I see. Thanks!
Too bad Gallium will start being usable for stable use by the end of next year or something..
And why can't Mesa implement a newer GL release?

[some-guy]

- does the GL_EXT_texture_from_pixmap extension help in anyway in regards to Compiz/Compositing?
GLX_EXT_texture_from_pixmap is required for compiz
(@ Michael, isn't it a typo (GL_ instead of GLX_ ?))

Ah.. I see. Thanks!
Too bad Gallium will start being usable for stable use by the end of next year or something..
And why can't Mesa implement a newer GL release?
Gallium is re-architecturized mesa, to support OpenGL 2 and 3

[jeffro-tull]

I can use Kwin's compositing in KDE4 on my X1300. It's not ideal, but it works. So I would imagine that you could use Compiz with your X500.

By the way, I'm running Gentoo with the x11 overlay (scripts to pull and compile from the git master branches), so I'm only a few days behind what's current.

[grantek]

GL_EXT_texture_from_pixmap extension for Xlib driver
So I guess that means compiz can now run without any sort of 3d card, entirely on the CPU (or not, if there's other extensions it depends on). I wonder how much CPU it requires for a typical desktop...

[mityukov]

I can use Kwin's compositing in KDE4 on my X1300. It's not ideal, but it works. So I would imagine that you could use Compiz with your X500.

By the way, I'm running Gentoo with the x11 overlay (scripts to pull and compile from the git master branches), so I'm only a few days behind what's current.

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

[ivanovic]

Uhm, "overlay" is what in gentoo are external repositories for debian/ubuntu. Those are just "overlaying" the content of the normal package manager tree and thus providing some additional packages and other versions. The portage overlay for X11 eg includes git ebuilds for xorg stuff. It has *nothing* to do with video overlay stuff, it is package manager wording.

[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 :D).

[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 ;)

[mityukov]

Thanks a lot. I'll probably will need to draw a chart, using everything that I read here..

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.

...

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.

Sorry, does it mean that Direct 3D calls are not used, when playing Videos, and it's closer to 2D in the way how it's performing? Why it flickers in Compiz, just like any other 3D app, then?

I mean.. Is there a chance that the Video would be played in with Desktop Effects enabled _before_ DRI2 implementation? :rolleyes:


By the way: were there any considerations about having some sort of "X Windows system: Desktop edition" - without Network transparency requirements or so (I mean, free of "Client-server" model).

[madman2k]

Sorry, does it mean that Direct 3D calls are not used, when playing Videos, and it's closer to 2D in the way how it's performing? Why it flickers in Compiz, just like any other 3D app, then?
the flicker is not generally caused by 3D apps, but by conflicting accesses to the framebuffer, like when 3D directly renders to framebuffer.

But it is also possible to render Videos directly to framebuffer, which is how the Xv Overlay works.


I mean.. Is there a chance that the Video would be played in with Desktop Effects enabled _before_ DRI2 implementation? :rolleyes:
it should already play fine with desktop effects enabled, if you use textured video.

you have probably configure it using "gstreamer-properties".


By the way: were there any considerations about having some sort of "X Windows system: Desktop edition" - without Network transparency requirements or so (I mean, free of "Client-server" model).
this does not make sense.

[DanL]

Wow! Mesa 7.1 officially released. This is surely a sign of the Apocalypse. The next thing you know, The Four Horsemen will show up (I'm going to offer them a beer).

This is a good read (summarizes the different aspects of X rendering):
http://www.rojtberg.net/67/exa-uxa-dri-gem-ttm/