AMD Releases Open-Source R600/700 3D Code

[rampage7]

I've wanted to try it by myself, but I've got some errors:

(EE) RADEONHD(0): RHDDRIVersionCheck: symbol GlxSetVisualConfigs not available.
(WW) RADEONHD(0): RHDDRIPreInit: Version check failed. Disabling DRI.

My system is Gentoo x86-64, xorg-server 1.5, 2.6.28 kernel with DRI module enabled, with mesa and radeonhd drivers from git repositories.
Have anybody some ideas about that errors?

[Louise]

I just read this blog post, about IBM should open source Domino.

http://feeds.feedburner.com/~r/stormy/~3/498752213/is-open-sourcing-domino-a-good-idea.html

Notice the none disclosure part. Scary stuff!

I guess AMD was faced with the same problems, and therefore choose to write the code that we now got :)

[DeepDayze]

Dual P4 2.66 GHz Xeon, 2 GB RAM, non-standard ATX power supply...

I hate throwing away perfectly useful and fully working hardware. And besides, the 4670's reduced power consumption makes it an ideal "final" upgrade for this machine.



That's surely up to your hardware partners! I'm hardly likely to magic an AGP version of anything out of my (err)"boat". (Or similar... ;-).)

For your rig, get an nVidia 7800..that's the final upgrade for it as it's the best card in AGP format ;)

[RealNC]

For your rig, get an nVidia 7800..that's the final upgrade for it as it's the best card in AGP format ;)

Nope, there's also an HD3870 AGP :D

[elanthis]

Do they have magical way to count every Linux machine? If someone buys computer with Windows and then he replaces that system to Linux only Windows is counted. Not only market share matters but quality.

Yes, actually. Sales aren't counted so much as average web browser statistics from a number of sites. Your browser reports the OS and CPU architecture along with the browser version, you know.

Some sites are obviously skewed (e.g., Phoronix), but when you take a large cut of websites and average out the results you can get a fairly accurate picture of the OS landscape.

[DoDoENT]

Let me tell you, I'm a Mobility X1600 camper and so far I'm happy with the open-source driver.

PowerPlay is WIP, as John mentioned, don't worry.

I will happily play Nexuiz with the crappy OpenGL 1.3 implementation of this driver anyday over fglrx that hangs my computer upon exiting Nexuiz.

Compiz is waaaaaaaaaaaaay faster than what fglrx delivers. 2d is waaaaaaaaaaaaaay faster. Even probably OGL 1.3 is faster than OGL 1.3 in fglrx.

Tear-freaking-free video playback!
Flicker-freaking-free video playback with compiz!

So to me, why you use fglrx, is a bit unjustified when you have in mind all the goodies coming in 2009 like Gallium, KMS, DRI2.

I will not be using fglrx anytime soon, even if they decode video with the GPU, but that won't be possible on r500 anyway. Fglrx is just one long, boring drag. I've had enough of it.

After reading your post, I've given another chance to the radeon driver... and I felt very disappointed. Nexuiz is slow, scorched3d unplayable, and glxgears gives only 1700 FPS (fglrx gives over 3000). Yes, with fglrx Nexuiz makes a mess from my screen resolution, but I solved that by playing nexuiz on 1680x1050 (which is my desktop resolution), and it WORKS well on that resolution (with radeon is slooow).

The only better thing in radeon is faster X startup and a lot faster suspend and resume process, but I think this will be solved in fglrx with the time too. After all, fglrx is consisted of both open and closed source code (as far as I know).

And I didn't experience any faster 2d performance with radeon than with fglrx. The video acceleration is the same. The only difference is when I turn on compiz effects - then fglrx makes no 2d acceleration at all, and radeon 2d performance is faster. But with compiz turned off, radeon driver is no match for fglrx, except in multi-monitor support. In multi-monitor support, radeon driver is a lot better, but since I use my laptop mostly for browsing the web, watching videos, gaming and for study, I rarely use multi-monitor feature.

So, to conclude, fglrx is an excellent driver for me (in comparison what it used to be one year ago).

Happy New Year to everyone!!!

[d2kx]

DoDoENT: Did you enable EXA for acceleration? I don't know why it is not the default option as even the Xorg.0.log advises you to do so. 2D acceleration with Xserver-stable which is 1.5 is better with EXA than fglrx, but it is insane with Xserver-unstable which will become 1.6.

Great improvements coming this year ;)

[DoDoENT]

DoDoENT: Did you enable EXA for acceleration? I don't know why it is not the default option as even the Xorg.0.log advises you to do so. 2D acceleration with Xserver-stable which is 1.5 is better with EXA than fglrx, but it is insane with Xserver-unstable which will become 1.6.

Great improvements coming this year ;)

Yes, I do have EXA enabled. Here is my xorg.conf configuration which I used with the radeon driver:

Section "Monitor"
Identifier "Configured Monitor"
EndSection

Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Configured Video Device"
SubSection "Display"
Virtual 2704 1050
EndSubSection
EndSection

Section "Device"
Identifier "Configured Video Device"
Option "AccelMethod" "EXA"
Option "DynamicClocks" "on"
EndSection

I didn't say that radeon's video acceleration is slow. I just said that fglrx's video acceleration is no slower than radeon's video acceleration. At least in my case: I used intrepid ibex's default radeon driver and catalyst 8.12 in my comparison.

[popper]

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.

forgive me for my slapdash long post, times short and i feel you need to consider all these points and take something of them away
with you and the AMD/ATI crews, and give people what they want and need, they did buy the X1xxx/HD2/3650 etc on the PR sales pitch
that they would get hardware assisted Encoding AVIVO HW some day, not just the newest HD4xxxx remember...

bridgman, all due respect to you and your team etc but YOU really need to get out of the developers cave more, ;)

it feels like your surounded by YES men, and no one wants to tell you this, but its is not 2000 anymore, and you seem to
have totally misread the current wants and needs for todays video users and part time video app coders etc.

theres a reason the AVIVO Encoder inside the MS driverset got a lukewarm reception world wide, and its not so much because of the lack of
real hardware assistance in it (ATI did sell X1xxx,HD2.3650 etc as getting GPU hardware assisted ENCODING though and still its doesnt)
, but rather the total lack of end user tweakability of the encoding parameters etc for 360/ps3 playback if you will,
thats getting your focus point totally wrong.

heres what you need to focus on _TODAY_
get some working code out that your average coders and users can see will benefit them ASAP and encurage them to drop the NV only
librays their code is now supporting and start using the likes of the ATI/AMD framework http://sourceforge.net/forum/forum.php?forum_id=764939 .

TODAY the most basic requirement for all the video users and part time coders of x264 and libavcodec/FFMPEG/VLC users world wide is
AVCHD, MBAFF and PAFF decoder options at the very least, curently AMD/ATI are getting forgotten as NV give these people the tools and
librays to do these most basic things and work with their video Encoding....

its simple , forget your ""classic use case" for XvMC was European digital TV" thats long past as the UK (sky),EU and far east moved
or are moving to AVC DVB containers, thats were you need to focus right now,"MBAFF and PAFF" and TS (transport stream) being the key
requirement right now as the major libavcodec/FFMPEG codebase that all the popular video apps use today doesnt do "MBAFF and PAFF"
or AVCHD to well today, and seriously needs to use hardware decoding programatical assistance ASAP, your key use of time right now
would be to simply work with and send in an AMD/ATI HD3650+ hardware patch to the developers at
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-January/thread.html developers message board
and sit back as that massive news hits the doom9 and other related message boards and people start downloading and using your ATI libarys
the very next day to add hardware assisted AVC,VC1, and even antiquated Mpeg2 decoding, and perhaps even Encoding and transcoding
into other containers etc....

put simply theres FAR MORE people intersted in ATI/AMD "MBAFF and PAFF",Decoding, ENCODODING, and transcoding to and from other containers
than anything you have written above, that is the focus you should be trying to gather interest around inside AMD/ATI circles with the
X1xxx/HD2/3650/4xxxx GFX cards capabilitys, WE need real working sample code for "MBAFF and PAFF" hardware assisted decoding patchs for
libavcodec at the very least.

a massive or even smaller but better than realtime code drop to the libavcodec/FFMPEG code base developers board
http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2008-December/018442.html
, not to mention the likes of http://www.kdenlive.org and ther linux video editing app thats trying to work with and find
working AVCHD HDcam support for editing could benefit massively if you just took the time to read up and help out TODAY, and make
AMD/ATI the talking point for weeks to come on the likes of the AVC focused http://forum.doom9.org/forumdisplay.php?f=77 threads
http://forum.doom9.org/showthread.php?t=143744&page=6 threads.

for to long the focus has been 3D with linux, wereas today it should really be GPU assisted video ENCODING and other related apps,
NV ARE taking the spotlight today because of that re-focus, and so your seeing the likes of ATI's
http://forums.amd.com/forum/categories.cfm?catid=328 being forgotten .part time coders want easy access to fully working
APIs that make todays HD video Encoding/Decoding work better and faster make that happen and go talk live and in person with them
on the message boards nad you will sell an lot of Gfx cards they can finally use, no matter what OS.


will you infact be including these essential MBAFF and PAFF decoder options in your base example code/apps.

http://en.wikipedia.org/wiki/H.264
"Flexible interlaced-scan video coding features, including:
Macroblock-adaptive frame-field (MBAFF) coding, using a macroblock pair structure for pictures coded as frames,
allowing 16×16 macroblocks in field mode (compared with 16×8 half-macroblocks in MPEG-2).

Picture-adaptive frame-field coding (PAFF or PicAFF) allowing a freely-selected mixture of pictures coded as MBAFF frames
with pictures coded as individual single fields (half frames) of interlaced video.
"

key points, you need to do a HW assisted GIT patched code drop to libavcodec, and include "MBAFF and PAFF" decoder options
therin, perhaps also AVCHD, and lossless Intra too, as per the latest x264 software freeware encoder etc....


as a side note to your assumed DVB Europe and the antiquated Mpeg2 you might want to read up on this.
DVB-SCENE27.pdf shows you the realitys of were its all going soon enough, and less than stadard H@L4.1, divx7 20Mbit max isnt it for your average end users paying the bills, and buying the kit to make your longterm profits, outside the US OC.

http://www.dvb.org/news_events/dvbsc...VB-SCENE27.pdf

page 4 of 16
"DVB-S2 Enables 140 Mbps Super Hi-Vision By Satellite At IBC 2008
Dr Alberto Morello,
Director of RAI Research and Technology Innovation Centre, Turin, Italy & Chairman of DVB TM-S2 Group

One of the highlights of this year’s IBC in Amsterdam is the first broadcast, live by satellite, of Super Hi-Vision (SHV)
using DVB-S2, from the RAI Research up-link station in Turin.

SHV, the 4000 line x 8000 pixels/line television system under development by NHK,"

Since the native SHV signal bit rate is a massive 24 Gbit/s, the major part of the challenge has been in developing technical ways of delivering the service to the final user. SHV is in our case compressed using MPEG-4 AVC at a final bit-rate of around 140 Mbit/sand delivered to IBC in Amsterdam from the up-link station of the research headquarters of Italian public broadcaster RAI in Turin, over Ku-band satellite capacity provided by Eutelsat.
"

[popper]

> > 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?

thats the day those USA people turn off analogue and start using Digital i assume!.

the US version isnt as popular as DVB-T and the rest of the DVB spec around the world today OC, and thats why when you talk about developers, you are forgatting almost everyone through nessesity are uing MS OS and NV freeware tools to make and process their DVB contained AVC Encodings....

the fact is as sad is it may be, unless AMD/ATI start helping out and encuraging (PPC) linux devs to start using the likes of the http://sourceforge.net/forum/forum.php?forum_id=764939

and http://forums.amd.com/forum/categories.cfm?catid=328
to write/port the required freeware Video apps and can help in the HW assisted "MBAFF and PAFF decoder options and AVCHD departments, we are not going anywere fast.....today.


and make it extreamy simple to use

[popper]

Congrats on finaly showing of the docs.

I'm sure in a few years the driver could be very useful. (No sarcarms intended.)

I like to highlight the need for supporting the XvMC API.

1. Did you forget what codec that's in DVD ? :) -> Mpeg2
2. Did you forget that most legacy cam recorders record in Mpeg2 ?
3. Did you forget that many applications such as Mythtv, Xine, Mplayer etc have good and useful support for this API ?

I also like to pinpoint that bulding an HTPC mediacenter based on ATI cards are terrible ? I worked with it for an hole year with an ATI2600 card and after picking up an used Nvidia 6600 I got an hole new life.

But yes, I'm in Euro and while there are a few Channels having an H.264 streams in the ts, most are still Mpeg2.

But yeah, I welcome something like VDPAU for ATI cards, but there are to many bugs with the curent closed driver and mythtv that should be fixed first.

Cheers and thanks for the hard work.

I might swap my Nvidia card when you catch up with them :)

sure, in the Uk DVB-T is still using Mpeg2 in their SD TS (transport streams, but....
4: Did you forget that Sky use HD AVC (Mpeg4 part10/aka Mpeg4-AVC)
5: Did you forget that todays HD cams use primarily AVCHD inside a TS.
6: Did you forget that BBC HD use MBAFF and PAFF decoder options on their HD AVC TS streams and ATI hardware can decode that fine, were FFMPEG software cant (very well or fast).

7:linux HD Editing software such as http://www.kdenlive.org/ are activly tying to support the new AVCHD, lossless AVC Intra
in their transcoding.

8: Did you forget that AVC intra, is now supported by the cross platform x264 software encoder, and that the CoreAVC decoder codec supported that decoding, linux software decoding of Intra is very limited and in desperate need of ATI to openly support it better than NV are doing now....

9:did you forget about the recent "http://www.dvb.org/news_events/dvbsc...VB-SCENE27.pdf

page 4 of 16
"DVB-S2 Enables 140 Mbps Super Hi-Vision By Satellite At IBC 2008
Dr Alberto Morello,
Director of RAI Research and Technology Innovation Centre, Turin, Italy & Chairman of DVB TM-S2 Group

One of the highlights of this year’s IBC in Amsterdam is the first broadcast, live by satellite, of Super Hi-Vision (SHV)
using DVB-S2, from the RAI Research up-link station in Turin.

SHV, the 4000 line x 8000 pixels/line television system under development by NHK,"
"
etc
etc

perhaps you might like to have a read of these Mpeg4-part10 aka AVC papers to get to to speed of were the current spec is today and in the near future the world DVB AVC inside TS is going.

http://www.chiariglione.org/mpeg/working_documents.htm#MPEG-4

[popper]

Did you forget that any CPU, even an old Pentium 2, can handle that? :P Even on Windows, where the drivers support everything, MPEG2 acceleration is not used by most people because it's totally unnecessary. They prefer software decoding due to the software being able to enhance the picture that way.

LOl, the old "Did you forget " assuming we know it to begin with OC. :)

Did you forget that P2 is for old SD PAL CIF and the like, NOT for the HD Mpeg2 at 720P/1080P you get and use today.

for high bitrate (we are talking 20Mbit+/s)Mpeg2 720P/1080P you cant do without at least an AMD 2100+

remember also, many HD Video end user people this year will buying arcade xbox360's as their cheap for HD TV HDvideo steaming now, or PS3 if you want to pay more OC.

and they do AVC, Vc1(divX with bells on) and OC Mpeg2 hardware playback fed through the likes of TVersity streaming on windows, alas theres nothing like that self contained GUI, stranscoding etc for linux as yet.....

here an old list of the codecs and containers you can use for these HD streams that the ATI COULD assist you in making and processing IF THEY coded up some working code samples for people to use and learn from...

http://a8t8.spaces.live.com/blog/cns!2518DD508BB713E8!188.entry

[bridgman]

The GPU-dependent code for motion comp isn't really much different from the Xv code we have already pushed into radeon and radeonhd. The actual processing is different (you're dealing at a block level rather than a frame level) but that is largely hardware-independent.

I just think that developer time would be better spent working on an implementation which could also support H.264 and VC-1 rather than putting time into something that only handles MPEG2 and needs a rewrite to support anything else.

[popper]

The GPU-dependent code for motion comp isn't really much different from the Xv code we have already pushed into radeon and radeonhd. The actual processing is different (you're dealing at a block level rather than a frame level) but that is largely hardware-independent.

I just think that developer time would be better spent working on an implementation which could also support H.264 and VC-1 rather than putting time into something that only handles MPEG2 and needs a rewrite to support anything else.

indeed, the old antiquates Mpeg2 doesnt concern me, what does concern me OC is the fact NV have make a simplistic libray that the windows part time coders and GUI video app writers are taking advantage of.

wereas the ATI/AMD librays while lower level and apparently fuller are not being used , infact are being ignored on the likes of doom9 were all the windows freeware AVC,vc1,transcoding etc apps happen...

they just dont want to try and use the raw framewave library
http://sourceforge.net/forum/forum.php?forum_id=764939

http://forums.amd.com/forum/categories.cfm?catid=328

all they need to begin with to finally start using the AMD/ATI open librays is a basic libary that suits their basic needs.

that need is simply AVC Encoding,MBAFF and PAFF ,AVCHD decoder options and perhaps AVC intra lossless processing,and vc1.

it doesnt even need to be fancy,for ATI to catch up all that would be required would be for ATI/AMD to write the hardware assisted decoding and DIFF against the current FFMPEG/libavcodec codebase and people can finally have good reason to buy and use the X1xxx/HD3650/HD4xxx

http://svn.mplayerhq.hu/ffmpeg/trunk/libavcodec/?view=log

put simply until someone preferably ATI give linux the only real option for Hardware decoding AVC,MBAFF and PAFF ,inside FFMPEG at the very least port and post the diff at
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-January/thread.html we as ATI advocates are going nowere.

[popper]

The GPU-dependent code for motion comp isn't really much different from the Xv code we have already pushed into radeon and radeonhd. The actual processing is different (you're dealing at a block level rather than a frame level) but that is largely hardware-independent.

I just think that developer time would be better spent working on an implementation which could also support H.264 and VC-1 rather than putting time into something that only handles MPEG2 and needs a rewrite to support anything else.

Mpeg2 isnt the problem OC , ,MBAFF and PAFF ,AVC decoding in linux is, porting any ATI code to libavcodec
is the only real option go kickstart the uptake today...

id advisable that someone writes some basic working HW ATO decoding code and posts the diff at http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-January/thread.html

[popper]

sure ,but AVC MBAFF and PAFF decoder options coded to the libavcodec/FFMPEG codebase is the only real option to linux users today.

and as you know , thats not great in software right now, only the current NV library everyone in doom9's useing and writing for right now, or perhaps something the ATI/AMD team might write ASAP and diff against the current libavcodec/FFMPEG codebase and post on the http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-January/thread.html
for all to see and talk about (theres major good PR in doing that simple thing OC) that might finally get the http://forum.doom9.org/forumdisplay.php?f=77 sections porting the free HD AVC video apps back to linux again....

and any improvement in libavcodec/FFMPEG HW assisted ati code might even be a very good thing for the likes of
http://www.kdenlive.org/kdenlive-nvidia-vdpau-ffmpeg-patch, the only linux video editor thats trying to promote lossless AVCHD cam file editing today it seems.

its apparent the doom9 video app coders and GUI creaters like the NV libray as it caters to their simple needs at a high level, one of the doom9 devs said the http://sourceforge.net/forum/forum.php?forum_id=764939 framewave libray
http://forums.amd.com/forum/categories.cfm?catid=328
is to low level,and to much work for part time HD app coders that dont currently own ATI HD cards,and see no reason to buy them right now as the NV libray works for them, whatever that means!

[bridgman]

sure, but WE'RE NOT THE ONLY ONES WHO CAN WRITE OPEN SOURCE DRIVERS :eek:

(y'know, that smiley should be called "rant", not "eek" :D)

Our commitment is to get enough technical information and sample code into the development community to enable the development of well featured, decently performing, and reliable drivers, and to provide support to developers to help fill any gaps. We also figure out how the new chips work and either write sample code for the community or just add the new GPU support ourselves.

For years the development community said "give us the specs, we'll write the drivers". We are providing the specs, and in fairness the development community is working on drivers. We also help write the drivers when time permits; Alex added both EXA Render and Xv support to the current driver stack. We also partnered with Novell to get the initial driver support for 5xx/6xx written, as well as the sample 3D code for 6xx/7xx. But please don't wait for us -- the code is there and the information is there -- anyone can add to or enhance the drivers.

[popper]

sure, but seeding your better ATI codebase for AVC MBAFF and PAFF decoder options coded to the libavcodec/FFMPEG codebase can only be a very good thing for all concerned.

its all about prioritys OC, and these Open source coders are advocating NV right now, and thats a very bad thing as all the popular apps dont currently use any ATI HW assistance, and is stopping people buying the far better ATI HW decoding GFX for mass market home HD video work.

thats a crying shame and id like to see that change as i have several X1/HD GFX cards that could take off but for some working sample libavcodec/FFMPEG code to match or better NVs current libavcodec/FFMPEG diff....

[bridgman]

OK, I'm confused. Are you talking about open source or proprietary NVidia drivers here ?

I looked all through the links and didn't see any reference to the "NV library" you mentioned.

You linked to both Framewave (which is a CPU math lib) and Stream (which is a GPU programming environment); which were you talking about ?

The other thing I don't understand is how we got onto AVC/H.264 and VC-1 in the first place. The only discussion in the thread was about whether it was worth implementing XvMC, which is currently MPEG2-only, and whether MPEG2 decoding placed enough load on the system to justify implementing XvMC.

I think we all agree that support is meeded for the more demanding formats, particularly H.264. The question *there* is whether that is a higher priority than 3D support, which is what we are working on now. I would argue that 3D support should remain the top priority, and after that we should look at H.264 support if someone has not already done it.

I'm still not clear whether you were talking about the open or proprietary NVidia drivers, though, or what that "NV library" referred to. If you're talking about transcoding apps accelerated through CUDA or Stream, that's all going to end up running over OpenCL soon on all platforms, ie ffmpeg would code to the OpenCL standard not to anything vendor-specific.

[popper]

i know its rather confusing LOL, i dont mean to make you rant, but in HD AVC,VC1,etc video work its clear both CPU and GPU library improvements are a good thing to advocate (PPC linux doesnt use the altivec SIMD for anything for instance, such a waste, PS3 PPC linux could make very good use of SIMD for instance).

my real concern right now is that NV have got the HW assist mindshare in the home video coder market right now, and ATi are nowere to be seen in that space,but perhaps you dont see it!

the simple option and masses of good PR is for some devs to take what your current offering in both better CPU and especialy GPU assisted Encoding/Decoding and trancoding and work with the libavcodec/FFMPEG codebase .

that gives every single app that currently uses libavcodec/FFMPEG codebase a boost, gets ATI some needed PR outside the specialist news outlets and gives the home devs some good working base code to take, learn and expand for eveyone long term good,.

its pritty simple, if you are using linux your using some libavcodec/FFMPEG codebase in at least one of your main apps, as are many other OS's including windows OC....

id prefer if that dev team were your ATI team as leads, as its in your long term interests to do so, and so far no other devs seem that interested right now even though the end user demand would love the ATI HW assited video procesing to help them process their AVC HD video better than real time preferably....

[bridgman]

I honestly still have no idea what you are talking about. WHAT IS THE NV LIBRARY YOU ARE SAYING WE NEED TO COMPETE WITH ?

When you talk about our technology, I *think* you're talking about our transcoding app, which runs over the Stream tools on the proprietary driver, so maybe you're also talking about ffmpeg using CUDA over the NVidia proprietary driver today ?

[bridgman]

I'm sorry, I just spent another half hour going through the links you posted and I still have no idea what that "NV library" is. It seems pretty clear that you want us to add GPU-assisted transcoding to the ffmpeg stack but I don't think anything like that exists for NVidia today either, so presumably we're talking about something else ??

Hopefully you can shed some light. Will check back in the morning.

[Nille]

I'm sorry, I just spent another half hour going through the links you posted and I still have no idea what that "NV library" is. It seems pretty clear that you want us to add GPU-assisted transcoding to the ffmpeg stack but I don't think anything like that exists for NVidia today either, so presumably we're talking about something else ??

Hopefully you can shed some light. Will check back in the morning.


Maybe he mean VDPAU from NV. ATI has Currently no real HW Acceleration and for XvBA there are no headers or smt like that for use it ( if its Wrong im sorry but i cant find anything about this) .

[popper]

:eek: why :angry: , OC its Stream and CUDA, unless theres another set of APIs im not aware of as yet, not every reader here or elsware have degrees in computer sciences as i assume you do, but thats no reason to be getting angree at people :eek:

Don/neuron2 that produces the DGAVCDecNV and DGVC1DecNV
http://forum.doom9.org/showthread.php?t=141104
http://forum.doom9.org/showthread.php?t=142961

said to me ..."Nvidia has a fine video decoding library and so I make use of it because libavcodec has problems that make it unsuitable for continued development.

So, for me, it's just going to be Nvidia, unless and until ATI make available a video decoding library, and not just a bunch of low-level functions.

Don "

and that seems to be the general feeling in the doom9 and other related messageboards threads, clearly someone in ATI needs to convince these developers of the popular video apps, to work with and provide mentoring and feedback.

the same for the linux HD video devs too, its not rocket science and no need to get or show anger here, you dont need to agree with my oppinion OC, mearly take it into consideration, and perhaps profit from it in the long term with better focus to those devs that can help advocate and produce long term apps results or continue on the current path and have these devs and users ignore ATI as they are doing now....

[Nille]

......


do you mean VDPAU from Nvidia ? ATI has SMT like this longer as Nvidia ;) but not announced yet or give header files :( http://www.phoronix.com/scan.php?page=article&item=amd_xvmc_xvba&num=1

[smitty3268]

I'm sorry, I just spent another half hour going through the links you posted and I still have no idea what that "NV library" is. It seems pretty clear that you want us to add GPU-assisted transcoding to the ffmpeg stack but I don't think anything like that exists for NVidia today either, so presumably we're talking about something else ??

Hopefully you can shed some light. Will check back in the morning.

I'm guessing he's just talking about VDPAU, I wouldn't worry about trying to decode that rambling if I were you.

[popper]

Maybe he mean VDPAU from NV. ATI has Currently no real HW Acceleration and for XvBA there are no headers or smt like that for use it ( if its Wrong im sorry but i cant find anything about this) .

Hi Nille, yes it might indeed be VDPAU that Don/neuron2 was refering to see:
http://forum.doom9.org/showthread.php?p=1228785#post1228785

however he's not around right now to clarify the question, but
what ever current NV means these doom9 devs are using, they are producing results people want/need, and people are starting to consider buying the cards these HD video apps are working with to speed up their video processing etc, thats the whole point, the end result and speed matters,not how you get to that point... if you even can with the HW brand and SW you have available.

its not just transcoding, its any and all options that your average user takes to get the end result, if any part of the workflow can be passed off to the GPU, thats more spare cycles for the CPUs to do other related video procesing stuff in a given timeframe, if that makes sense to you!.

[popper]

I'm guessing he's just talking about VDPAU, I wouldn't worry about trying to decode that rambling if I were you.

you consider asking for, and airing the subject of GPU assisted HD video processing with the readers here rambling ?, very odd.

"he's just talking about VDPAU" thats what message boards are for are they not ?, is "VDPAU" and "transcoding" so common now that every reader knows what that is, and how you use it, LOL

i take it then that you dont care about any potential future ATI assisted GPU code (whatever that might be, if any)being written, and diffs against the current FFMPEG codebase being submitted.

[smitty3268]

:eek: why :angry: , OC its Stream and CUDA, unless theres another set of APIs im not aware of as yet, not every reader here or elsware have degrees in computer sciences as i assume you do, but thats no reason to be getting angree at people :eek:

Don/neuron2 that produces the DGAVCDecNV and DGVC1DecNV
http://forum.doom9.org/showthread.php?t=141104
http://forum.doom9.org/showthread.php?t=142961

said to me ..."Nvidia has a fine video decoding library and so I make use of it because libavcodec has problems that make it unsuitable for continued development.

So, for me, it's just going to be Nvidia, unless and until ATI make available a video decoding library, and not just a bunch of low-level functions.

Don "

and that seems to be the general feeling in the doom9 and other related messageboards threads, clearly someone in ATI needs to convince these developers of the popular video apps, to work with and provide mentoring and feedback.

the same for the linux HD video devs too, its not rocket science and no need to get or show anger here, you dont need to agree with my oppinion OC, mearly take it into consideration, and perhaps profit from it in the long term with better focus to those devs that can help advocate and produce long term apps results or continue on the current path and have these devs and users ignore ATI as they are doing now....

Ah, OK. You're talking about the CUDA vs Stream computing on GPUs.

I agree that CUDA seems to have a much stronger mind share right now, for whatever reason.

I haven't tried messing around with either so I can't say much on the subject. Except that I really hope they both just die and OpenCL takes their place as an open (and compatible) standard.

[smitty3268]

you consider asking for, and airing the subject of GPU assisted HD video processing with the readers here rambling ?, very odd.
...
i take it then that you dont care about any potential future ATI assisted GPU code (whatever that might be, if any)being written, and diffs against the current FFMPEG codebase being submitted.

Not at all, I just found that post in particular hard to read and confusing. Perhaps "rambling" was the wrong description. I'm guessing that maybe you aren't a native english speaker?

More to the point, I didn't feel it really added much to the discussion. I'm sure bridgeman is very aware of all the people who want accelerated video decode, and if he is spending 30 minutes looking through a single post which I figured was just telling him what he already knew then I figured he should just drop the matter :)

I think adding some OpenCL code to the FFMPEG decoders is a pretty good idea, but I'm not really sure I see it as AMD's responsibility. OpenCL is a standard, and I think the FFMPEG devs probably have a better idea about how to write a codec than AMD does. Certainly if you look at their transcoding tool on the windows 8.12 drivers I think you may want to keep AMD as far away as possible and have them stick to the underlying video driver code ;)

[Nille]

I agree that CUDA seems to have a much stronger mind share right now, for whatever reason.

Nvidia has a better Marketing. You hear anywhere from Nvidia and CUDA and ATIs Steam promo Software is Folding@Home and the Crappy AVIVOConverter.

[popper]

"I'm sure bridgeman is very aware of all the people who want accelerated video decode" i wouldnt make that assumption though, if bridgeman is one of several high ranking people inside ATI/AMD, its more likely he and they are mostly only hearing the commercial vendors wants, and generic 3D linux driver mantra.

knowing that a high % of people want some form of video processing is one thing,picking the right app (FFMPEG)to support and show off your HW is another matter all together.

i find the "you want Transcoding" rather telling, as theres far more to video processing than mearly transcoding, and it comes down to prioritys again and how you support your end game.

the windows AVIVO internal driverset transcoder was a real messy implimentation,the old 2005 stand alone AVIVO was a far betetr idea thats for sure ;) ,and its results are bad when compared to the lowest comparable x264 settings, however, for "quick and dirty" and remember its still only using the CPU, no matter what the ATI/AMD PR try and tell you, it can still take a 90minute HD AVC H@L4.1 MKV and transcode it to an xbox360 VC1 WMV container in 20minutes on a simple core2 dual 2GHz machine, good enough for your tversity streamed 360.

with some work, you can also bypass the internal 4 year old childrens GUI with virtually no codec parameta output control, and just use all the ATI AVIVO installed directshow drivers directly to make a working graph, and improve the output etc for quick HD 360 streaming use, but thats OT (but related)here....

im not asking that he/they write all the optimised SIMD code for FFMPEG inclusion, mearly supply a good fully working example that improves/provides frame accurate stream decoding and MBAFF and PAFF at the very least, OC AVCHD and AVC intra lossless would give many more semi pro people reason to look at ATI/AMD GPUs ;)

that simple base code wouldnt need some new set in stone linux HD Video API, but would give masses of people around the world a good reason to give ATI a fighting chance in the PR and long term HD video processing mindset.

im not fully up on OpenCL but i seem to remember that ATI current implimentation isnt working right now,or in the near future, and even then, OpenCL doesnt and isnt intended to cover all the tipical HD video stream processing you might expect today anyway !

but OC if someone patchs OpenCL ATI into the FFMPEG framwork, and people get to save 10% of their time on a given workflow because of it, then thats a good thing too.

[bridgman]

Thanks popper, that answered my question. I put up the "getting mad" icon because I kept asking "what is this library you say we need" and you just kept telling me how great it would be for us to do... whatever it was... :D

The library appears to be an NVidia-supplied Windows-only binary called NVCUVID, which allows a CUDA program to use the VP2 dedicated video processor (like one piece of our UVD) to do the initial decoding of H.264 or VC-1 frames followed by CUDA code doing motion comp and filtering. The CUDA video program can either display the decoded frames through DX or return the frames to the calling application. The second option is obviously what a ripper/frameserver would want.

This collection (CUDA run time + NVCUVID binary + CUDA video decode program) is then built into a frame serving program written by Don Graft (neuron2 on the doom9 forum), called either DGAVCDecNV or DGVC1DecNV depending on whether you are using the AVC (H.264) or VC-1 version.

The announcement talks about it being cross-platform so presumably it may show up on Linux or MacOS at some point.

[rbmorse]

The announcement talks about it being cross-platform so presumably it may show up on Linux or MacOS at some point.

I wonder what license nVidia put on them.

[bridgman]

The library itself is binary so it is presumably covered by the same EULA as the rest of the binary driver. The header files etc... are covered by NVidia's usual open source license, which is a slightly modified MIT license (looks like the one SGI used to use).

EDIT - popper, did you make another (long) post around 8 AM ? I can't find it anywhere although I have the notification email from it.

I thought the post was pretty good, although you may still be missing that we are arguing on the same side. I was arguing AGAINST investing in a vanilla MPEG2/XvMC implementation because I felt that time would be better spent working on code which would work with H.264 and VC-1.

[highlandsun]

Yeah ;)

It's probably obvious but when I said "high performance expectations" I was talking about the graphics subsystem where the drivers are hugely complex and proprietary drivers still have an edge.


Still, it sounds like you're equating "open source" == "easy to do" and "proprietary" == "more sophisticated". I should point out that this is an old-fashioned mentality; for example the highest performance directory software in the world is open source (OpenLDAP); it's generally 5-10x faster than any/all of the proprietary directory software packages out there, and it implements the specs correctly where all the proprietary vendors cut corners. Sophistication and performance doesn't require closed source proprietary developers. It doesn't even require the highest paid development teams. I did the profiling and refactoring of OpenLDAP's code simply because I saw it needed to be done, not because anybody paid me to do it... It annoys me that no one has jumped in here yet re: XvMC, and I regret that I don't have the time to do it myself.

And it still sounds like XvMC is worth investing in, given that Via already extended their implementation to work with H.264 etc; it was obviously the path that gave them the most bang (software compatibility) for their development buck. But if something like VAAPI is suddenly getting adopted, as it now appears to be, then that'd be fine instead.

[rbmorse]

What Bridgeman said holds true for video drivers.

[bridgman]

Still, it sounds like you're equating "open source" == "easy to do" and "proprietary" == "more sophisticated". I should point out that this is an old-fashioned mentality; for example the highest performance directory software in the world is open source (OpenLDAP); it's generally 5-10x faster than any/all of the proprietary directory software packages out there, and it implements the specs correctly where all the proprietary vendors cut corners. Sophistication and performance doesn't require closed source proprietary developers. It doesn't even require the highest paid development teams. I did the profiling and refactoring of OpenLDAP's code simply because I saw it needed to be done, not because anybody paid me to do it...

If you read enough of my posts you'll see that I don't believe in that line of thinking (proprietary automatically = more sophisticated) at all. The problem here is the sheer size of the work relative to the size of the development community.

Right now getting drivers with features and performance comparable to the proprietary drivers on other OSes takes more development work than the community can do on its own *or* than HW vendors can fund based on the size of the Linux client market. That means the HW vendors will need to share the costs (and the code) across multiple OSes, and so far the business realities of those OTHER OSes dictate that the resulting code remain closed on Linux as well.

In that context closed source drivers offer a way to tap into more development resources than we could get access to otherwise; nothing more.

It annoys me that no one has jumped in here yet re: XvMC, and I regret that I don't have the time to do it myself.

Yeah, that is my whole argument in a nutshell; the expectations and demands of the Linux market are growing faster than the development community or the market share (and, of course, market share drives the funding which HW vendors and commercial distros can put in).

One of our hopes is that by providing sample code and by continuing to work on drivers for older GPUs we will make it easier for new developers to get started and allow more people to participate in graphcis driver development than we have today. The experienced volunteer X developers we have today are extremely good and can take on a project like this on their own, but we don't have anywhere near enough of them.

And it still sounds like XvMC is worth investing in, given that Via already extended their implementation to work with H.264 etc; it was obviously the path that gave them the most bang (software compatibility) for their development buck. But if something like VAAPI is suddenly getting adopted, as it now appears to be, then that'd be fine instead.

I don't think the developers extended the detailed XvMC API to support H.264 on Via HW - that would have been a much larger task. AFAIK they just added a "slice level" API and used that to feed into the slice level hardware on specific GPUs, bypassing all the places where the XvMC details didn't match the H.264 details. Since a lot of our GPUs don't have slice level hardware, and at the moment we do not have plans to open up the slice level hardware on the chips which *do* have it, that approach is probably not feasible unless we implement the slice level support in software inside the driver (which, I guess, is an option).

I have only skimmed the code so far; need to look through it in more detail. Hey, that's what weekends are for, right ? :D

[RobbieAB]

I don't think Via extended the actual XvMC API to support H.264 - that would have been a much larger task. AFAIK they just added a "slice level" API and used that to feed into the slice level hardware on the chip, bypassing all the places where the XvMC details didn't match the H.264 details. Since a lot of our GPUs don't have slice level hardware, and at the moment we do not have plans to open up the slice level hardware on the chips which *do* have it, that approach is probably not feasible unless we implement the slice level support in software inside the driver (which, I guess, is an option). I have only skimmed the code so far; need to look through it in more detail. Hey, that's what weekends are for, right ? :D

IF the Via XvMC is "slice level" based, would using a slice level approach in the AMD drivers allow cross driver code usage? Afterall, if one of the problems is the lack of developers, maximising the usage of current code is a good idea...

[bridgman]

It would definitely allow code sharing up in the player. I doubt there would be much code to be shared in the driver, assuming the Via driver just stuffs slice level info into the chip as I suspect.

I think in the end we're going to have to pin all the APIs up on a wall and game out what happens if we use each one. We (and the open source devs for other HW) really need to choose between two options :

1. Choose or create an API which matches the functionality we plan to offload to the chip (practically speaking, this means we do *not* offload entropy decode, probably *do* offload IDCT, and definitely offload everything from that point)

2. Standardize on a slice level API recognizing this means we will need to duplicate some existing CPU code for the things we won't be offloading to the chip.

So far the second option seems conceptually simpler but more work unless we can borrow the entropy decoding stage from an existing software decoder; that gets tricky because all of the software decoders seem to be GPL or LGPL licensed. You can move code from an MIT-licensed X driver to GPL-licensed software decoder but you can't move from a GPL-licensed SW decoder to an MIT-licensed driver without contacting all the copyright holders and getting their agreement to relicense (which, in practice, rarely seems to happen).

Putting GPU acceleration into an existing SW decoder (say libavcodec) seems like an obvious option but is tricky because the codec would then need to be come a drm client and follow the DRI protocols; practically speaking you end up having to define an API to get into the X driver stack anyways. This is where Gallium3D could get interesting, assuming that the final implementation automatically brings along the drm/dri integration so the codec could just say "this state, this shader, go".

BTW I confirmed over the weekend that our older IDCT hardware will *not* be able to support H.264 acceleration; looks like H.264 uses a modified IDCT with different coefficients from the ones hard-wired into our older MPEG2 hardware. That's why I said "probably" for offloading IDCT; I think it will work OK on shaders but I haven't actually seen anyone do it yet.

[RobbieAB]

2. Standardize on a slice level API recognizing this means we will need to duplicate some existing CPU code for the things we won't be offloading to the chip.

Surely the non-offloaded parts will mostly be the same for multiple chips?

[bridgman]

Yes, I think the code would be largely common across any chip using shaders rather than dedicated hardware. I was thinking of "duplicate" in the sense that this code has already been implemented in a number of GPL-licensed software decoders.

[RobbieAB]

Ooops, sorry, I misunderstood what you meant.

I was just thinking that if developers is the big limitation on opensource drivers, anything that gets more use from the code available is a good thing.

[bridgman]

Yep. The tricky part is that if the "most code-sharing-y approach" also requires the most work to be done before showing any useful results, the choice becomes harder.

The slice level approach also means that the driver devs need to maintain the front end (eg entropy decode) code in each driver whereas if we had a slightly lower level API then that code would be maintained once in the player or whatever decoder sat between the player and the driver API.

In other words, there's a practical difference between "sharing a single copy" and "having one set of code which can more or less be used by a bunch of different drivers, each with their own copy, each being maintained independently by different developers and probably drifting in slightly different directions over time". Going with a slice level API is the second case, unfortunately.

[Kjella]

So far the second option seems conceptually simpler but more work unless we can borrow the entropy decoding stage from an existing software decoder; that gets tricky because all of the software decoders seem to be GPL or LGPL licensed. You can move code from an MIT-licensed X driver to GPL-licensed software decoder but you can't move from a GPL-licensed SW decoder to an MIT-licensed driver without contacting all the copyright holders and getting their agreement to relicense (which, in practice, rarely seems to happen).

