XvMC support

[bridgman]

Moving this discussion out of the open source 6xx/7xx thread...

Look at

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

XvMC is listed as TODO across the board. When can we expect to
see FLOSS AMD/ATI drivers supporting XvMC?

There hasn't been much interest in XvMC so far -- general feeling seems to be that even a laptop CPU can handle MPEG2 decoding well enough. There seem to be an increasing number of HD MPEG2 use cases, and we have already released enough information to implement MC on 5xx (and, as of today, 6xx/7xx I guess) but nobody has even asked how to implement it, which surprises me. We have IDCT on the list of hardware to try and open up, but given the lack of interest in MC it doesn't seem like a real priority (MC eats more CPU time than IDCT and is probably easier to implement).

If the issue is simply that not enough developers know how to implement XvMC then we could probably put together a sample implementation to get things started, but nobody seems to even ask about XvMC let alone show any interest in implementing it. I guess the issue is that the only place XvMC really buys you much these days is playing HD resolution MPEG2 streams, typically from off-the-air HDTV (ATSC, DVB), and not many people seem to do that.

EDIT -- I might have found the answer. The "classic use case" for XvMC was European digital TV, which was heavily standardized on MPEG2 at HD resolutions. Looks like many countries have already jumped ship to MPEG4 for most of their HD broadcasts, so the demand for HD MPEG2 acceleration seems to have evaporated. Given that, I think interest in XvMC is going to continue to be lukewarm until there is some agreement on an API which cleanly handles H.264 and VC-1 as well, whether it be an XvMC extension or something new like VAAPI, XVBA or VDPAU.

> There hasn't been much interest in XvMC so far

Perhaps you missed Phoronix's "2008 Linux Graphics Survey"?

The #1 activity was video playback, listed by 37.90%

"the second area with the most interest is seeing video improvements to X.Org"
Chart says 21.26%

Video playback/acceleration was listed by 15.09%

"When it comes to video playback improvements, the leading open-source solution
right now is through XvMC"

A related feature, TV-out was listed by 19.6%

http://www.phoronix.com/scan.php?page=article&item=lgs_2008_results&num=1

> I guess the issue is that the only place XvMC really buys you much these
> days is playing HD resolution MPEG2 streams, typically from off-the-air
> HDTV (ATSC, DVB), and not many people seem to do that.

Does the date 2009-02-17 mean anything to you? Do you actually think that
not many people watch TV?

So there is need/interest. When will FLOSS drivers accelerate mpeg decoding
on AMD/ATI GPUs?

[bridgman]

I read the survey and I saw the interest in video acceleration. I also understand that there is a mandatory transition to digital broadcasting going on. I don't know many people who watch TV but I understand that most people do (although relatively few seem to watch TV on Linux PCs).

The question is not whether people watch TV, or whether there is interest in video acceleration, but whether XvMC itself is the solution to their needs. My point was that I'm not seeing a lot of demand for accelerated MPEG2 playback - the bulk of the interest is in MPEG4, which XvMC does not directly support.

Both the European and North American TV standards now include MPEG4 as well as MPEG2. The move to MPEG4 seems to be happening very quickly, and right now XvMC only standardizes MPEG2 acceleration.

Are you asking about MPEG2 (XvMC) or MPEG4 / H.264 / VC-1 ? They really are two different questions.

> > There hasn't been much interest in XvMC so far

> Perhaps you missed Phoronix's "2008 Linux Graphics Survey"?

Bridgman is probably talking about developer interest, not general interest. We may not like it, but unless someone with the technical knowhow becomes motivated, neither XvMC not tv-out will see the light of day. That's the way the open-source world works.

What's so signifcant about 2009-02-17?

You are right about the developer interest, although I'm actually not seeing a lot of pull for MPEG2 acceleration in general. All of the interest seems to be in H.264/VC-1 acceleration, which XvMC doesn't handle today.

From the other thread, Feb 17 is the mandatory cutover date when analog broadcasting is supposed to end in the USA.

[StefanHamminga]

You are right about the developer interest, although I'm actually not seeing a lot of pull for MPEG2 acceleration in general. All of the interest seems to be in H.264/VC-1 acceleration, which XvMC doesn't handle today.

I think this is spot on, everyone I know wants H264 and to a lesser extend VC1 acceleration, I never hear about MPEG2 playback issues (on any os).

[calica]

I think this is spot on, everyone I know wants H264 and to a lesser extend VC1 acceleration, I never hear about MPEG2 playback issues (on any os).

I agree completely. I'm getting really sick of people whining about the lack of XvMC. With modern CPUs (rough guess last 6 years) MPEG2 isn't a problem. There is plenty of work to do that will result in real benefits and XvMC isn't one of them.

I even feel that accelerating H264/VC1 should be a low priority. My ranking (in rough order, for all cards) EXA optimizations, Improving 3D (Wine support), DRI2/GEM (redirected OpenGL vblank), Gallium3d, and finally next gen codec accel (maybe part of gallium3d). The big reason for this opinion is that there is no stable API to implement. VA-API is vapor and the rest proprietary. Let someone else do R&D until the OSS drivers catch up. Once caught up, then lead.

[steefjeqv]

Hi,

I've been using VDR for about two years know and I visit the VDRPortal (forum) on a daily basis.

HDTV (h.264-mpeg4) is one of the main topics on this forum, and the next stable version of VDR will support HDTV.

It took the MythTV guys a few days before they integrated VDPAU.
VDPAU meanwhile also kind of works with Xine and is being tested on VDR, with mixed results.

So, yes there are lots of people out there waiting for h.264 video accelaration. MPEG-2 can be handled with CPU power.
For the moment I'm using my good old Sapphire X550 and a dual core 5000+ and they can barely cope with the BBC 1080i HD signal.

Bridgman, if you don't mind, I'd like to link this thread to the VDRPortal. Just in case somebody's interested over there.

Greetings,
Steven

[Kano]

I never tested the MythTV VDPAU port, but I tested the xine-vdpau implementation. It works well with kaffeine tuning in a DVB-C hd channel (kaffeine svn should be able to tune in DVB-S2 directly). Also I tested the mpeg2 accelleration via VDR + xvdr (not really needed however for sd channels). With disabled composite extension tearing is not there, but bad frames seem to be able to crash the Xserver - or at least corrupt the display. CPU usage is really low with it. When you test mplayer vdpau you usually can not tune in hd channels directly, but you can use it for playing h264 media in containers. mkv does not work for example using xine but using mplayer. As the input data is usually better it did not crash for me yet testing this. A cpu usuage below 20% is really nice... ATI should work on it very soon.

[disturbedsaint]

Spending time/resources on a GPU hardware MPEG2 implementation is atm a waste of resources.

Like mentioned above every modern CPU will be more than capable te playback an (HD) MPEG2 movie.

H.264/VC-1 would be a lot better!
Though a standard and open API for it would be nice...

[RealNC]

I was playing MPEG2 fine even on my old Pentium 2 400MHz! That's not a "modern" CPU by any stretch of the imagination. People are interested about MPEG4 formats and think MC is going to help them.

[chrisr]

I read the survey and I saw the interest in video acceleration. I also understand that there is a mandatory transition to digital broadcasting going on. I don't know many people who watch TV but I understand that most people do (although relatively few seem to watch TV on Linux PCs).

Well I do, and my DVB-T devices are all based on MPEG2, as are all of the digital broadcast signals here in the UK. If DVB-T starts broadcasting MPEG4 then a lot of devices are going to break, which in turn would mean that there would have to be a lot of advance warning given. And I'm not seeing any right now.

If the UK is waiting until the analogue signals are all switched off before moving to MPEG4 (the extra bandwidth would allow HD DVB-T channels) then that won't be until 2012.

My point was that I'm not seeing a lot of demand for accelerated MPEG2 playback - the bulk of the interest is in MPEG4, which XvMC does not directly support.

Are you asking about MPEG2 (XvMC) or MPEG4 / H.264 / VC-1 ? They really are two different questions.

Well obviously we all want accelerated MPEG4 / H.264 / VC-1 but that doesn't mean that I wouldn't want to accelerate MPEG2 either! I don't care if my CPUs are "up to the task" of MPEG2 - I might be using them for something else at the same time!

