Nouveau's Gallium3D Driver Gets Video Boost

[phoronix]

Phoronix: Nouveau's Gallium3D Driver Gets Video Boost

Younes Manton, the student developer that has been working on Generic GPU Video Decoding that allows video decoding to be done universally in the GPU's shaders with any Gallium3D driver, has made some more progress on the NVIDIA front. We last talked about the state of Gallium3D video decoding back in September when Manton's video decoding method was working, but at an awfully slow pace. Now with his work on the Gallium3D-based Nouveau driver for NVIDIA hardware, he has achieved more promising results. Thanks to the latest code in Gallium3D and an improvement in Nouveau's winsys layer, those using this community-developed driver can now play 1080p video clips...

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

[Pfanne]

cant wait till ati drivers are ported to gallium3d combined with kms and r600/700 having full support!
2009 is going to rock!

[d2kx]

Yeah, a status update on Radeon + GEM/KMS/DRI2/Gallium3D would be nice (or have I missed something that was posted recently?). GEM is a dependency for all of them as far as I know, and Fedora 10 back in November was already running KMS stable for me, so some pieces should work I think.

[[Knuckles]]

Heh, it seems my old FX5200 might still be useful for something after all :)

[bugmenot]

Great work!

Does this confirm that this is the right (=best/easiest/most effective) way to go also for amd/ati?

[TechMage89]

It's definitely the easiest way, but unfortunately, while it takes a load off the CPU, it doesn't do much for power consumption, because it *does* put a substantial load on the GPU. It would be nice for people who want to watch DVDs on laptops, etc, to take advantage of fixed-function video decode hardware, but that's a lot harder, because it's non-generic and would have to be reverse-engineered.

In the case of AMD/ATI, they may be able to open specs for UVD2 for the more recent cards, but they're skittish about revealing too much about the DRM in their cards for fear of having their Windows certification revoked.

For now, the generic approach is the easiest and most practical, but it isn't low power and may not work as well on older/low end cards.

[Zhick]

@TechMage: Modern Graphics-Cards are several times faster than the NV40s this is currently beeing developed on. So if those cards are capable of playing back 1080p, modern cards could probably do so even when running at the lowest power-level (powerplay for ATi, don't know what it's called for nVidia), in contrast to a CPU which would most likely need to run at it's highest powerlevel. So I'd say you'll still end up saving power.

[_txf_]

@TechMage: Modern Graphics-Cards are several times faster than the NV40s this is currently beeing developed on. So if those cards are capable of playing back 1080p, modern cards could probably do so even when running at the lowest power-level (powerplay for ATi, don't know what it's called for nVidia), in contrast to a CPU which would most likely need to run at it's highest powerlevel. So I'd say you'll still end up saving power.


The problem being that with most (all?) open drivers dynamic clocking is currently a no-go. Not to mention the other stuff the card is doing at the same time i.e. compositing drawing widgets (exa). KDE4 (Qt4) + firefox gets all laggy when my clocks drop on my 8600m.

Then there is the fact that for h.264 (which is what most people care about accelerating) puts a significant load on decoding with the cpu meaning not much power is saved. What it does do is help ensure that the video won't stall on higher bit rates. You could consider it more like gpu assisted decoding.

[Louise]

Can anyone tell me, if this are the keys technologies?


| GEM | KMS | DRI2 | Gallium3D
-----------+-----+-----+------+-----------
Radeon | | x | |
-----------+-----+-----+------+-----------
RadeonHD | | x | |
-----------+-----+-----+------+-----------
OpenChrome | | | |
-----------+-----+-----+------+-----------
Nouveau | | | | x
-----------+-----+-----+------+-----------
Intel | x | x | x |
-----------+-----+-----+------+-----------

[whizse]

Intel does DRI2. KMS too, but it's still in heavy development, so you need stuff from git. Don't know about Gallium.

[Louise]

Intel does DRI2. KMS too, but it's still in heavy development, so you need stuff from git. Don't know about Gallium.

Thanks :)

But isn't GEM suppose to replace DRI2 for all drivers?

[whizse]

No, I don't think that's the right way to think about it, there's a good explanation by bridgman in this thread (http://www.phoronix.com/forums/showthread.php?t=7221).