GPL is maybe tricky, but is there a problem with LGPL? You could keep the software decoding stages in their own library and thus it wouldn't affect any other bits. I thought that was the general idea of the LGPL = Library GPL, any changes you make to the library itself must be released but nothing else. Throw in a configuration flag to build with (LGPL dep) or without (MIT) video support and the rest is still free game. You're talking to someone that thinks the X stack being under the MIT license is a contributing reason why it's gotten no futher than it has though, so I'm obviously biased.

[bridgman]

I'm not sure what the current thinking is re: LGPL in xorg drivers but will ask. I guess the best approach would be to make a subset library from the current decoder which only handled the work we did not offload to the GPU then link the binary in - that would also allow multiple drivers to share the same lib.

Interesting idea - thanks !

[Dieter]

bridgman> The only discussion in the thread was about whether it was
bridgman> worth implementing XvMC, which is currently MPEG2-only

Yes

bridgman> whether MPEG2 decoding placed enough load on the system to
bridgman> justify implementing XvMC

Yes

bridgman> I think we all agree that support is meeded for the more demanding
bridgman> formats, particularly H.264. The question *there* is whether that
bridgman> is a higher priority than 3D support, which is what we are working on now.

For Rage, Radeon, FireMV-2D: video decoding 1st, then power management, then 3D

For FirePro-3D, FireGL-3D: 3D 1st, then power management, then video decoding

Have I left out any video chip families?

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

smitty3268> I think the FFMPEG devs probably have a better idea about how to
smitty3268> write a codec than AMD does

Wow! Given that ffmpeg core dumps constantly, you must have a *really* low
opinion of AMD.

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

bridgman> I just spent another half hour going through [ ... ]
smitty3268> I wouldn't worry about trying to decode that rambling

Obviously bridgman needs rambling decode acceleration. That was
a half hour that could have been spent on XvMC.

[bridgman]

Yes
Yes


Just to be clear, we're dealing with finite resources here so the question is not "would it be nice to have MPEG2 accel ?" (even I can answer that one :D) it's "should the community work on MPEG2 accel instead of H.264/VC-1 accel ?", ie which should be worked on first ?

For Rage, Radeon, FireMV-2D: video decoding 1st, then power management, then 3D

For FirePro-3D, FireGL-3D: 3D 1st, then power management, then video decoding

The GPU programming is pretty much the same for the two families, so sequence of implementation would be the same for both. If you were combining the families, what would the sequence be ?

Obviously bridgman needs rambling decode acceleration. That was a half hour that could have been spent on XvMC.

Agreed, but that is another example of a workload which needs specialized hardware and is difficult to parallelize :D

[DoDoENT]

Just to be clear, we're dealing with finite resources here so the question is not "would it be nice to have MPEG2 accel ?" (even I can answer that one :D) it's "should the community work on MPEG2 accel instead of H.264/VC-1 accel ?", ie which should be worked on first ?

I vote for H.264/VC-1 acceleration, although I desperately need power management and faster 3D acceleration on my M56 chip (R500-based Mobility Radeon X1600).

Why don't you create a forum poll, so everyone could give it's own opinion about what should be created first?

[popper]

people dont want a poll this late in the game, they want and NEED a real subset AVC decode and related libray ASAP, perhaps as a tempory stop gap measure until it all settles down later if needs be, PLUS development headers and DOCUMENTATION, and sample full working code showing anyone how to use it ASAP/TODAY.

some basic benchmark code/charts for each proposed code example might be nice to, so you can decide at a glance which routine or usage suits your requirements for code review and insertion into the likes of FFMPEG etc..

its been said that "the API is the least of the problems" and thats true to some degree, but Bridgeman has stated he beleaves theres enough data documentation out there right now.

presumably that means theres enough information right now for someone here ? to take parts of the ATI/AMD API(s) and make an equivenent VDPAU ?

call it an alpha AVIVO.lib for AVC,vc1,Dirac, and even mpeg2 if its only another entry point in the lib API.

remember, the actual ATI hardware can officially decode all but one of these already ,some video Dev here reading must be capable of running up a quick HW assist AVC decode library based on the ATI API in the same vain as VDPAU being used right now in ffmpeg code in a few days and posting it here ?

there MUST be some test API code sat on the ATI/AMD devs PCs Bridgeman is in contact with and can get their permissioon to use and contribute an hour or so for outside use, to learn from, and use in a basic alpha state open avivo libary.

as Prototyped outlined here
http://episteme.arstechnica.com/eve/forums/a/tpc/f/96509133/m/467009165931

"....
In September, ATI released their Catalyst 8.9 driver with X Video Bitstream Acceleration (XvBA) libraries that could be enabled using tools that shipped with the driver, and then last month, the 8.10 driver enabled the UVD2 video acceleration by default.

The unfortunate thing is that they didn't also ship any development headers with the driver, with the result that the binary libraries were available, but there was no SDK or information available to media player developers to actually utilize the libraries. So XvBA currently remains a white elephant.
..."


for PR purposes and to try and make outsiders equate the ATI/AMD library to VDPAU subset library, i think it should be called AVIVO.lib not XvBA , X-Video Bitstream Acceleration (XvBA), were people are confusing it with the old X-Video Motion Compensation (XvMC)


remember also that its 4 months since the library(s) have been available, so alpha/beta test code at the very least must exist on the ATI devs machines to show off this new libray use, but still NO docs are available that i know of, to explain how you might use this library or its official API for hardware assist video decoding etc, WHY AS THAT?
a poll is wasting peoples times, were are these X-Video Motion Compensation (XvMC) docs so FFMPEG people and the like MIGHT stand a chance to get some parity with the current HW assist VDPAU FFMPEG code diffs....

http://en.wikipedia.org/wiki/XvBA
"...
From Wikipedia, the free encyclopedia
(Redirected from XvBA)
Jump to: navigation, search
X-Video Bitstream Acceleration (XvBA), designed by AMD for its ATI Radeon GPU, is an extension of the X video extension (Xv) for the X Window System on Linux operating-systems[1].

XvBA API allows video programs to offload portions of the video decoding process to the GPU video-hardware. Currently, the portions designed to be offloaded by XvBA onto the GPU are motion compensation (mo comp) and inverse discrete cosine transform (iDCT), and VLD (Variable-Length Decoding) for MPEG-2, MPEG-4 AVC (H.264) and VC-1 encoded video.

XvBA is the Linux equivalent of the Microsoft's DirectX Video Acceleration (DxVA) API for Windows.[2]

...
"

seeing as it seems to be the fashion, and the fact ATI/AMD sold them to us as giving you access to some form of hardware assisted video decode/playback etc with a driver update, i have several X1550,HD3650 and looking to get some HD4xxx soon if something HW assisted code comes home sometime seen, or something else to start advocating werever we go....


as it happens, the lads HD3650 has a large 1gig memory on it, i wonder if pre-loading/pipeing some video through a FIFO to the cards internal memory might improve any future HW assisted processing!

[popper]

Just to be clear, we're dealing with finite resources here so the question is not "would it be nice to have MPEG2 accel ?" (even I can answer that one :D) it's "should the community work on MPEG2 accel instead of H.264/VC-1 accel ?", ie which should be worked on first ?



The GPU programming is pretty much the same for the two families, so sequence of implementation would be the same for both. If you were combining the families, what would the sequence be ?



Agreed, but that is another example of a workload which needs specialized hardware and is difficult to parallelize :D


Oh,theres your problem , your thinking taking your workload and trying to parallelize it, you should be thinking micro-kernel and multitasking in the same vain as Carl Sassenrath of the original home mutitasking Amiga OS and rebol http://en.wikipedia.org/wiki/REBOL TCP/IP GUI scripting fame. :D

actually, rebol GUI scripting would be a very good thing to use for any cross platform GUI HW assisted front end, and Carl's old AOS multitasking kernel Co-Processing ideas would work great for todays Gfx cards,plus a simple JIT backend/frontend perhaps, go ask him over on rebol.org

[bridgman]

its been said that "the API is the least of the problems" and thats true to some degree, but Bridgeman has stated he beleaves theres enough data documentation out there right now.

presumably that means theres enough information right now for someone here ? to take parts of the ATI/AMD API(s) and make an equivenent VDPAU ?

The thread where I posted that was about XvMC. What I said was that there was enough information out there to implement XvMC. The information released is also sufficient to accelerate the back half of H.264/VC-1 decode (from inverse quantization onwards, with the rest being done on CPU. There's a good chance that frames using spatial prediction would need to have more of the work done on CPU.

The unfortunate thing is that they didn't also ship any development headers with the driver, with the result that the binary libraries were available, but there was no SDK or information available to media player developers to actually utilize the libraries. So XvBA currently remains a white elephant.

No, it remains an unannounced feature which some clever people have started picking apart and talking about already.

remember also that its 4 months since the library(s) have been available, so alpha/beta test code at the very least must exist on the ATI devs machines to show off this new libray use, but still NO docs are available that i know of, to explain how you might use this library or its official API for hardware assist video decoding etc, WHY AS THAT?

Because we haven't released it yet as far as I know.

[energyman]

people dont want a poll this late in the game, they want and NEED a real subset AVC decode and related libray ASAP, perhaps as a tempory stop gap measure until it all settles down later if needs be, PLUS development headers and DOCUMENTATION, and sample full working code showing anyone how to use it ASAP/TODAY.


no, people want 3D perfornance first. As shown here:
http://www.phoronix.com/scan.php?page=article&item=lgs_2008_results&num=5

so all that crying about video decoding is just a vocal minority - like always.

[popper]

hmm , perhaps , but non the less "a vocal minority" that puts in their picket every time theres a new use for their minority interest.

and lets face it, theres far more people into video than any 3D linux use, sure linux 3D is cool, but it does nothing for your Co-Location ISP usage,HW assisted decoding/transcoding, and other related NON 3D processing etc will find its way into the data center for home/SOHO use to name but one example.

[Dieter]

> Just to be clear, we're dealing with finite resources here
> so the question is not "would it be nice to have MPEG2 accel ?"
> it's "should the community work on MPEG2 accel instead of
> H.264/VC-1 accel ?".

Mpeg2 accel is needed NOW. NTSC goes away in 6 weeks. ATSC is
Mpeg2, and many people don't have CPUs fast enough to decode HD
in real time, and some people probably don't have CPUs fast enough
for SD.

IIRC you wrote that you don't watch tv and perhaps you don't think it
is important. But TV is more than just entertainment. It is an
important part of the modern communications infrastructure. Many
people depend on TV to get news about time critical problems, both
natural (snow, ice, wind, earthquake, tsunami, volcano, tornado,
hurricane, land slides, forest fires, floods, etc.) and man made
(9-11, etc.). Is the tap water safe to drink? Am I supposed to
try and get to school/work? Is transportation working, or have
they closed the highways, and canceled the trains and planes?

> If you were combining the families, what would the sequence be ?

Mpeg2 accel is needed NOW.

I've been asking about Mpeg2 accel for months (years in some forums).
It is H.264/VC-1 accel that would be "nice to have", but that is
entertainment, not critical news. Same for 3D. 3D is "nice to have",
but is not needed to get critical news.

[bridgman]

OK, now *that* is a useful answer.

BTW I mentioned that I don't watch TV only because someone posted that "obviously you watch TV so...". My personal habits should not be driving development decisions anyways ;)

Serious question though -- do you really believe that people who rely on their analog TV today for critical information are going to go out and buy a tuner card for their too-slow-to-decode-MPEG2 Linux PC and have that as their only option, ie they would not pick up a cheap set-top box to convert from ATSC to NTSC ? I can imagine maybe 10 people falling into that scenario, not tens of thousands.

Anyone who already had an ATSC tuner card but could not decode the signals would have upgraded their PCs already or would not be relying on it. I have a tough time believing that they are sitting at home hoping that we will implement MPEG2 acceleration before Feb 11, or am I being too cynical here ?

[energyman]

> Just to be clear, we're dealing with finite resources here
> so the question is not "would it be nice to have MPEG2 accel ?"
> it's "should the community work on MPEG2 accel instead of
> H.264/VC-1 accel ?".

Mpeg2 accel is needed NOW. NTSC goes away in 6 weeks. ATSC is
Mpeg2, and many people don't have CPUs fast enough to decode HD
in real time, and some people probably don't have CPUs fast enough
for SD.


mpeg2 decoding can be easily done by a K6-2 400 - that is a 10 year old cpu....

[popper]

Nitpick old Mpeg2 SD and CIF type low bitrate encodes can be decoded by......K6-2 400 etc.

a K6-2 400 or 500MHz that i have cant decode PAL SD 50i thats broadcast at greater than 1.3Mbit/s on the DVB-T mpeg2 streams.

20Mbit HD 720P/1080i/P is totally another matter....

[energyman]

so what? are people watching blueray disks on their low level linux boxes? when you have the money to spent on a blueray player, you also have the money to buy a cpu with more than a 1ghz.

And tv?
'normal' digital tv is SD anyway - and handled easily by every cpu produced in the last 10 years.
And hd tv? Well - what about a decoder card? You need it anyway, so you can spent the few bucks more for one with hardware decoding, or on a better cpu.

In the mean time - 3d is something you can't go around with a better cpu. And 2d is far from perfect either. 2d is certainly more used than hd video watching.

So again, vocal minority.

[popper]

The thread where I posted that was about XvMC. What I said was that there was enough information out there to implement XvMC. The information released is also sufficient to accelerate the back half of H.264/VC-1 decode (from inverse quantization onwards, with the rest being done on CPU. There's a good chance that frames using spatial prediction would need to have more of the work done on CPU.



No, it remains an unannounced feature which some clever people have started picking apart and talking about already.



Because we haven't released it yet as far as I know.

the question then seems to become, after 4 months of releaseing the XvBA librays, why didnt/hasnt someone in ATI/AMD release (at least some of) the related docs to encurage developers to start using it/them!

[bridgman]

Because we haven't released it yet as far as I know.

[energyman]

a K6-2 400 or 500MHz that i have cant decode PAL SD 50i thats broadcast at greater than 1.3Mbit/s on the DVB-T mpeg2 streams.


I had a k6-2 400 and I was able to watch fullscreen dvd with it - without any support from the graphics card. dvd that is mpeg2 at 11mbit/sec. The same as digital tv.

I just had to make sure that glibc, and the libs for the apps used were compiled for pentium - not 386 or 486...

[popper]

so what? are people watching blueray disks on their low level linux boxes? when you have the money to spent on a blueray player, you also have the money to buy a cpu with more than a 1ghz.

And tv?
'normal' digital tv is SD anyway - and handled easily by every cpu produced in the last 10 years.
And hd tv? Well - what about a decoder card? You need it anyway, so you can spent the few bucks more for one with hardware decoding, or on a better cpu.

In the mean time - 3d is something you can't go around with a better cpu. And 2d is far from perfect either. 2d is certainly more used than hd video watching.

So again, vocal minority.

your falling into the same old antiquated trap as all the other x86 coders thinking..... it doesnt matter, as the next faster CPu will be along any day now....

the world is becoming netbook CPU size and lower CPU thoughput as the power requirements drop....

im not advocating only mpeg2, far from it, give me AVC encoded and streamed everything over Multicast tunnels any day....

i look forward to the futures realtime AVC multicast streaming variable bitrate Encoded digital multi-PIP over a new VNC/X server or two :)

however it seems many people are oblivious to the fact the worlds home PCs are changing right now, and people are wanting to buy small, low power mobile and soon static type devices and use them in dedicated single/dual tasks, thats were your dedicated (better than)realtime HW assisted Encode/Decode will be welcome, you dont then need the latest and greatest CPU to do all your mundain gfx processing....

"'normal' digital tv is SD anyway " you assume that is and will remain the case for all parts of the world , the world is not only the USA OC.....

"'normal' digital tv is SD anyway " are you also assuming its all encoded as Mpeg2 as well, that too isnt the case as more and more countrys adopt the AVC/H.264 for their HW realtime transcoded SD content (DVB-*) broadcasts...

nor the webs streaming content eather, Youtube encode your content to AVC remember, and DivX7 is developing H@L4.0 AVC OC.... theres not going to be much Mpeg2 left in the realtime trancoding world wide, only lagacy Mpeg2 from those that are milking the Mpeg2 only HW SOC (system On a Chip)for all they can until it drys up....

"are people watching blueray disks on their low level linux boxes?" OC not, they are using their HD PS3s mostly as the largest BR player sold world wide OC, BTW BR is encoded in AVC/H.264 today, the old semipro Mpeg2 transition transencoding kit was mostly sidelined long ago by the major BR vendors as the real long term AVC/H,264 trancoders came online.

So again, the vocal minority that puts in their pocket EVERY time theres somthing new that can speed up their video interest.

you dont for one minute think people havnt pulled their HD ATI cards right now and replacing them with NV cards so as to start using them now the tools and code have arrived in ffmpeg etc....

this minority are paying out and will continue to pull any card if another one comes along that makes their video procesing even slightly faster, can the same be said for the 3D linux buyers.... its clear who's werth more to the gfx vendors in this global turn down, anyone that buys their cards, time after time thats who...

[Dieter]

bridgman> Anyone who already had an ATSC tuner card but could not
bridgman> decode the signals would have upgraded their PCs already
bridgman> or would not be relying on it.

You don't have to rely on ATSC as long as NTSC is still around.
News can be watched live on NTSC. And news is only a *need*
when there is a serious problem. Entertainment can be transcoded
down to SD (or whatever) at slower than real time and watched later.
Or watched on NTSC.

Many people have been busy working on improving ATSC reception.
NTSC degrades gracefully, and the picture gives you good clues as to
what is wrong (snow vs ghosts vs herringbone, etc.) ATSC does not degrade
gracefully, often called the digital cliff effect. And doesn't give
you any clues as to *why* your reception is bad. You don't need
real-time decoding to work on reception problems, and hey, ATI
is releasing docs, and the drivers get the new features amasingly
quickly once the docs are out, so we should have XvMC soon. Well,
here we are in January 2009 and still no XvMC. :-(

bridgman> I can imagine maybe 10 people falling into that scenario,
bridgman> not tens of thousands.

How many people *need* fast 3D for anything? (Really need, not
the kiddie "I *need* my shiny new toy".) I can imagine zero.

How many people *need* H.264 or other newer codecs? I can imagine
zero. This is entertainment, and can be transcoded down at slower
than real time and watched later.

We actually *need* mpeg2 decoding.

energyman> mpeg2 decoding can be easily done by a K6-2 400
energyman> - that is a 10 year old cpu....

BS. There is no way a 10 year old CPU is going to decode full bitrate
720p or 1080i in real time. Maybe it can decode some low bitrate
low resolution, but that isn't the problem. From thread 14641:

rvdboom> I have a 2GHz Opteron and it cannot deal with HD contents,
rvdboom> either in MPEG4, MPEG2 or any other codec.

highlandsun> I have an Opteron 185 and a Dvico Fusion HDTV tuner
highlandsun> and a Radeon 9550, and 4GB of DDR-400. It's pretty
highlandsun> much impossible to watch 1080i HDTV material on this machine

That's just what I found in a couple minutes. I've seen lots of postings
in other forums about various other recent CPUs that can't decode HD in
real time.

[energyman]

is this hd?
RIFF (little-endian) data, AVI, 1280 x720, 29.97 fps, video: DivX 5, audio: MPEG-1 Layer 3 (stereo, 16000 Hz)

if yes - that decodes fine on my 6000+ with almost no load and one core occupied with another application. And xshm as xine output plugin.

[Dieter]

energyman> 'normal' digital tv is SD anyway

Wrong. You have no clue what you are talking about.

Many broadcasts are HD, so to watch it you have to decode HD.
If your display can't do HD you have to scale it down, so even
more work for the CPU, until someone gets the Xv stuff working
correctly.

energyman> what about a decoder card?

Decoder card? What are you talking about, some expansion card
that has hardware mpeg decoding, that can handle full bitrate HD,
and has FLOSS device drivers for *BSD, Plan-9, Linux, OpenSolaris,
OS-X, etc. ? And magically adds a free expansion slot to your computer?
And not just any expansion slot, but one with enough bandwidth to
handle decoded HD (PCIe x2 or faster) and ship it over to the GPU.
Yes, where do we get one of these magical decoder cards?

energyman> you can spent the few bucks more for one with hardware
energyman> decoding, or on a better cpu.

A better cpu is more than a few bucks. Quite a few more since it
really means a whole new computer.

energyman> dvd that is mpeg2 at 11mbit/sec. The same as digital tv.

Wrong again. DVD is 720x480. ATSC is up to 19.3 Mbps and up to
1920x1080.

[energyman]

no, I know exactly what I am talking about.
Almost all digital content HERE is SD.

Yes, there is some hd content - however since most tv sets still can't do it, it is sent in a way to make downsizing simple.

I have an analog tv card - no load for my cpu
I have a digital/analog dvb-t/analog usb stick - no load for my cpu.

and standard sd digital tv has the same rate as dvd. That is correct. Start learning to read.

[monraaf]

Looks like everybody is using this thread to push their wish list. So I'll put in mine too :)

1: Fast and stable 2D EXA acceleration for R600/R700.
2: Tear-Free Xv acceleration for R600/R700
3: 3D-Acceleration for R600/R700

I think this is in line with the development path for the radeonhd driver, and sure hope that the developers are not letting themselves be influenced by the ad infinitum demands by a vocal minority for features that can easily be handled by a 50 euro CPU.

[Dieter]

> Almost all digital content HERE is SD.

You don't explain where "HERE" is.

I'm talking about ATSC in the United States.

Many ATSC broadcasts in the US are HD (720p or 1080i)
and can be up to 19.3 Mbps. To watch them live you must
be able to decode this in real time, and if done in
a CPU it takes a LOT of CPU.

You keep talking about SD. I'm talking about HD
broadcasts. HD takes a LOT more CPU to decode than
SD does.

The solution is for the GPU to support XvMC.

[BlackStar]

Dieter, making mpeg2 decoding a priority on the open drivers simply does not make sense with the current situation. Fast, tear-free 2d and Xv, power management, support for KMS and RDR are simply much more important in day to day use.

The few (*) people who wish to watch ATSC broadcasts on their linux boxes can get by with the catalyst drivers. Hopefully, this will also allow the dust to settle around the competing decode acceleration specs and avoid wasting the (already strained) developer resources.

Edit: (*) Few, because most people will probably use an external decoder hooked to their tv. Really, how many have CPUs that won't decode 720p mpeg2 these days anyway? Any recent CPU, bar Atoms (which don't use AMD cards!) should be able to do this, Semprons included.

[bal_zac]

You can use a converter box on any analog card, like the pvr-350, and voila you get a sd mpeg-2 copy of just about any broadcast here in the good ole US of A. Oh and did I mention that you can play it back on as low as a good ole sempron 3100 underclocked at 800 MHZ? Even my be-2300 underclocked to 1ghz can easily handle 1080p mpeg-2 streams aorund here no problemo. MPEG is easy. AVC on the other hand...

[smitty3268]

This is getting a little ridiculous. You guys are making it sound like people are going to die in some national emergency just because they can't watch their broadcast news in HD on a 5 year old linux computer. That's really the best argument you can come up with? Seriously now, how many people:
1. Have their fastest computer be one from 5 years ago.
2. Use Linux.
3. Don't own a single TV.
4. Don't have the means to correct this themselves.

No one really NEEDS XvMC any more than anyone NEEDS 3D support. It's not some basic human right that everyone is entitled to. If it's really that important you, spend the $20 to get a card which supports what you want, or better yet just get a cheap TV.

The truth is, there are 2 large areas of use that the drivers should be helping out with that nearly everyone uses. 3D support and video. Both have loud minority populations - apparently the video guys want XvMC, and the 3D minority wants to play demanding games. Both have much, much, much larger populations that would be happy with just basic desktop compositing support and x264 decoding. I certainly hope that the developers choose to spend their time focusing on areas which will help the majority of users first, and then move on to the lesser used features later. I'm pretty sure that's going to happen.

XvMC support would be nice, but I would consider it more of a power saver than a performance feature. I imagine it could be helpful for people who play DVD's on their laptops/netbooks.

[Kano]

H264 acc IS needed. Of course you can buy cpus that can decode even 1080p material (720p should be possible even on cheap ones) but why should Linux users need to buy a much faster cpu than Win users just because of missing driver features? In many other cases Linux tools do not run not slower than on Win - due to missing virus scan they start even faster. VDPAU works pretty well (except that you have to disable composite to get rid of tearing) and ATI needs to show something similar soon. Right now you can only tell ppl to buy those GF8+ cards or onboard solutions for watching H264. You need to compile a bit but then you have got very low cpu usage...

[BlackStar]

This is getting a little ridiculous. You guys are making it sound like people are going to die in some national emergency just because they can't watch their broadcast news in HD on a 5 year old linux computer. That's really the best argument you can come up with?
Well said!

H264 acc IS needed.
Exactly, and in fact it's needed much more than mpeg2 acceleration (XvMC). Problem is, we need 3d and Xv and a suitable API before H264 can be accelerated in the open drivers. We also need power management, because watching a video with your GPU howling is no fun.

Not joking about the last part, either: my severely underclocked 4850 card consumes ~65W with RadeonHD vs ~30W with Catalyst when idle. This translates to a fan speed of ~4000RPMs (intolerable) vs ~2000RPMs (barely tolerable). (Yes, I'm going to add a big bad piece of copper and silence it, but the difference is significant.)

[yotambien]

no, people want 3D perfornance first. As shown here:

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

so all that crying about video decoding is just a vocal minority - like always.

Oh, really? OK, let's have a look at the numbers YOU quoted, then:


OpenGL performance 17.3 %
Video playback/acceleration 15.1 %
Licensing/open source 11.5 %
2D performance 10.8 %
Image quality 10.3 %
Syspend/hibernate 9.7 %
Stability 9.4 %
Ease of installation/maint. 8.1 %
Display-related features 4.8 %
Multi GPU rendering 2.3 %

Now, apart from the obvious fact that anybody with a first degree in finger counting could acknowledge, one could also argue that the answers given to 'Image quality' are more related to the video playback business than to 3D performance.

In the same lines seen in some posts in this thread, I could say that efforts to improve 3D performance are a waste of time given the scarcity of linux games and the absolute no need for a compositing desktop. Of course, there would be an army of people including gamers, professional and academic users of 3D graphics software and linux enthusiast that wouldn't be very happy.

I don't know what's the hard part in understanding that decoding HD MPEG-2 puts quite a stress on the CPU, and that having the hardware we bought to do it would be, uhm, reasonable. The _technical_ questions related to the convenience of implementing this now or doing it within a unified API encompassing MPEG-4 standards are valid and solid. Arguments based on what one would personally like to see are not.

PS. On the other hand, you guys in the states may have some extra time to lobby for this:http://news.slashdot.org/article.pl?sid=09/01/08/2052212
:)

[energyman]

you do know that 2d is dead, right? That today is everything is done in the 3d hardware of a card, right? That 3d performance is important to 2d performance and features, right?

no, you don't.

[Dieter]

smitty3268> You guys are making it sound like people are going to
smitty3268> die in some national emergency just because they can't
smitty3268> watch their broadcast news

You seem to think this is far fetched. Stranger things happen
every day, heck, every minute. Large sections of the US have had
record setting severe weather the last few weeks. Highways closed,
trains canceled, flights canceled, grocery store shelves empty,
power outages, medical facilities closed, the list goes on, and on,
and on...

smitty3268> No one really NEEDS XvMC

I need it. I need mpeg2 accel and I need it now. I am not alone.

Some of us understand the difference between need and want.
I would *like* support for other codecs, but that can wait.

smitty3268> Don't own a single TV.

I don't see what the marital status of my TV has to do with this.
If I convince my TV to get a divorce will that help?

What matters is that most existing TVs only have a NTSC tuner.
ATSC tuners have only been mandatory for a year, and some stores
were caught selling NTSC-only TVs past the deadline. Big name
stores that should know better. So lots of people have NTSC-only TVs,
even people that bought one very recently. BTW, TVs can last for
decades, they really need to have the ATSC tuner mandate in place
for at least 10 years, preferably 15 years or more before shutting
down the NTSC broadcasts. Maybe someone will develop a decent
demodulator by then.

I have looked into the CECBs and big surprise the programmers
were sloppy and they crash. Do you think they are open source
so that we can fix the bugs?

I have looked into other hardware solutions and they have similar
problems. To have any hope of getting something that works it
has to be FLOSS so that the bugs can be fixed.

[popper]

Quote:
Originally Posted by popper
i dont know if it (core/nvcuvid) will be usable on linux X86 as yet though.

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

im not so sure, see:
http://forum.doom9.org/showthread.php?p=1229752#post1229752

BTW are ATI/AMD at CES? go chat with BetaBoy perhaps, he hints he's talking to the Gfx vendors about HW assisted decoding so there may or NOT be a potential use in the near term for a CORE PLAYER...

[bridgman]

That link seems to be talking about adding CUDA itself, not the nvcuvid library. CUDA is available on Linux (as is Stream), but AFAIK it's the nvcuvid library which provides access to the decoder hardware and that seems to be Windows only so far. I

n the future obviously anything is possible.

AMD is at CES but I'm off ice fishing for the weekend :D

[popper]

fishing for ice :p
is that one of those (vocal) minority sports ;)

i may go and ask BB if its nvcuvid library or full CUDA on linux and clarify, but he's not one for fast turn around and someones got to mention the Core Encoder that didnt appear in 2008 and see what comes back....

BTW,if any reader joins doom9 to try and encurage the devs to look at and contribute to any linux ATI HW assist potential theres a 5 or is it 7 day turn around i forget,before you can post so do it now.

BTW am i to assume if Betaboy or the other devs there want to get access to the Stream and AVD docs for any apps they write,they stand a better chance than the average open dev getting them and being passed to an internal ATi dev for errata help/advice ?, i may put that to them too if so...

it might be nice if Dark Shikari ,x264 developer could be convinced to add something ATI HW assist related, he didnt like the NV coding options apparenty...but i dont know the details.

[popper]

Well said!


Exactly, and in fact it's needed much more than mpeg2 acceleration (XvMC). Problem is, we need 3d and Xv and a suitable API before H264 can be accelerated in the open drivers. We also need power management, because watching a video with your GPU howling is no fun.

Not joking about the last part, either: my severely underclocked 4850 card consumes ~65W with RadeonHD vs ~30W with Catalyst when idle. This translates to a fan speed of ~4000RPMs (intolerable) vs ~2000RPMs (barely tolerable). (Yes, I'm going to add a big bad piece of copper and silence it, but the difference is significant.)

if your trying to justify needing PM,Xv etc before we can get assisted video decode etc working ,No we dont, its assumed after reading here and doom9, that just like the nvcuvid library API part of cuda that doesnt use anything other than the blackbox ASIC VP2 (400 MHz powered VP2 Logic),that ATI's blackbox ASIC UVD ??Mhz ! does virtually the same low power drain and so uses virtually no power to access and use its potential just sat there idel or going full wack FIFO.


OC people seem to think it doesnt matter right now and thats a massive ATI beancounter mistake for the long term as the word of mouth PR gravy train spreads and moves away from all things ATI video related.

as NV seem to have put their beancounters in check on this easy assisted decoding/encoding matter, and are working really hard full stream :p ahead to push their Blackbox VP2 Logic VP2 Logic to any and all devs closed and open right now, it appears ATi wont have anything for you for at least months if your an open dev wanting to use and advocate UVD Logic today at least....

VP2 Logic:
badaboom
http://www.cyberlink.com/eng/press_room/view_1994.html
CoreAVC, AVCNV,FFMPEG etc....

UVD Logic:
AVIVO encoder, no not really, as currenty thats still only using the CPU for its encoding.
????
????

[energyman]

popper, and you are thinking that everything is about hd content.
It isn't. Earth to popper, most people don't care about hd.

Most people care about noise. And with catalyst my 3870 is quiet (overall energy consumption 106W). On a vt, the fan howls unbearable (energy consumption 160W). As it does with r/rhd - which makes the open drivers useless for me.
Most people care about 2d performance. Oh, they don't vote for it - but read all the complaints about non-snappy windows, slow scrolling, etc.
A lot of people care about 3d. Because everything is 3d today.
A lot of people care about xv - because apps like tvtime don't even run without it, others need a lot less cpu with it (xine, mplayer).
But hd? Who watches hd content on a linux box? And what are the surces?
x720 divx5 - is that hd? if yes - newsflash, that doesn't even get my cpu away from 1ghz...

[popper]

popper, and you are thinking that everything is about hd content.
It isn't. Earth to popper, most people don't care about hd.

Most people care about noise. And with catalyst my 3870 is quiet (overall energy consumption 106W). On a vt, the fan howls unbearable (energy consumption 160W). As it does with r/rhd - which makes the open drivers useless for me.
Most people care about 2d performance. Oh, they don't vote for it - but read all the complaints about non-snappy windows, slow scrolling, etc.
A lot of people care about 3d. Because everything is 3d today.
A lot of people care about xv - because apps like tvtime don't even run without it, others need a lot less cpu with it (xine, mplayer).
But hd? Who watches hd content on a linux box? And what are the surces?
x720 divx5 - is that hd? if yes - newsflash, that doesn't even get my cpu away from 1ghz...

Earth to energyman :p

your not thinking of the far larger end game here,or seeing the long term cause and effect for that matter, its common in many circles so your not alone OC....

fact is the WORLD (is not just the USA) IS transitioning from Analogue to Digital right NOW, the world standard IS becoming HD thats true, and one day HD will be your generic SD OC.

people are changing the worlds internet usage and Video streaming etc has/IS becoming the No1 bandwidth usage very quickly, people want to encode and decode this content and will buy and use whatever is available to them to allow this task, you agree?

well just like adults stick to the food groups they learn to like in childhood, the very same thing happens in all walks of life, and that especially happens in the computer and internet markets, you agree?

do you start to see the big picture here?, as NV get peoples attention in this early stage, they are securing longer term useage of their tools and APIs, while i assume ATI bean counters and middle management (as the boardroom guys cant be that daft missing such a fundimental flaw in their cost savings as the economic downturn hits can they?)cut costs in supplying UVD Logic API documentation manpower were it's required right now, as thats what the people buying the cards, and keeping the profits coming in want now....

on the larger scale, as the economic downturn hits, people turn to their existing inhome entertainment and video, TV, DVD and newer HD kit rather than go out, theres a massive potential for new profits in cheap home/net entertainment HD Tech/SW that works, if your in the right place at the right time, NV seem to be there now, what about the others....

make no mistake about it, its not just some tunnel vision HD thing on my part, but rather, trying to have people looking for and seeing the far bigger long term picture in all things IT i write about, and try and bring to peoples attention...

as a secondary point, OC i would like all these things you point out too, but right now, the short term prioritys months/tears instead of weeks and days for UVD docs for the HW thats already on your installed shop shelf kit, so its available right now, but unusable due to lack of docs and will to write the working code examples internally ,and OC bean counters are holding things back, not authorising far more man power or overtime to push this thng through now its become clear UVD is a thing ATI customers have and want to use right now, instead of having to stand by, watching NV HW only apps appear around you.

and again, if you want to talk about "energy consumption" and being green, as usual the main stream press get it all wrong OC, people dont care about saving the planet as much as, people DO care about saving real cash on their electronic energy costs.

i like low power everything electronic, as it has the potential to then be run off a one time cost PV,micro wind, and distilled water Fual cells etc, local power stored in batterys for overnight use etc.... that saves me money long term with a one off cost, that i can perhaps offset by buying something extra power generating every other month, and get a grant at some point to pay it off..... bottom line, give me lower power netbook static CPU/GPU/MB,HD LCD,and wireless 11n/wimax access points/routers etc and i save lots later and get the jobs done i want to do now.

[energyman]

so the world is 'going digital' and more hd content will pop up in the future.
Yeah, that is nice. But that is in THE FUTURE. Not now. So there is plenty of time.

[popper]

so the world is 'going digital' and more hd content will pop up in the future.
Yeah, that is nice. But that is in THE FUTURE. Not now. So there is plenty of time.

sure, theres plenty of time if your happy always taking the left overs and being at the end of the worlds food line....

if you however want to keep some kind of reasonable income long term, you had better pull your socks up and get out there producing and flogging your goods, and building your good will....right now.

[energyman]

so tell me - how many bluray players are there for linux?

[popper]

so tell me - how many bluray players are there for linux?

as many as you can go out and buy OC :p

plugging them in is easy,but making them work without docs is all together another matter....

that would be a HW vendors not supplying drivers and docs OC but all linux users know that story all to well....

your point being i assume you cant play BR disks direclty in linux....

Ohh wait, thats another good reason to try and get UVD Logic HW assisted working code into the (linux) apps ASAP so you can rip your original payed for BR transport streams and transcode them to something you CAN use faster, or will YOU be using the NV tools for that job? , if thats what exists today probably, unless OC your going to have a word with your USENET connections and download it because you dont have the tools you need in your machine.... ;)

[energyman]

em, you might want to read up on bluray. It was made 'unrippable' - and there won't be any open source bluray players ever.

So - how many bluray players for linux are there?

none.

Will that change in the future?

no,

That leaves 'hd' digital tv - which is pretty much a joke, easily decoded and still far away and illeagally downloaded porn.

So why do you want hd decoding again?

[popper]

" It was made 'unrippable' " LOL, it appears its YOU that might want to go read up a little, (but thats OK as no one knows everything, weres the FUN in that) the doom9 threads are full of devs asking for BR 50M clips of problem BR Pro house encodes, go read that CoreAVC doom9 thread for one.

tell that "It was made 'unrippable'" to the people ripping them right now, as their only option is to transcode the HD AVC/AAC inside the BR transport streams into another container for playback on the devices they have.....

(were are YOU?)your 'hd' digital tv - might be a joke, the Uk's FTA HD BBC and others DVB-T and DVB-S(2) bitrates are fine and indeed seem to have set the standard all others world wide are measured against.

notice too, i keep mentioning "transport stream" thats the defacto standard virtually all the worlds Digital content be it that oddball USA thing, DVB-* FTA/PFS, HD DVD/BR and soon enough the online streaming content will be using as the world also moves to TCP/IP packets for all things digital ,make no mistake .TS is as important if not more so than your old AVI and the VP2 Logic and UVD Logic already works with that TS standard OC.

[energyman]

and dvb-t is just mpeg2 - which is decoded fine with even a cpu from the stone age.

And bluray? it is just a matter of time until they revoke the hacked keys - and then you are back on square one. With a fundamental difference. Since the media industry has bought the politicians, the laws changed. Ripping dvds might be legal (because there is no copy protection), ripping bluray is not.

So - where are we?
HD is not important now or in the near future. Recent CPUs (everything in the last couple of years) have no problem with content up to 720p - and I have no other films here.
2d is still not fixed - and is important. Every single second you are in front of your computer 2d performance is affecting you.
3d is important because it is the 2d's backend
and most important is power consumption. Because NOBODY wants to watch a film next to a card screaming at 4 sone

[BlackStar]

tell that "It was made 'unrippable'" to the people ripping them right now, as their only option is to transcode the HD AVC/AAC inside the BR transport streams into another container for playback on the devices they have.....
I don't get what you are trying to say... the reason for hd acceleration is watching / transcoding ripped movies?

Popper, I think we all agree that hd acceleration is important and should be implemented in the not-too-far future. However, right now there's much bigger fish to fry in the open drivers.

I really, really don't see a problem here: fglrx is set to gain hd decode acceleration in the (near?) future, so we'll have an option. R/RHD should focus on energyman's points first (esp. power management), wait for the hd dust to settle and then implement acceleration.

If it happens like this, the only people affected are:
1. amd users
2. who want to watch hd content
3. and don't want to use fglrx

Sorry, but I find it reasonable that you won't be able to have all 3 together in the near future. Agd5f explained the reason.

[RobbieAB]

and again, if you want to talk about "energy consumption" and being green, as usual the main stream press get it all wrong OC, people dont care about saving the planet as much as, people DO care about saving real cash on their electronic energy costs.

Power consumption concerns are less about being green and saving money long term, and more about thermal out put (high power consumption usually runs hot) and battery life.

You talk about the bigger picture, but you don't seem to appreciate who matters most regarding what succeeds. It's not going to be the people on the doom9 forums, it's not going to be the people buying the kit in stores. The most important customers are the big OEMs, like Dell. And guess what? For those people, one of the most important requirements is being able to score points in the marketing game, so a nice open API matters LESS than "8 hours battery life" or some other marketing gimmick.

If you want a demonstration of the significance, look at Bruce Changs recent postings to the openchrome mailing lists. He pretty much admits the Via open source initiative was a result of OEM pressure.

[Goga777]

as I mentioned before AMD have announced plans to sell the Imageon division.

sorry, where can I find more details about that ? do you mean the AMD division which is working under videocards ?

[smitty3268]

sorry, where can I find more details about that ? do you mean the AMD division which is working under videocards ?

Imageon is the cellphone division from ATI. It's actually a whole system-on-a-chip, but it sounds like AMD is just selling the graphics/multimedia IP and not some of the other stuff.

http://news.cnet.com/8301-13924_3-10145732-64.html

[bridgman]

Yep, in addition to the main PC graphics division (Radeon etc..) we had two other consumer divisions. One made graphics devices for cell phones and PDAs, while the other made specialized display products for the digital TV and set top box markets.

The first of those consumer divisions was sold to Qualcomm, and the second was sold to Broadcom.

[highlandsun]

How sad, neither of those companies has a good open source track record. (On a somewhat related note, I saw a friend playing Quake3 on his Android G1 phone. I see that Motorola will be releasing an Android phone soon; I'll be amazed if they ever release one on CDMA. Qualcomm seems to have all of that BREW environment locked up tight.)