Are we just talking about just R500+ here? I do have older machines with CPUs barely capable of MPEG2: R100, for example. (Or possibly rv100 - it's a Radeon 7000.)

I also happen to be a C developer with time on my hands (apart from WoW, which is like a black hole for free time) so what's the harm in a little extra functionality?

[RealNC]

Well obviously we all want accelerated MPEG4 / H.264 / VC-1 but that doesn't mean that I wouldn't want to accelerate MPEG2 either! I don't care if my CPUs are "up to the task" of MPEG2 - I might be using them for something else at the same time!

Yes, but that should be at the bottom of the priority list because we can live without it :P MPEG2 takes ~5% of your CPU lol.

Are we just talking about just R500+ here? I do have older machines with CPUs barely capable of MPEG2: R100, for example. (Or possibly rv100 - it's a Radeon 7000.)

This just needs good overlay support, not XvMC. I thought overlay is supported for those old cards?

[chrisr]

Yes, but that should be at the bottom of the priority list because we can live without it :P MPEG2 takes ~5% of your CPU lol.

That's still ~5% I could use for something else.

This just needs good overlay support, not XvMC. I thought overlay is supported for those old cards?

Huh? Of course R100/rv100 has overlay support. But the older CPU in this machine would definitely benefit from having any amount of work offloaded! Obviously.

[RealNC]

That's still ~5% I could use for something else.

But it's still 5% and therefore not as important as other issues :)


Huh? Of course R100/rv100 has overlay support. But the older CPU in this machine would definitely benefit from having any amount of work offloaded! Obviously.

Still it's an old machine and there are other issues more important :D

Don't take me wrong on this though. Of course it would be nice to have MPEG2 acceleration. It's just that, in my opinion, driver development should be focused on getting the more important bits implemented right now since XvMC is not going to help with MPEG4 which *would* be a high priority *if* XvMC would be suitable for it.

[TechMage89]

I think an implementation of VDPAU OR VA-API in the open-source drivers would be the way to go. It would primarily be useful for media PCs, but it definitely would be cool (and if it actually worked right, it would be better than Windows' video decode accel.)

That said, I think fully featured, fast 3D and 2D acceleration take precedence, because the use case for accelerated video decode is still smaller (most procs can handle even hi-def h264, and most people don't multitask while watching video).

[RealNC]

I just found this in Wikipedia's XvMC article (http://en.wikipedia.org/wiki/XvMC):

XvMC also supports offloading decoding of mo comp, iDCT, and VLD ("Variable-Length Decoding", more commonly known as "slice level acceleration") for not only MPEG-2 but also MPEG-4 ASP and MPEG-4 AVC (H.264) video on VIA Unichrome (S3 Graphics Chrome Series) hardware.

Is this true? If yes, how? Can we have it too? Please? :P

[curaga]

My Pentium2 333Mhz can handle xvid at dvd resolutions. With the help of a Rage Pro and full vidix accel, but still.

@RealNC: Yes, it's true. You'll need however the Via binary drivers, and to patch & compile mplayer. Don't remember right now if Via had a patch for Xine too.

[deneb]

XvMC also supports offloading decoding of mo comp, iDCT, and VLD ("Variable-Length Decoding", more commonly known as "slice level acceleration") for not only MPEG-2 but also MPEG-4 ASP and MPEG-4 AVC (H.264) video on VIA Unichrome (S3 Graphics Chrome Series) hardware.
I don't think they actually had support for H.264 acceleration, neither in software nor hardware, only H.263 and maybe MPEG-4 ASP in addition to MPEG-2. Haven't used the driver myself though.

[agd5f]

Are we just talking about just R500+ here? I do have older machines with CPUs barely capable of MPEG2: R100, for example. (Or possibly rv100 - it's a Radeon 7000.)

If someone was inclined, MC acceleration could be implemented with shaders on all r3xx-r5xx hw. IIRC, MC was done with the 3D engine on older asics (r1xx/r2xx) as well, but there may have been some special bits in the pipeline to handle it due to the lack of shaders on the older hw.

I also happen to be a C developer with time on my hands (apart from WoW, which is like a black hole for free time) so what's the harm in a little extra functionality?

Your best bet would be to study the video decode math and see what could be done on the 3D engine. One of the Xorg GSoC students implemented an MC interface gallium. You might want to look at that.

[RobbieAB]

I don't think they actually had support for H.264 acceleration, neither in software nor hardware, only H.263 and maybe MPEG-4 ASP in addition to MPEG-2. Haven't used the driver myself though.
XvMC is a bit hit and miss on the Via chipsets as to whether the drivers support it or not. It is being actively worked on for the openChrome drivers...

[chrisr]

Your best bet would be to study the video decode math and see what could be done on the 3D engine. One of the Xorg GSoC students implemented an MC interface gallium. You might want to look at that.

Do you mean this?:
http://www.bitblit.org/gsoc/g3dvl/index.shtml

This seems to imply that MC was done using shaders for the Nouveau project. So assuming that shaders are ARB, and therefore portable between NVIDIA and ATI hardware, doesn't this imply that the video decode math is already done?

[bugmenot]

Yes, the idea is that it should be portable. The radeon-gallium3d-brach is just to incomplete to let the video decode run on it.

Also the video decoding via gallium3d has still some issues and missing features, look at the last blog entry. It is for example still too slow. Maybe you could help out there?

[bridgman]

Well obviously we all want accelerated MPEG4 / H.264 / VC-1 but that doesn't mean that I wouldn't want to accelerate MPEG2 either!

Chrisr, all your points are valid. The question is whether the development community should invest their (limited) time in MPEG2 acceleration via XvMC or spend their time on MPEG4 instead.

My feeling is that our time is better spent working on MPEG4, where even some modern systems could use help.

[Kano]

Well VDPAU does not support MPEG4, only those codecs which are used by BlueRay.

[deneb]

Well VDPAU does not support MPEG4, only those codecs which are used by BlueRay.
You mean MPEG-4 ASP (DivX, XviD, ...). It does support MPEG-4 AVC.

[Kano]

Sure, but he mentioned MPEG4 and H264 - so I don't think he ment MPEG4 AVC twice.

[chrisr]

Chrisr, all your points are valid. The question is whether the development community should invest their (limited) time in MPEG2 acceleration via XvMC or spend their time on MPEG4 instead.

My feeling is that our time is better spent working on MPEG4, where even some modern systems could use help.

By all means, work on MPEG4 support; I can't help with that. However, with a small amount of guidance I could probably do something for MPEG2 - assuming that the GSoC has already written the shaders.

I managed to add zero-copy TFP support for R100/R200 using the exact same method, with a little help from Michel Danzer...

[_txf_]

Sure, but he mentioned MPEG4 and H264 - so I don't think he ment MPEG4 AVC twice.

Maybe it is just confusion between the container and the codec. It is almost as pointless to accelerate mpeg4-asp as it is to accelerate mpeg2.

[Dieter]

> XvMC is a bit hit and miss on the Via chipsets as to
> whether the drivers support it or not. It is being
> actively worked on for the openChrome drivers...

Is there a chart somewhere showing which features
openChrome supports on which Via chips? Perhaps similar to

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

[RobbieAB]

Not that I am aware off...

Though that might be something I could manage to arrange if the openchrome devs don't kill me for all my questions... ;)

[RobertCNelson]

Just a quick commit,

The MPEG-2 Stream off devices such as the HDHomerun (1) (1920x1080) or HD-PVR are not the easiest to decode on an age'ed cpu. I have a 10-20 second sample 16MB. (just pm me for link, (upload via slow cable modem))

1: http://www.silicondust.com/products/hdhomerun

Regards,

[Dieter]

> Both the European and North American TV standards now include
> MPEG4 as well as MPEG2. The move to MPEG4 seems to be happening
> very quickly, and right now XvMC only standardizes MPEG2 acceleration.

Show me a US TV station broadcasting mpeg4.

> Are you asking about MPEG2 (XvMC) or MPEG4 / H.264 / VC-1 ? They
> really are two different questions.

The immediate FCC created need is mpeg2, thus XvMC, which is what
I've been asking about. XvMC handles mpeg2 and there is talk about
having it do the newer stuff.

Out here in the real world, normal people don't buy a new computer
every three months to get the latest ueberphemon3++ 5.72 Ghz x16.
Full bitrate HD takes a lot more CPU than SD and computers in
the real world have trouble with it or can't do it at all.

Sure, longer term we will want support for the newer stuff.
But XvMC is the standard that the players already support,
It will take ages for the alphabet soup of proposed APIs
to get sorted out. Meanwhile the train wreck is scheduled
for 2009-02-17.

Maybe you should ask congress for bailout money to support the
DTV transition? :-/

[smitty3268]

>
Out here in the real world, normal people don't buy a new computer
every three months to get the latest ueberphemon3++ 5.72 Ghz x16.
Full bitrate HD takes a lot more CPU than SD and computers in
the real world have trouble with it or can't do it at all.

I've heard several general complaints about this, but not a single hard number. I would have guessed a Pentium 3 would have enough juice for this - can you definitively state which CPU you have in your computer that isn't fast enough? If there are P4's that can't keep up that's one thing, but it's very different if it's just P2's that need to be upgraded. I don't really have an old computer lying around to test myself.

Personally, I would love XvMC support. But not at the expense of just about any other feature I can think of. It's got to be right at the very bottom of almost everyone's list. Hopefully someone can build some generic support into Gallium3D and we won't have to always keep waiting for specific drivers to get supported.

I'm sure it sucks to be among the few who need it, but as had been said: the specs are available and someone just has to step up and do the work. That's the beauty of open source ;)

[rvdboom]

I have a 2GHz Opteron and it cannot deal with HD contents, either in MPEG4, MPEG2 or any other codec. And yes, I use overlay.
There is another reason why having accelerated MPEG2 would be nice : professional HD codecs. Most of them (HDV, HDCam, XD-Cam) are still MPEG-2 based and it's quite nice to be able to work natively with them at full resolution. Blue Ray is still MPEG2 also, AFAIR.
But I think that what should be worked on is a more generic acceleration API than XvMC allowing for several codecs, at least H264.
Since GPU are programmable now, isn't it possible to provide a generic API allowing to create small decoders in the appropriate programming language?

[Kano]

I don't know if H264 and small fits in the same sentence ;) But of course a generic solution using OpenCL for example would be very interesting.

[_txf_]

I don't know if H264 and small fits in the same sentence ;) But of course a generic solution using OpenCL for example would be very interesting.

H264 is designed to be scalable and has several different profiles. AFAIK most flash based web videos are based upon h264, and it can offer a very good tradeoff on bitrate vs quality,especially in comparison to mpeg2 and mpeg4 asp.

[RealNC]

I don't know if H264 and small fits in the same sentence ;)

Oh yes, it does! In fact, that the most important thing about H.264 for, uhm, file sharers :eek: :D ;)

Also, converting a DVD (MPEG2) into a single 700MB H.264 video with no loss of quality is another thing that makes "H.264" and "small" really fit together. Same quality but with an order of magnitude smaller size.

[deneb]

I have a 2GHz Opteron and it cannot deal with HD contents, either in MPEG4, MPEG2 or any other codec. And yes, I use overlay.
If 1080p30 MPEG-2 and MPEG-4 ASP are problematic for your CPU, you are either dealing with very high bitrates (> 30 Mbps) or there may be something wrong with your player/decoder setup or the graphics driver.

Blue Ray is still MPEG2 also, AFAIR.
Blu-ray can carry MPEG-2, but also H.264 and VC-1. MPEG-2 is rarely used in new releases.

But I think that what should be worked on is a more generic acceleration API than XvMC allowing for several codecs, at least H264.
Since GPU are programmable now, isn't it possible to provide a generic API allowing to create small decoders in the appropriate programming language?
A generic API and decoder implementations would certainly be a good idea for the future. Today, the most efficient way to decode MPEG-2, H.264 and VC-1 is by using specialized hardware like AMD's UVD or NVIDIA's VP3. To use these kind of complete decoding solutions, we only need lightweight hardware-specific wrappers and a common API.

[deneb]

@ _txf_ and RealNC

I think Kano was referring to the size and complexity of a fully-featured H.264 decoder implementation, not encoded video.

[duby229]

Oh yes, it does! In fact, that the most important thing about H.264 for, uhm, file sharers :eek: :D ;)

Also, converting a DVD (MPEG2) into a single 700MB H.264 video with no loss of quality is another thing that makes "H.264" and "small" really fit together. Same quality but with an order of magnitude smaller size.

I dont knwo if that is entirely accurate. Say you've got a 1:45 hour fourty five minute film and you want to keep the file at around 1500MB. Thats a fairly high bitrate. Even at that bitrate you can still see obvious blocking in dark areas. I have several films that are dark from start to finish, and they are blocky through out the entire film even, even at that bitrate.

[deneb]

Blockiness in flat and dark areas at relatively high bitrates can be avoided by using adaptive quantization. In particular, x264 used to suffer from these problems before VAQ was introduced in mainline and turned on by default. If you are seeing problems in encodes made by others, they are either old files or otherwise poorly encoded.

[duby229]

Blockiness in flat and dark areas at relatively high bitrates can be avoided by using adaptive quantization. In particular, x264 used to suffer from these problems before VAQ was introduced in mainline and turned on by default. If you are seeing problems in encodes made by others, they are either old files or otherwise poorly encoded.

These are my own encodes. I'm curious to hear more about VAQ, Is that somehow related to this patch?

http://files.x264.nl/x264_patches/force.php?file=./x264_aq_var.48.diff

If not then are you talking about Constant Quantizer? If so then what quantizer should I use to get near DVD quality?

[deneb]

These are my own encodes. I'm curious to hear more about VAQ, Is that somehow related to this patch?

http://files.x264.nl/x264_patches/force.php?file=./x264_aq_var.48.diff
Yes, but VAQ has been in the official x264 (git) tree since last spring and it is turned on by default if you use x264 CLI or MEncoder. See: x264 --longhelp | grep -A 4 aq

If not then are you talking about Constant Quantizer? If so then what quantizer should I use to get near DVD quality?
Always use CRF (constant rate factor) instead of CQ. CRF values of 18 or less should be mostly transparent, but personally I'm quite happy with CRF 22. Try values between 18 and 24 and decide what is good for you given the resulting file sizes.

[lamikr]

I read the survey and I saw the
Both the European and North American TV standards now include MPEG4 as well as MPEG2. The move to MPEG4 seems to be happening very quickly, and right now XvMC only standardizes MPEG2 acceleration.


My experiences from here in Finland is that all digital terrestrial broadcasting (DVB-T) is today in mpeg2.

During the time of Peking olympic, there were some HD broadcatings tests in the capital and some commercial channels may start also broadcasting DVB-T2/mpeg4 channels in some good luck within 1-2 year. Reason preventing the move is pretty much political because it is impossible to demand people again to upgrade their set top boxes and TV's which after a lot of complaining are now finally all digital. (and most of them will only support MPEG2)

Satellites/DVB-S/DVB-S2 are on the other hand moving much more fastly for the digital content, so partially you are right and accelerated MPEG4 is important. In VDR mailing list somebody reported 2 days ago that he was able to watch VOOM HD with 7 % cpu usage with NVidia 8200 chipset based motherboard and AMD4850 cpu thanks for the VPDAU support.

If I instead use VDR-1.7.2 and mplayer for watching the ArteHD with my AMD780G/4850E system, the top is reporting much worser numbers:

Tasks: 174 total, 3 running, 171 sleeping, 0 stopped, 0 zombie
Cpu(s): 71.4%us, 1.5%sy, 0.3%ni, 26.6%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st
Mem: 1799896k total, 1654508k used, 145388k free, 265404k buffers
Swap: 8185076k total, 176k used, 8184900k free, 642744k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7761 lamikr 20 0 730m 62m 22m S 120 3.6 3:54.90 vlc
3004 root 20 0 384m 58m 13m S 21 3.3 2:02.05 X
5200 lamikr 9 -11 224m 5540 3816 S 2 0.3 0:14.22 pulseaudio
7746 root 20 0 213m 24m 4460 S 2 1.4 0:04.87 vdr

With normal arte channel broadcasting MPEG2, my cpu usage according to top is about 25 %.

Mika

[bitnick]

In Sweden there's one DVB-T channel using mpeg4 at the moment, the experimental channel SVT HD. It is local to the capital area. I've heard rumors that some mpeg4 SD channels will be starting during 2009. But it's only rumors; I cannot give a real source.

[Kjella]

In Norway the terrestrial network is H.264. HD satellite TV is H.264. HD cable service is as far as I know also H.264. AVCHD video cameras is H.264. The only use I have for accelerating MPEG2 is my HDV camera but I don't have any use for it.

So basicly, interest in XvMC if it means extending XvMC to support H.264: High. XvMC MPEG2: None.

[lamikr]

I am little confused with terms in X... When this thread talks about whether to support XVMC, does it also mean whether to support XVIDEO/XV?

I own Wii which does not support direct output to LCD monitors. Therefore I am used to connect my Wii to my LCD monitor with the assistance of video input support in hvr-1300 dvb-t card and linuxtv application which can then show the content.

This worked very well with my 10 year old Pentium 700mhz with
integrated intel graphic card but not anymore with ATI drivers on my modern AMD780G system.

If I try to launch linuxtv I am now getting error:

[lamikr@tinka szap-s2]$ tvtime
Running tvtime 1.0.2.
Reading configuration from /etc/tvtime/tvtime.xml
Reading configuration from /home/lamikr/.tvtime/tvtime.xml
xvoutput: No XVIDEO port found which supports YUY2 images.

*** tvtime requires hardware YUY2 overlay support from your video card
*** driver. If you are using an older NVIDIA card (TNT2), then
*** this capability is only available with their binary drivers.
*** For some ATI cards, this feature may be found in the experimental
*** GATOS drivers: http://gatos.souceforge.net/
*** If unsure, please check with your distribution to see if your
*** X driver supports hardware overlay surfaces.

Some months ago I asked this in irc and heard from somebody that YUV2 support is coming soon once the docs are available.
Is there any updates for this expected soon? I think this was also not working with ATI's closed source drivers, at least the XV support was missing on last summer.

Mika

[bridgman]

Good question.

Everyone agrees that Xv is a must-have, partly since a number of applications more-or-less require it, and partly because Xv significantly helps pretty much every video playback task no matter what video format or resolution is being used.

This thread is only debating the urgency of building XvMC (Motion Compensation and optionally IDCT) on top of Xv, to offload more CPU work to the GPU when decoding MPEG2 video streams. Our view is that time would be better spent working on an implementation which could also handle H.264/VC-1 as well as MPEG2, which will require either some extensions to the XvMC API or a different API completely.

Right now Xv is implemented in the open drivers up to the 5xx and RS690 products; the 6xx and 7xx GPUs use an entirely new 3D engine which required a lot more development and documentation work. We released an "almost working" open source Xv implementation for 6xx/7xx into a public branch of radeonhd a few days ago; I imagine it will take a couple of weeks before we have it fully working. The code also needs a bit more work to run on the 780; I don't know exactly how long that will take but I don't think there will be any big delays.

I believe we added YUY2 support to the closed source drivers during the summer some time -- ah, here we go... looks like it was the June 08 (Cat 8.6) release.

[RobbieAB]

My take on this is that it is less a question of can the CPU do the work, but can we reduce power consumption by doing it on the GPU and putting the CPU into a lower power state? If power consumption can be reduced, it is worth getting working for the mobile device market, which is battery life sensitive.

[lamikr]

My take on this is that it is less a question of can the CPU do the work, but can we reduce power consumption by doing it on the GPU and putting the CPU into a lower power state? If power consumption can be reduced, it is worth getting working for the mobile device market, which is battery life sensitive.

Thats true. It would be nice to know what's the case with NVIDIA/VDPAU drivers. I mean what is the total power consumption of computer in case where you use 90% of your CPU for watching the h264 material compared to situation where the CPU load is only 7 % thanks for the VDPAU but the GPU is on the other hand doing much more work.

And is there any easy method/top kind of tool for watching the GPU utilization?

Mika

[Zajec]

Just wanted to add my "case".

I'm not interested in MPEG-2 or MPEG-4. GPU decoding of H.264 is something I would love to see. That is the format that really eats my CPU while playing.

[val-gaav]

It would be also nice to see some GPU help for encoding H.264 files with x264...
It takes a lot of time even on a dual core system, so it would be very nice if x264 encoding could use third thread and use the GPU to speed up the encoding :)

[deneb]

Thats true. It would be nice to know what's the case with NVIDIA/VDPAU drivers. I mean what is the total power consumption of computer in case where you use 90% of your CPU for watching the h264 material compared to situation where the CPU load is only 7 % thanks for the VDPAU but the GPU is on the other hand doing much more work.
Decoding video with NVIDIA's VP2/3 or AMD's UVD does not load the GPU much since the decoding unit is special-purpose hardware, separate from the GPU's stream processors. A passively cooled GeForce 8400 GS or Radeon HD 3450 decodes high-bitrate HD H.264 video without breaking a sweat. HD deinterlacing and other postprocessing may be a more stressing task.

And is there any easy method/top kind of tool for watching the GPU utilization?
I don't think there is for Linux, but monitoring the GPU temperature is a better way to estimate energy consumption.

[highlandsun]

As another data point, I have an Opteron 185 and a Dvico Fusion HDTV tuner and a Radeon 9550, and 4GB of DDR-400. It's pretty much impossible to watch 1080i HDTV material on this machine under Linux, but it works fine under WindowsXP using DxVA. I don't know what you guys are viewing when you say "MPEG2 doesn't even use 5% of my CPU" but it totally swamps this box. 720p stuff is generally viewable without trouble, but it still keeps the CPU pretty busy.

Anyway, the lack of XvMC on Radeon is one of the reasons I haven't switched my cable TV subscription from analog to HiDef yet (here in Los Angeles). It will be a long time before MPEG2 becomes irrelevant in the US...

[deanjo]

Decoding video with NVIDIA's VP2/3 or AMD's UVD does not load the GPU much since the decoding unit is special-purpose hardware, separate from the GPU's stream processors. A passively cooled GeForce 8400 GS or Radeon HD 3450 decodes high-bitrate HD H.264 video without breaking a sweat. HD deinterlacing and other postprocessing may be a more stressing task.


I don't think there is for Linux, but monitoring the GPU temperature is a better way to estimate energy consumption.

Well the 3450 will not do any of the decoding on the GPU for h264 yet so that would be up to your CPU to do all the decoding. A GeForce 8 series though can utilize vdpau even on insanely high bitrates and CABAC enabled.

This is what the usage and temperature looks like on a Sempron LE-1150 coupled with a 8200 IGP based board with Big Buck Bunny encoded from the raw 1920 HD pngs at a constant bitrate of 48 mbit/s for the full 10 minutes of playback. As you can see cpu and gpu don't even break a sweat during playback when vdpau is used on the 8200 and you have 0 dropped frames. Attempting such on a ATI card with such a meager system right now as it stands is not possible. Usage for mpeg2 and VC-1 are on par as well.

http://i30.photobucket.com/albums/c316/deanjo/1230081415-0.png
http://i30.photobucket.com/albums/c316/deanjo/1230081415-3.png

[deneb]

As another data point, I have an Opteron 185 and a Dvico Fusion HDTV tuner and a Radeon 9550, and 4GB of DDR-400. It's pretty much impossible to watch 1080i HDTV material on this machine under Linux, but it works fine under WindowsXP using DxVA. I don't know what you guys are viewing when you say "MPEG2 doesn't even use 5% of my CPU" but it totally swamps this box.
They are viewing SD MPEG-2. For me, playing 16 Mbps 1080i30 MPEG-2 video with MPlayer loads one core of a 2 GHz Core 2 Duo (T7200) up to about 60 %. I use NVIDIA's binary blob with the laptop's GeForce Go 7700 GPU.

Deinterlacing the video with a good software filter is much harder than MPEG-2 decoding, and my CPU is not up to the task with the current single-threaded Yadif (-vf yadif=3) implementation in MPlayer. FFmpeg's half-rate deinterlacer (-vf pp=fd) or simple bobbing (-vf tfields) adds about 10% to the CPU load.

I also tried the same video on an Athlon XP 2400+ (GeForce 2 GTS, nv driver) and it utilizes the CPU up to 80 % with some spikes to 95 %. Deinterlacing was not possible without dropping frames.

So, either you are dealing with bitrates much higher than 20 Mbps, your graphics driver has poor support for XVideo, your video playback software sucks or you are trying to use fancy software deinterlacing. ;)

[curaga]

About power consumption. Even if the cpu uses less, then the gpu uses more. While general cpus usually use max 95W, we have general gpus that can take 190W just on their own.

So, are there any benchmarks on total power consumption with vdpau/some other accel and without? Does the increased gpu wattage offset the decreased cpu power usage?

[deanjo]

About power consumption. Even if the cpu uses less, then the gpu uses more. While general cpus usually use max 95W, we have general gpus that can take 190W just on their own.

So, are there any benchmarks on total power consumption with vdpau/some other accel and without? Does the increased gpu wattage offset the decreased cpu power usage?

Power consumption increase from idle compared with during playback with vdpau is extremely small. At the wall measurements for the total system showed an increase of about 11 watts (idle 55 watts to 66 watts during vdpau playback) in consumption tested with a Fluke 83 V with some of that no doubt being consumed with the increased load on the harddrives. CPU powerstate remained at it's lowest level. Temp values on the GPU support those findings.

EDIT: I should add that playback attempts made without vdpau increased power consumption on the same system to 89 watts and dropped frames like mad.

[MU_Engineer]

I've heard several general complaints about this, but not a single hard number. I would have guessed a Pentium 3 would have enough juice for this - can you definitively state which CPU you have in your computer that isn't fast enough? If there are P4's that can't keep up that's one thing, but it's very different if it's just P2's that need to be upgraded. I don't really have an old computer lying around to test myself.

My MythTV machine is a 1.6 GHz Duron with a GeForce 6200 using the nvidia drivers. I downloaded a 40-some-odd Mbps 1080p MPEG-2 HD test file and this machine can play it back using 65-85% CPU usage with XvMC enabled and bob deinterlacing. It cannot play it back at all without using XvMC (e.g. by using Xvideo.) My Athlon 64 X2 4200+ desktop can just barely play back the same file with using Xvideo with an ATi x1900GT- CPU usage was about 95% and there was not enough CPU horsepower left to do deinterlacing. My month-old laptop's Core 2 Duo T7250 with the GM45 chipset using Xvideo has about 100% CPU utilization and occasionally drops frames playing the same test file. It is the bare minimum of being watchable, and it's a new machine. I say we certainly do need MPEG-2 decode assist for HDTV, which is mostly MPEG-2.

Personally, I would love XvMC support. But not at the expense of just about any other feature I can think of. It's got to be right at the very bottom of almost everyone's list. Hopefully someone can build some generic support into Gallium3D and we won't have to always keep waiting for specific drivers to get supported.

I'm sure it sucks to be among the few who need it, but as had been said: the specs are available and someone just has to step up and do the work. That's the beauty of open source ;)

Here's my priority for features desired in any new driver:
1. Recognizing the card and getting it to accelerate 2D.
2. Getting the card to not brek suspend-to-RAM/suspend-to-disk.
3. Getting Xvideo playback to work.
4. Getting 3D OpenGL acceleration/DRI to function.
5. MPEG-2 acceleration
6. Getting 3D OpenGL acceleration/DRI to work _well_.
7. MPEG-4/H.264/XviD/Ogg Theora decode acceleration
8. to 99. Bug fixes
100. VC-1/WMV/BluRay acceleration. Who gives a crap about MS's proprietary formats, a super-expensive optical disk format that can't even legally be played on the OS in almost all cases, and not to mention contend with a buttload of DRM in the process?

[_txf_]

Using dedicated hardware for a specific task will always be more power efficient than using a general purpose hardware.
In modern gpus dedicated bitstream decoding silicon will be more power friendly than using the graphics engine or the cpu.

However, there is a disadvantage to dedicated hardware, in that it is nowhere near as programmable or flexible as the cpu. This essentially means that files have to be encoded with the right codec, in the right way. There are many x264 encoded video files that will not work on the gpu (depending on the options used), but will work on the cpu. It is also why VC-1 cannot be added to the 8xxx parts because they do not do VLC.

[deanjo]

It is also why VC-1 cannot be added to the 8xxx parts because they do not do VLC.

Some do support VC-1, All 8200/8300 IGP's and some 8400GS (have to be based on the G98) have the capability.

[RealNC]

However, there is a disadvantage to dedicated hardware, in that it is nowhere near as programmable or flexible as the cpu. This essentially means that files have to be encoded with the right codec, in the right way. There are many x264 encoded video files that will not work on the gpu (depending on the options used), but will work on the cpu.

That's why we want OpenCL supported soon :) You can run everything on the GPU that way, regardless of how it's been encoded. CoreAVC (a Windows DirectShow H.264/AVC decoder) will be supporting CUDA soon in order to allow decoding of every video on the GPU with no regards to how it's been encoded.

[bridgman]

You can run everything on the GPU that way... (OpenCL)


I should mention that some of the video decode work (particularly the variable length decode (aka entropy decode) doesn't have much inherent parallelism and isn't the kind of thing that the GPU core does particularly well. Once you have gotten through the entropy decode, however, the rest of the work (starting with inverse quantization) is more amenable to generic GPU processing. Encoding is even more GPU-friendly, since motion estimation involves some godawful-expensive sweeps through the image looking for pattern matches, and GPUs are really good at that kind of thing.

It's really the bit-pickin' work where dedicated hardware is most useful. Fortunately the entropy decode is a relatively small part of the workload and is at the front of the pipeline so doing it on CPU is not a problem.

[Redeeman]

I have a 2GHz Opteron and it cannot deal with HD contents, either in MPEG4, MPEG2 or any other codec. And yes, I use overlay.
There is another reason why having accelerated MPEG2 would be nice : professional HD codecs. Most of them (HDV, HDCam, XD-Cam) are still MPEG-2 based and it's quite nice to be able to work natively with them at full resolution. Blue Ray is still MPEG2 also, AFAIR.
But I think that what should be worked on is a more generic acceleration API than XvMC allowing for several codecs, at least H264.
Since GPU are programmable now, isn't it possible to provide a generic API allowing to create small decoders in the appropriate programming language?
That simply cannot be possible.

I have a first generation amd64, socket 754, 2ghz, with very slow singlechannel ddr1 ram, and i can without issues play 1920x1080 mpeg2 videos, with standard xv output (overlay). Your opteron can impossibly be slower?

[MU_Engineer]

That simply cannot be possible.

I have a first generation amd64, socket 754, 2ghz, with very slow singlechannel ddr1 ram, and i can without issues play 1920x1080 mpeg2 videos, with standard xv output (overlay). Your opteron can impossibly be slower?

The bitrate of the MPEG-2 file is a big consideration. If he is playing large 1080p 40 Mbps files and yours are 1080i 15 Mbps or so, his Opteron has a MUCH harder workload ahead of it than your 3000+ does.

[deneb]

That's why we want OpenCL supported soon :) You can run everything on the GPU that way, regardless of how it's been encoded.
... when you have implemented fully-featured decoders that are comparable to current CPU-based decoders. General purpose GPU programming is harder than traditional coding, so don't expect quick results once OpenCL is usable.

CoreAVC (a Windows DirectShow H.264/AVC decoder) will be supporting CUDA soon in order to allow decoding of every video on the GPU with no regards to how it's been encoded.
CoreAVC is still only using the dedicated VP2/3 decoder through NVCUVID API in CUDA, just like Donald Graft's DGAVCDecNV. Most videos will be supported since NVIDIA's H.264 decoder is quite flexible (it can decode 1080p with 15 reference frames), but for example video resolutions higher than 1920x1080 will probably not work. Well, current CoreAVC doesn't support them either, but most other software decoders do.

[rvdboom]

The bitrate of the MPEG-2 file is a big consideration. If he is playing large 1080p 40 Mbps files and yours are 1080i 15 Mbps or so, his Opteron has a MUCH harder workload ahead of it than your 3000+ does.

Exactly.
The HD files I deal with indeed are made in a HD movie production pipeline, so they're usually quite high bitrate, above 30Mbs most of the time. Most of them are progressive, 24fps files, since they are made to be transfered on 35mm film prints.
I can play them on Windows with appropriate drives and players, but not on Linux.
Of course, I'm kind of a corner case, but I still would love GPU encode/decode support on Linux, as the hardware is already there to do that.

[rvdboom]

... when you have implemented fully-featured decoders that are comparable to current CPU-based decoders. General purpose GPU programming is harder than traditional coding, so don't expect quick results once OpenCL is usable.

Stupid question :
Would it be possible to have sort of a translator from C to OpenCL, allowing to for instance to translate ffmpeg decoders with minimum of work?

[bridgman]

It would be really hard. The way you structure a program for running efficiently on parallel hardware like a GPU is quite different from the way you would program a CPU.

In the case of a CPU you normally use loops and can easily have different behaviour at different points through the loop; with a GPU you set up little programs which run independently on every point in an image and then let them all run in parallel. As a result, complicated things like dealing with the edge of a block tend to be handled very differently in a GPU than in a CPU.

In-between systems like Cell processors bring yet another set of challenges; on those you can write more CPU-like code but you still need to deal with partitioning the work across a lot of little processors.

So, bottom line is that there is no easy solution yet, at least not that anybody has found.

[lamikr]

Sorry a stupid question but I have not been involved earlier anyway with gpu programming.

If you have multiple independent small programs that makes the calculations in paraller, is there often a problem that program2 can for example make it's work for pixel1 only once the program1 have finished it's job for certain pixel area? I mean how do you handle the dependencies between those small applications so that you prevent running them in wrong order. (3 + 2) * 5 != 3 + 2 * 5

[bridgman]

Nope, it's a good question. There are ways you can deal with dependencies and data communication between parallel threads, but in general if you rely on them much you lose most of the benefit of parallism.

This is why converting from a CPU program to a GPU program is not easy; you often need to come up with a new approach to solving the problem which does not require those dependencies. Some problems (eg picking apart a sequential bitstream) don't lend themselves to parallel processing at all.

[RealNC]

CoreAVC is still only using the dedicated VP2/3 decoder through NVCUVID API in CUDA, just like Donald Graft's DGAVCDecNV. Most videos will be supported since NVIDIA's H.264 decoder is quite flexible

Hmm. So then OpenCL is not the answer here? Then what is?

[bridgman]

It depends on the question ;)

The ideal solution is to have access to the dedicated hardware we all put in our chips to support BluRay playback. Unfortunately that hardware is also wrapped up in bad scary DRM stuff so making it available on Linux is a slow and painful process.

In the meantime, a lot of the computationally expensive work associated with H.264 decode and encode can be done with shaders, which is where OpenCL comes in. It doesn't *have* to be OpenCL, and the work doesn't have to wait for OpenCL, we're just saying that a year from now anyone writing that kind of code will probably start with OpenCL.

In the meantime, I believe there is enough info publicly available today to write a GPU-accelerated H.264 decoder for Linux on either Intel or ATI hardware using the 3D engine using conventional shaders. Another option for ATI and NVidia hardware would be to write the decoder using Stream or Cuda tools (but without that handy library).

One thing that tools like OpenCL will do is make it possible for more people to get into this kind of programming, without having to first take the plunge into driver development. The CUDA and Stream tools certainly help, but I think OpenCL will help more.

The other obvious benefit of OpenCL is the ability to run the same program on hardware from different vendors, which I guess you could say is "bad for the hardware vendors individually but good for them collectively" :D

[RealNC]

It depends on the question ;)

The ideal solution is to have access to the dedicated hardware we all put in our chips to support BluRay playback. Unfortunately that hardware is also wrapped up in bad scary DRM stuff so making it available on Linux is a slow and painful process.


You aren't making it available on Windows either :P CoreAVC is going to support CUDA. Was has ATI to offer here? They say "DXVA sucks" and that "it's a failure".

[bridgman]

Huh ? AFAIK we were the first to ship full GPU offload for HD-DVD/BluRay on Windows, and most of the reviews seem to think we still have a better implementation today.

If you read the rest of the thread where BetaBoy said "DXVA sucks and must die" it seems they aren't really planning to use CUDA itself as much as the library which NVidia made available for CUDA developers (the one popper mentioned a couple of days ago). I think the attraction of the library is that it makes it easy to retrieve the decoded frame, while most of the decoder implementations supplied by HW vendors tend to only output to the screen simply because that was the main requirement.

We make a similar capability available to ISVs :

http://www.cyberlink.com/eng/press_room/view_1756.html

I suspect the library uses the DXVA framework in the NVidia drivers, so having DXVA die might be a bit inconvenient, but that's just a guess ;)

[asun]

Another vote for offloading H.264 to GPU. Also another datapoint here:
AMD X2 5000+
Radeon HD2400 Pro
2GB DDR2 Ram
1920x1080 display

Hi bitrate H.264 video files would cause stutter and out-of-sync audio. No problem at all with MPEG2 or other MPEG4 codecs (divx, xvid, etc). Using top, it shows that mplayer is taking up all the CPU cycles.

[bridgman]

asun, are you playing through Xv, OpenGL or X11 output ?

[Kjella]

In the meantime, a lot of the computationally expensive work associated with H.264 decode and encode can be done with shaders, (...)

This might be a very short question with a very long and complicated answer, but: What shader power is required to match the custom hardware?

I did follow some attempts to implement generic shader decoding this summer like here: http://www.bitblit.org/gsoc/g3dvl/ - the other was Rudd on the XMBC team but that didn't seem to go anywhere and the g3dvl project was only able to do 854x480 in realtime.

Surely AMD looked a bit into whether regular shaders could do the work as they decided to go for dedicated hardware, so is it realistic to do Blu-Ray streams on shaders or is that just exaggerating the power of shaders?

It's a also a question of what class of chips can do this - like would it be something for an integrated chip with 10 shaders or only something for a 48xx class card? Some ballpark idea of that would be nice.

[bridgman]

Yep, the answer is long and complicated ;)

First off, let's get one thing clear. Implementing decode on shaders is not a complete substitute for dedicated hardware, but it is more flexible (fixed function hardware is picky about encoding details) and should be able to reduce CPU utilization enough to make a lot more systems able to decode in real time.

There are a bunch of activities in h.264 decode (bitstream parsing, entropy decode, spatial prediction) which don't lend themselves to being implemented on shaders so that work is going to have to stay on the CPU anyways. Fixed function hardware can handle the entire decode operation and use less power when doing the decoding.

In terms of hardware required, quick answer is "nobody knows for sure until the code is written". I doubt that the 40-ALU parts (HD2400, HD34xx, 780) will have enough power since the 3D engine is also being used for render accel (colour space conversion, scaling, deinterlacing etc..). I have always suggested that anyone wanting to run the open source drivers go with at least a 120-ALU part (2600, 3650 etc..) to have some shader power left over for decode work.

Again, this is all hypothetical right now anyways. I am just trying to give everyone an idea of what the likely scenarios are -- we are going to look into opening up UVD, I just can't make any commitments until we have actually gone through the investigation and it won't be quick. We have 6xx/7xx 3d code out now, so IMO the next priority should be basic power management.

[MU_Engineer]

In terms of hardware required, quick answer is "nobody knows for sure until the code is written". I doubt that the 40-ALU parts (HD2400, HD34xx, 780) will have enough power since the 3D engine is also being used for render accel (colour space conversion, scaling, deinterlacing etc..). I have always suggested that anyone wanting to run the open source drivers go with at least a 120-ALU part (2600, 3650 etc..) to have some shader power left over for decode work.

What about R5xx parts? Are the shaders on those units usable for shader-assisted decode?

[bridgman]

Yep, there's nothing special about the 6xx/7xx shaders in that regard. That's one of the interesting things about a shader-based implementation -- it can't accelerate as much as dedicated hardware, but it can work on GPUs which don't *have* dedicated hardware. You would probably need a fairly high end card though -- the rv530 was the first time we started cranking up the ALU:TEX and ALU:ROP ratio (partly for more shader-intensive games, and partly for video processing), and you probably would need X8xx, X18xx or X19xx realistically.

Again, until something is implemented these are all SWAGs.

[popper]

"we are going to look into opening up UVD, I just can't make any commitments until we have actually gone through the investigation and it won't be quick. We have 6xx/7xx 3d code out now, so IMO the next priority should be basic power management. "


thats a shame, we are looking at months at the very least then!

"I think the attraction of the [NV cuda] library is that it makes it easy to retrieve the decoded frame, while most of the decoder implementations supplied by HW vendors tend to only output to the screen simply because that was the main requirement.

We make a similar capability available to ISVs :

http://www.cyberlink.com/eng/press_room/view_1756.html
"

yep,that about covers it for basic needs it appears, your average dev and indeed Pro coders such as BetaBoy and the CoreAVC coders dont really need that much help once they have the right library and docs access it seems, BetaBoy said he wanted to support ATI UVD in CoreAVC and related apps but you dont give them or the open SW coders access to the ATI UVD.

"I suspect the library uses the DXVA framework in the NVidia drivers, so having DXVA die might be a bit inconvenient, but that's just a guess "

i think its just entry points into and out of the generic DSP "blackbox" they put on their cards/SOC chips TBO.....

i dont really see why ATI/AMD couldnt also make such as "blackbox" UVD available as a stop gap measure to help multi OS devs in the short term TBO...!

i dont know why (other than saving pennys they could recoup on the retail cost) you HW vendors dont just move away from these antiquated DSP SOC, and start using current faster and vastly more expandable FPGA's for your UVD, you (or indeed anyone) could then simply re-program on the fly for many other HW assisted tasks and market sectors?.

imagine the open source and even closed add-on FPGA (Field Programable Gate Array)code you could market and sell into a generic mass markets.

simply taking the chance and putting a current fast,low power FPGA on every ATI/AMD gfx and related card/MB would bring the worlds FPGA prices right down in line or below the cheap DSPs favoured today perhaps....fostering lots of innovative cost effective uses in the near/long term for everyones benefit.

and there wouldnt be any problems as regards DRM layden code.

given the apparent potential long wait for anything ATI UVD related, perhaps its finally time to move over to NV cards for now as the only viable option for many people world wide today!, as CoreAVC have a linux library available and have released test HW assisted cuda/VS2 CoreAVC on windows that apparently gives it a massive (x2-x4) decoding boost, i dont know if it will be usable on linux X86 as yet though.

[bridgman]

thats a shame, we are looking at months at the very least then!

For open source, yes, but I expect fglrx will have it sooner.

i dont know why (other than saving pennys they could recoup on the retail cost) you HW vendors dont just move away from these antiquated DSP SOC, and start using current faster and vastly more expandable FPGA's for your UVD, you (or indeed anyone) could then simply re-program on the fly for many other HW assisted tasks and market sectors?. imagine the open source and even closed add-on FPGA (Field Programable Gate Array)code you could market and sell into a generic mass markets. puttig an FPGA on every ATI/AMD gfx and related card/MB would bring the FPGA prices right down in line or below the cheap DSPs favoured today perhaps....

FPGAs need an insane number of random-logic transistors (ie they take a bunch of die area per transistor) to perform the same functionality as application-specific logic. I think UVD would end up roughly the same size as the RV770 shader core if we did it in FPGA. It's a nice idea but the cost would probably be a lot higher than you expect.

given the apparent potential long wait for anything ATI UVD related, perhaps its finally time to move over to NV cards for now as the only viable option for many people world wide today!, as CoreAVC have a linux libray available and have released test HW assisted cuda/VS2 on wiodows,

Again, I was talking about UVD support in the open source drivers.

i dont know if its will be usable on linux X86 as yet though.

The nvcuvid library that everything else builds on is Windows only AFAIK.

[_txf_]

If you want a fpga based graphics card you should look at the open graphics project. Their initial developer cards are fpga based, and note that they use a fairly beefy fpga just to do a "simple" graphics card. You can also gasp at the price of one of those boards (whilst it is true, that the fact that it is niche keeps costs up).

However even the open graphics people want to transition/create a wide release asic version. Fpgas use much more power,silicon, and are less powerful than an equivalent asic, and as a result their primary market applications are for developers and applications where one needs specific functionality but for which there are no equivalent asics.

[Dieter]

> If you want a fpga based graphics card you should look at the open graphics project.

http://www.traversaltech.com/

[popper]

the reason i mentioned FPGAs in passing was not for looking into making the whole core of the gfx card ,but rather finally tapping into the far broader mass markets were many gfx apps and datasets could benefit IF there were an FPGA put on a common board such as a gfx card or a common a garden motherboard for instance...

NV and ATI are using a static ASIC today for their blackbox video engine, i think FPGA in this case would be better (other than as Bridgeman outlined as space in your blackbox video AV SOC [System On a Chip]) OC

the "Fpgas use much more power,silicon, and are less powerful than an equivalent asic" doesnt seem to be the case as much today, for instance this

http://www.videsignline.com/products/212501012;jsessionid=BAZHTTSN1ARPSQSNDLPCKH0CJUNN2 JVN

true its a large chip but its billed as "... are claimed to offer the industry's largest density, highest performance, highest system bandwidth, and lowest power among high-end FPGA solutions. "

they as you might expect also offer conversion to Altera's transceiver-based HardCopy IV GX ASICs.

but thats not my point, if all your new HW has a generally available FPGA onboard, making just as common as a USB port, than you can start to use that to set yourself apart on the mass market, and offer lots of innovative ways for your customersbase to interact with that FPGA(s)for their own use for instance.

im trying to get away from the old school thinking, prototype on FPGA and copy to your slighty cheaper static mass ASIC, to later find you need to fix a bug or limitation you didnt imagine, and run off a new batch/revision.

using FPGAs in all your kit could remove that problem and be used to bring that convenience to the masses of home devs and also give you the ability to fix your design errors/limitations later.

in the case above as bridgeman says OC, it increases die area in a specialist SOC so its not as versitile for that case, but theres nothing stopping you putting a seperate off the shelf version on your main PCB and linking it in to your main SOC that way to use as you see fit .....

generally speaking its become cheaper now to take other peoples SOC, and mix and match them to get your desired end result, rather than have the ASIC made yourself, so its just the logical step to forget the limited static ASIC and just use flexable FPGAs on mass to bring the prices down there, they are as fast or faster and would only get better as CPU and Gfx did, if HW vendors started using them on mass in the PC realm.

or thats how i see it today, and how it could be tomorrow with some insight and innovative thinking ;)

i like this http://www.pldesignline.com/ for getting you thinking...

if you wanted to get real twisted OC theres also the KiloCORE PPC based FPGA with 256 and 1024 cores from way back in 2006 , mixed PPC/Altivec and x86 now thats a sure fire headline even today ;)

http://www.rapportincorporated.com/pdfs/Rapport%20-%20Kilocore%20Development%20Platform.pdf

[clavko]

Might be considered ranting, rather than helping but...

Where exactly lays linux appeal for the average Windows convertee
(being one myself)? Can't play some fancy 3d games, ok, I can live
with that. Must learn a lot about things I never even knew they were
needed. For example - what's the thing with XRandR - everyone gets
excited about (gasp!) changing resolution, multiple displays and
rotating them? Well that's an amazing feature - guess it shouldn't be
had for granted in the third millenium.

Going on - want to play mp3? Good luck finding your way through names
like GStreamer, Xine, Phonon, PulseAudio... Fancy window rendering?
No problem, first you got to install fglrx or radeonhd or radeon or ati
and then configure your Composite flag in xorg.conf, but you can't do
it if you don't su/sudo first. Fglrx? Fglrx? WTF is fglrx? Compiz?
Metacity? Kwin? People, I just want them kube rotatin'n'shit :)

ACPI on laptops? hald, acpid - there's always something wrong with them,
deeper C states on processors have problems, can't have power managenent
on laptop IGP's (without fglrx), standby and hibernate woes.

OK - most of regular Redmond-style users quit at this point. Me - not.
I read, I learned, compiled quite a bit, changed text files, patched,
recompiled. Slow and steady - one day I'll even manage to do it all
without a blink. Not so soon, though.

But... at the end of the day - what do I get, where's the satisfaction?
Can't play games - checked. Can't have video under compiz - checked.
Can't do web developing right (IEs4linux - not so good, flash?)- checked.
Can't play shockwave game online during break - checked. But wait!
I can watch my HD H-264 DVB-T TV broadcast and trailers - NOT.

I always considered linux to be a kind of OS that is smart about
resources. You know - doing things the way they should be done.
If you got a specialized hardware to do some kind of work - use it,
optimize, optimize, optimize. Come on... an i810 integrated graphics
has working XvMC. If it is such a hassle to program a working MPEG2
acceleration on a modern graphic processor (and it seems it is), then
what's the point? Where is that magical area that linux excels at -
compiling stuff? Watching DVD on a console framebuffer? Showing some
other friend wobbly windows?

I know what's the answer - why don't you do something yourself? Yup,
criticism is hard to take when you're doing all the work. I respect
that. And I promise I won't give you a "But,...". Just a thought.

[popper]

" I just want them kube rotatin'n'shit
"

ROTFL

[BlackStar]

[...] then what's the point? Where is that magical area that linux excels at [...]

Choice.

This is a system that can scale from paltry router hardware (100MHz processor, 4MB flash) all the way to clusters with thousands of processors. You can choose exactly how you want your system to work, what software to run and how the software will look like.

I'm not saying this power comes for free - you've seen the price. I'm also not saying this is something most people want or need - but it's there if you need it.

However, Linux is steadily getting better, bit by bit. 2008 brought major improvements to wireless and video drivers, the two major pains. Most companies have now released or have promised to release specs for their hardware. The UI is improving (compare KDE 4 to 3 or Gnome 2.24 to 2.16 if you want proof). More programs see ports or can be adapted to run under wine. 2009 will hopefully bring massive improvements to video support - the pieces are already set.

We won't see masses of people switching overnight (people never like change, XP vs Vista anyone?), but as Linux becomes more and more viable, the more adapters it will gain. In fact I was quite surprised at how many people switched in my immediate environment, expressed they liked the change and never went back.

I agree it gets frustrating at times and I certainly share your pain about video playback, flash support and certain development tools. However, I look forward to the (hypothetical) day when I'll be able to go to a shop and buy a computer with Linux installed by default ("Do you want windows? It's only 80€ more.") :)

[agd5f]

As has been stated before, it's a resource issue. Windows has 90% of the desktop market; linux is like 1-2%. I'd love to support video decode and 3d and advanced power management, etc., but these tasks are non-trivial (especially considering how complex gfx hardware is nowadays) and there are only a handful of active developers.

[Porter]

The ideal solution is to have access to the dedicated hardware we all put in our chips to support BluRay playback. Unfortunately that hardware is also wrapped up in bad scary DRM stuff so making it available on Linux is a slow and painful process.

It seems as though the graphics hardware manufacturers should spend more time lobbying US legislators, both to repeal the DMCA and preferably to ban DRM outright. It's a boat anchor on the tech industry, it hobbles the pace of technical innovation, and everyone knows it.

Seriously... looking at the resources involved in driver development (for all platforms) to deal with DRM in one fashion or another, the lobbying efforts might be time and money better spent... if DRM is taken out of the picture, then anyone could use your fancy dedicated hardware on any system without any lawyers having a hemorrhoid over the whole thing. Which, frankly, would raise the intrinsic value and usefulness of your hardware product.

[MU_Engineer]

It seems as though the graphics hardware manufacturers should spend more time lobbying US legislators, both to repeal the DMCA and preferably to ban DRM outright. It's a boat anchor on the tech industry, it hobbles the pace of technical innovation, and everyone knows it.

Seriously... looking at the resources involved in driver development (for all platforms) to deal with DRM in one fashion or another, the lobbying efforts might be time and money better spent... if DRM is taken out of the picture, then anyone could use your fancy dedicated hardware on any system without any lawyers having a hemorrhoid over the whole thing. Which, frankly, would raise the intrinsic value and usefulness of your hardware product.

I am not a lawyer (oh GOD no I am not a lawyer!), but if my interpretation of 17 USC section 117 (the "fair use" section of the U.S. copyright laws) is anywhere near correct, you could argue that DRM is already illegal as it prevents users from backing up media or programs, moving the software to a new machine, or copying for educational and research purposes, all of which are rights granted to the users of the copyrighted works.

[clavko]

Choice.

Yup, choice. And I choose to stay here, I've been hooked. And since
I'm already here I decided to dump the current state of my feelings
registers, before I get too comfortable to be considered a typical
Microsoft product user ("Do you hear that, Mr. Anderson?").

I hope there's no hard feelings - I know some of you guys and girls
are really doing your best. Think of it as a form of "Come on, you're
the best - now act like it, damnit!". In the meantime I'll be working
on my degree and find a way or two to help. Just... throw us something
here and there to keep us excited ;)

[Dieter]

>>> XvMC is a bit hit and miss on the Via chipsets as to
>>> whether the drivers support it or not. It is being
>>> actively worked on for the openChrome drivers...
>>
>> Is there a chart somewhere showing which features
>> openChrome supports on which Via chips? Perhaps similar to
>>
>> http://www.x.org/wiki/RadeonFeature
>
> Not that I am aware off...
>
> Though that might be something I could manage to arrange if
> the openchrome devs don't kill me for all my questions...

Where should I watch for this? On the x.org wiki?

BTW, ATI should create charts for the Rage and Fire* families.

[rvdboom]

According to this news : http://www.phoronix.com/scan.php?page=news_item&px=NzAwNA, there seems to be work to accelerate video directly in Gallium3D.
Wouldn't that make kind of obsolete any XVMC or equivalent development? Wouldn't it be a more interesting way to help developping these features and make sure they work well with ATI?

[TechMage89]

Actually, that's an implementation of XvMC. The API is still important.

However, that ought to work on ATI cards once there is a working Gallium driver. The downside however, is that it won't be as low-power or fast as using the hardware decoders.

[bridgman]

So far I think the implementation only covers MC (the XvMC API covers MC-only or IDCT+MC).

For GPUs with dedicated IDCT hardware it may turn out to be easier to integrate the IDCT and MC processing with a native XvMC implementation. Most of the Radeon family parts have some additional logic to coordinate IDCT (on dedicated HW) and MC (on shaders) processing, but I don't think that would work if the MC part were being done through Gallium.

[popper]

it seems that XvMC and UVD is getting left far behind as devs work daily on all the other non UVD ASIC hardware/APIs, realisticly, is it simply to late for them now?, do any ATI coders care about UVD API anymore?, and if so what timelines can we expect some working usable code ?, a simple ? frame accurate FFMPEG patch seems to be all thats required to get at least some interest from 3rd partys, but perhaps im missing something fundimental and need it spelling out , no docs (for months to come), no interest, seems to be the basic problem here.

http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-January/060522.html

" Gwenolé Beauchesne gbeauchesne at ......com
Thu Jan 29 17:01:18 CET 2009

Previous message: [FFmpeg-devel] [PATCH] h264.c: space fix
Next message: [FFmpeg-devel] [PATCH][0/8] VA API patches summary
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

--------------------------------------------------------------------------------

Hi,

The upcoming patches add VA API support to FFmpeg. They rely on libVA
changes that are not upstream yet, though the maintainer agreed to
integrate them for a future release. Those changes are actually
extensions (new fields) to suit the needs of XvBA and VDPAU backends.
You can get the current libVA patchset here: .....

VA API currently covers the following codecs:
- MPEG-2
- MPEG-4
- H.263 (MPEG-4 part-2 short video header format)
- H.264
- VC-1

Regards,
Gwenole.
"

[bridgman]

no docs (for months to come), no interest, seems to be the basic problem here.

Docs required for XvMC on 5xx and earlier have been out for almost a year; docs and sample code for 6xx/7xx are out now.

I don't think it's so much lack of interest as much as higher priorities in the short term; our devs are working on 3D and (hopefully soon) power management; the main community devs are working on kernel modesetting, memory management and Gallium3D.

[mirak63]

I was playing MPEG2 fine even on my old Pentium 2 400MHz! That's not a "modern" CPU by any stretch of the imagination. People are interested about MPEG4 formats and think MC is going to help them.

are you sure it was on linux and not windows ?
because even right now, I can't play a DVD or a DVB stream on a powerpc G4 400mhz or a celeron coppermine 700mhz.

[curaga]

Perhaps you don't have the right accel? XV should be quite enough.
Vesa+vidix should be even lighter, that's what geexbox used to use, and it played dvd's and dvd-res divx/xvid just fine on my P2 333Mhz.

(It's Mplayer, the comp in question has a Rage Pro Agp 2x, and 192mb ram)

[MU_Engineer]

Perhaps you don't have the right accel? XV should be quite enough.
Vesa+vidix should be even lighter, that's what geexbox used to use, and it played dvd's and dvd-res divx/xvid just fine on my P2 333Mhz.

(It's Mplayer, the comp in question has a Rage Pro Agp 2x, and 192mb ram)

In my experience, playing back a 720x480 MPEG-2 file using Xv takes something like a 500 MHz CPU to accomplish. My old HTPC setup consisted of a 900 MHz Celeron Coppermine and an NVIDIA 6200 PCI and it took roughly 50% of the CPU to play back 720x480 MPEG-2 files using Xv. If you use XvMC, you could probably get by with a 300 MHz PII or K6.

H.264/MPEG-4 or HD resolution video is a much different matter. You need something close to 1 GHz to play back 720x480 MPEG-4/H.264 files smoothly using Xv or 1080 MPEG-2 HDTV with XvMC. It's more like 1.4-1.8 GHz to do 1080 MPEG-2 HDTV with Xv and a 3 GHz Core 2 or Phenom to do 1080 H.264/MPEG-4 HDTV using Xv. I've only ever used one machine personally that can play back 1080p H.264 smoothly using Xvideo and that was a 2.8 GHz Phenom II X4 920 and even then one core was just about pegged doing the decode.