Announcement

Collapse
No announcement yet.

AMD Releases Open-Source R600/700 3D Code

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by sundown View Post
    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!!!

    Comment


    • 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

      Comment


      • Originally posted by d2kx View Post
        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:

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

        Comment


        • Originally posted by bridgman View Post
          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/...ry/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/...er/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.
          "

          Comment


          • Originally posted by BlackStar View Post
            > > 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

            Comment


            • 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

              Comment


              • 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-02-2009, 11:40 PM.

                Comment


                • 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, 12:13 AM.

                  Comment


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

                    Comment


                    • 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

                      Comment


                      • 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, 01:42 AM.

                        Comment


                        • 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, 01:51 AM.

                          Comment


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

                            Comment


                            • 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, 02:20 AM.

                              Comment


                              • 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, 02:26 AM.

                                Comment

                                Working...
                                X