Anyway, according to this blog entry (http://liquidat.wordpress.com/2008/08/14/gallium3d-a-short-explanation-where-it-fits-in/), it seems Intel is doing quite well when it comes to Gallium3D too:

Early 2008 the state was that the first real world driver, an older Intel one, was working quite well. It might take a while until Gallium3D really enters the stage.

[TechMage89]

GEM is a requirement for both KMS and Gallium.

Intel has all three, although their Gallium driver is still experimental.

ATI has working GEM and KMS in experimental branches (neither is a function of the Xorg driver, so radeon vs radeonhd doesn't matter.) Experimental DRI2 Also exists in radeon branches, I believe. Work has started on Gallium, but it doesn't yet produce any useful result.

Nouveau has experimental GEM, KMS, and Gallium, although all of it is still very incomplete and not really ready for end-users yet.

[Louise]

No, I don't think that's the right way to think about it, there's a good explanation by bridgman in this thread (http://www.phoronix.com/forums/showthread.php?t=7221).

Anyway, according to this blog entry (http://liquidat.wordpress.com/2008/08/14/gallium3d-a-short-explanation-where-it-fits-in/), it seems Intel is doing quite well when it comes to Gallium3D too:

okay, I gor it all mixed up a bit =)

So Gallium3D should replace Mesa?

GEM replace TTM (for gfx cards without dedicated gfx ram) ?

And there is no replacement for DRI2?

[some-guy]

It should be more like

| KMS | Memory Manager | DRI2 | Gallium3D |
+-----------------+-----------+----------------+--------+-----------+
| RadeonHD/Radeon | DEV | GEM/TTM | DEV | DEV |
+-----------------+-----------+----------------+--------+-----------+
| Openchrome | NO | TTM | NO | NO |
+-----------------+-----------+----------------+--------+-----------+
| Nouveau | DEV(NV50) | GEM/TTM | NO | DEV |
+-----------------+-----------+----------------+--------+-----------+
| Intel | MERGED | GEM | MERGED | DEV |
+-----------------+-----------+----------------+--------+-----------+
Radeon/RadeonHD are just separate DDX drivers they share dri/drm code

Also GEM or TTM is a requirement for KMS/DRI2/G3D, however TTM isn't in the kernel so GEM is required to have it merged

[Louise]

GEM is a requirement for both KMS and Gallium.

Intel has all three, although their Gallium driver is still experimental.

ATI has working GEM and KMS in experimental branches (neither is a function of the Xorg driver, so radeon vs radeonhd doesn't matter.) Experimental DRI2 Also exists in radeon branches, I believe. Work has started on Gallium, but it doesn't yet produce any useful result.

Nouveau has experimental GEM, KMS, and Gallium, although all of it is still very incomplete and not really ready for end-users yet.

Wow. This is a lot of keep track up =)

There should be a page like http://www.x.org/wiki/RadeonFeature for these things =)

[Louise]

It should be more like

| KMS | Memory Manager | DRI2 | Gallium3D |
+-----------------+-----------+----------------+--------+-----------+
| RadeonHD/Radeon | DEV | GEM/TTM | DEV | DEV |
+-----------------+-----------+----------------+--------+-----------+
| Openchrome | NO | TTM | NO | NO |
+-----------------+-----------+----------------+--------+-----------+
| Nouveau | DEV(NV50) | GEM/TTM | NO | DEV |
+-----------------+-----------+----------------+--------+-----------+
| Intel | MERGED | GEM | MERGED | DEV |
+-----------------+-----------+----------------+--------+-----------+
Radeon/RadeonHD are just separate DDX drivers they share dri/drm code

Also GEM or TTM is a requirement for KMS/DRI2/G3D, however TTM isn't in the kernel so GEM is required to have it merged

This one cool break down! Thanks a lot =)

[bridgman]

So Gallium3D should replace Mesa?

Gallium3D plus its drivers replaces the current HW drivers in Mesa. The rest of Mesa stays. Gallium3D is also probably going to be useful without Mesa, eg the recent article about implementing XvMC over Gallium3D.

GEM replace TTM (for gfx cards without dedicated gfx ram) ?

The GEM API is replacing the TTM API everywhere... but part of the GEM API is defined as "driver specific" so each driver will probably have different calls there. So far the initial implementation of GEM is not being used on cards with dedicated video memory, and instead the devs are using their existing TTM implementations.

It's best to think about the API part of GEM, or things will get very confusing very quickly ;)

And there is no replacement for DRI2?

Right, but DRI2 replaces DRI.

The other new thing is Redirected Direct Rendering, which needs DRI2 and GEM (DRI2 used to need TTM rather than GEM, but it was pulled back and reimplemented over GEM). RDR combines the speed of direct rendering with the compositer compatibility of AIGLX (indirect rendering), in other words all your apps still work but don't flicker under Compiz. It's possible that RDR work is being bundled in with DRI2 but I'm not sure.

It's mostly RDR and KMS that will make users' lives better; everything else is critical infrastructure to get there. Mesa-over-Gallium3D is hard to categorize; it'll do the same as Mesa did before, but hopefully will be faster and easier to optimize & enhance over time.

[Dieter]

The GEM, Gallium, etc. chart is fine for graphics developers.
End users need a chart more like:


+-----------+----------------+--------+-----------+---------+
| Xv | XvMC | mpeg4 | H.264 | theora |
+-----------------+-----------+----------------+--------+-----------+---------+
| RadeonHD/Radeon | | | | | |
+-----------------+-----------+----------------+--------+-----------+---------+
| Openchrome | Yes | Yes | ? | ? | ? |
+-----------------+-----------+----------------+--------+-----------+---------+
| Nouveau | | | | | |
+-----------------+-----------+----------------+--------+-----------+---------+
| Intel | | | | | |
+-----------------+-----------+----------------+--------+-----------+---------+



And we need to know what resolution and bitrate the driver/chip combo can handle.

I'd like to see a chart like http://www.x.org/wiki/RadeonFeature
for Chrome, Rage, Fire*, ...