Page 12 of 20 FirstFirst ... 21011121314 ... LastLast
Results 111 to 120 of 199

Thread: AMD Releases Open-Source R600/700 3D Code

  1. #111
    Join Date
    Jan 2007
    Posts
    459

    Default

    Quote Originally Posted by Uber View Post
    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/wor...nts.htm#MPEG-4

  2. #112
    Join Date
    Jan 2007
    Posts
    459

    Default

    Quote Originally Posted by RealNC View Post
    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...13E8!188.entry
    Last edited by popper; 01-03-2009 at 12:40 AM.

  3. #113
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,544

    Default

    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.
    Last edited by bridgman; 01-03-2009 at 01:13 AM.

  4. #114
    Join Date
    Jan 2007
    Posts
    459

    Default

    Quote Originally Posted by bridgman View Post
    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...odec/?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/...ry/thread.html we as ATI advocates are going nowere.

  5. #115
    Join Date
    Jan 2007
    Posts
    459

    Default

    Quote Originally Posted by bridgman View Post
    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/...ry/thread.html

  6. #116
    Join Date
    Jan 2007
    Posts
    459

    Default

    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/...ry/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-nvi...u-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!
    Last edited by popper; 01-03-2009 at 02:42 AM.

  7. #117
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,544

    Default

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

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

    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.
    Last edited by bridgman; 01-03-2009 at 02:51 AM.

  8. #118
    Join Date
    Jan 2007
    Posts
    459

    Default

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

  9. #119
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,544

    Default

    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.
    Last edited by bridgman; 01-03-2009 at 03:20 AM.

  10. #120
    Join Date
    Jan 2007
    Posts
    459

    Default

    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....
    Last edited by popper; 01-03-2009 at 03:26 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •