Announcement

Collapse
No announcement yet.

Tear-Free Acceleration For ATI EXA, Xv

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

  • #46
    Originally posted by ivanovic View Post
    Uhm, there is a very good reason for radeonhd:

    It works better than radeon. That is at least on my system with a hd3850 it is working better. Do not ask me why, that is just the case. Somehow I think that the default for everything till r5xx will be xf86-video-ati where for everything later on it will likely be xf86-video-radeonhd.

    No idea how long it will really take till kernel mode setting will be available. This might as well take many more months. Until then for r6xx+ hardware, radeonhd is IMO preferable.
    I understand that some people believe that radeonhd has some unexplainable, almost religious value.. It's a shame, but there is nothing I can do about it. So let me ask you what makes radeonhd preferable? They switched over to using atombios, and are recycling the acceleration code from radeon anyway... Radeon is more mature, and offers more functionality. So what -exactly- makes radeonhd preferable?

    I'm sorry, I've tried, but I just cant see anything more then a waste of valuable time and effort.

    Comment


    • #47
      Originally posted by some-guy View Post
      At that point (when radeonhd was started, and radeon didn't support r500+), radeon was meant to support r100-r400 cards, radeonhd was meant to support r500+, the problem came with atombios. radeonhd said that using the registers diretly is the better (and free-er) solution, but amd wanted radeonhd to use atombios first, then after it was implemented properly, use registers. But radeonhd still used the registers, so radeon started implementing r500+ support with atombios.

      Then radeon went ahead in support, and started implementing things faster that radeonhd.
      So things didnt work out the way things had been envisioned. I can understand that, But in that case why is it still being funded and developed? Once it was discovered that radeon was capable of doing what needed done faster and cheaper than radeonhd, why wasnt it killed right then and there?

      The radeonhd devs are fully capable and highly qualified, so why arent they working on radeon right now?

      Comment


      • #48
        Originally posted by duby229 View Post
        The radeonhd devs are fully capable and highly qualified, so why arent they working on radeon right now?
        FWIK, mostly disagreements on how things should be done.

        I'm sure one will be dropped once kms is finished, because at that time the main differences will be 2D and video acceleration, which imho isn't enough reason to have 2 (2D) camps.

        BTW, both projects use the same drm and 3D code...

        Comment


        • #49
          Or even better, they could merge :P One can dream..
          What matters most to me right now is the 3D, I can't wait till they move to Gallium, but I think that won't be till next year..

          Comment


          • #50
            Originally posted by Extreme Coder View Post
            Or even better, they could merge :P One can dream..
            What matters most to me right now is the 3D, I can't wait till they move to Gallium, but I think that won't be till next year..
            Nope definitely not till next year.. My biggest complaint is that I cant get the damn xserver to build from git for some damn reason, and nobody seems to have any explanation why. I've asked on this forum several times. I've asked on gentoo's forums several times. I've asked on several mailing lists several times, and so far I've got nothing from nobody. I mean do I actually have to wait until next year?

            ATi, do you actually expect people to wait that long? DRI as it is now may not be all that great, but at least the infrastructure is there. Why not get everybody together and stabilize the drivers for DRI right now, and then start working on DRI2? That way we could have a stable and reliable driver now --AND-- later...

            Makes sense to me...... But of course lets all vote for change...

            Comment


            • #51
              Uhm, DRI has been working fine for me for about a month now. Gallium isn't in any way essential to 3d working. It's just an easier (and potentially more flexible) way of making DRI drivers. Mesa 7.1 has now been released, so the Xserver 1.5 should be released shortly.

              We do get 3d now and later. Now it works. Later it will work better.

              Also, reagarding the point of radeonhd, it's more compact and clean, as well as faster. The ati driver has a lot of legacy code for older chips and doesn't do the (faster) native modesetting for new ones. This should all be less relevant when KMS arrives, because the 2d accel/TexturedVideo of the two drivers is pretty much the same.
              Last edited by TechMage89; 08-30-2008, 09:50 PM.

              Comment


              • #52
                Originally posted by TechMage89 View Post
                Uhm, DRI has been working fine for me for about a month now. Gallium isn't in any way essential to 3d working. It's just an easier (and potentially more flexible) way of making DRI drivers. Mesa 7.1 has now been released, so the Xserver 1.5 should be released shortly.

                We do get 3d now and later. Now it works. Later it will work better.
                Well, AFAIK, OpenGL 2 comes with Gallium.

                Comment


                • #53
                  Well, AFAIK, OpenGL 2 comes with Gallium.
                  Only because the devs don't think it's worth the effort to continue to pour effort into advancing a depreciated driver framework (well technically Gallium isn't a framework, but I'm not sure what exactly to call it)

                  Comment


                  • #54
                    Originally posted by TechMage89 View Post
                    Uhm, DRI has been working fine for me for about a month now. Gallium isn't in any way essential to 3d working. It's just an easier (and potentially more flexible) way of making DRI drivers. Mesa 7.1 has now been released, so the Xserver 1.5 should be released shortly.

                    We do get 3d now and later. Now it works. Later it will work better.

                    Also, reagarding the point of radeonhd, it's more compact and clean, as well as faster. The ati driver has a lot of legacy code for older chips and doesn't do the (faster) native modesetting for new ones. This should all be less relevant when KMS arrives, because the 2d accel/TexturedVideo of the two drivers is pretty much the same.
                    How about working on making it stable so that those of us who dont know that voodoo you do can take advantage of it as well....

                    And what exactly has native modesetting done? Dalay after delay, it;s over a year now with no progress, and and has been dropped in favor of the same kind of modesetting that radeon already does...

                    Once modesetting is moved into the kernel and radeonhd is using radeons acceleration code what then will have been the point? I guess I just dont understand the religion...

                    Comment


                    • #55
                      AtomBIOS-based modesetting is very good for basic support (and I think it's stupid that the radeonhd driver didn't take advantage of it earlier) but AtomBIOS has errata/doesn't work that well on some hardware. Native modesetting is also faster (there is a noticeable difference how fast X takes to start up between radeon and radeonhd).

                      The code will very shortly be stable. With Xorg 7.4, 3d should work fine up through r500.

                      RadeonHD already has the acceleration code from radeon. KMS will have its own modesetting code, from what I understand, it will use atombios, but I don't think that rules out using native modesetting code for some cards later on.

                      Comment


                      • #56
                        Originally posted by TechMage89 View Post
                        AtomBIOS-based modesetting is very good for basic support (and I think it's stupid that the radeonhd driver didn't take advantage of it earlier) but AtomBIOS has errata/doesn't work that well on some hardware. Native modesetting is also faster (there is a noticeable difference how fast X takes to start up between radeon and radeonhd).

                        The code will very shortly be stable. With Xorg 7.4, 3d should work fine up through r500.

                        RadeonHD already has the acceleration code from radeon. KMS will have its own modesetting code, from what I understand, it will use atombios, but I don't think that rules out using native modesetting code for some cards later on.
                        Like I said, I guess I just dont understand the religion.

                        If KMS could support native modesetting down the line somewhere then why did radeonhd waste time on it? If it already uses radeons acceleration code then why did they waste even more time on that?

                        The way I see it is that so far radeonhd offers --nothing-- that radeon doesnt already offer in a more complete and stable package, right now. And never will. Same thing with fglrx. The problem with radeon is that it isnt complete or stable enough. But it --could-- be. If everybody would just stop working against each other and consolidate on a common goal working together and sharing resources.

                        radeonhd and fglrx both need to be scrapped and the folks working on the linux portion of both these drivers need to put there attention towards radeon right now while the opportunity still exists. The window is closing, it wont be available much longer. If ATi lets this golden nugget slip by, they probably wont catch up ever again.

                        Comment


                        • #57
                          Originally posted by duby229 View Post
                          Like I said, I guess I just dont understand the religion.

                          If KMS could support native modesetting down the line somewhere then why did radeonhd waste time on it? If it already uses radeons acceleration code then why did they waste even more time on that?

                          The way I see it is that so far radeonhd offers --nothing-- that radeon doesnt already offer in a more complete and stable package, right now. And never will. Same thing with fglrx. The problem with radeon is that it isnt complete or stable enough. But it --could-- be. If everybody would just stop working against each other and consolidate on a common goal working together and sharing resources.

                          radeonhd and fglrx both need to be scrapped and the folks working on the linux portion of both these drivers need to put there attention towards radeon right now while the opportunity still exists. The window is closing, it wont be available much longer. If ATi lets this golden nugget slip by, they probably wont catch up ever again.
                          What chance are you talking about that later on won't exist?

                          Comment


                          • #58
                            Originally posted by Extreme Coder View Post
                            What chance are you talking about that later on won't exist?
                            ATi has no real competition right now... nvidia doesnt have an x86 chip, so once fusion hits the market, nvidia will be relying solely on discreet products to get by.. And Intel doesnt have anything compelling on the graphics side.

                            However this is only a short term condition.... The rumormill has it that nvidia is working on designing an architecture that will be compatible with X86 on the front end, which puts them back in the game... And Intel will have Larrabee...

                            The only thing nVidia needs is a top end CPU, and the only thing Intel needs is a top end GPU, and they are both working on exactly those things.....

                            Comment


                            • #59
                              Duby, you're being a bit abrasive and also unrealisitc. Radeon and radeonhd are *very* similar drivers. Very little effort is being duplicated at this poing and a lot of code is being shared. RadeonHD is arguably the better driver since the inclusion of ATOMBios, which enables it to do modesetting natively for cards that it knows about, and with ATOMBios for everything else. Also, the acceleration code for r600+ is totally different from anything prior, so including in radeon would be rather impractical.

                              Saying fglrx needs to go away is rather impractical. The mesa 3d driver will never equal the 3d performance of fglrx, simply because ATI spends the time and money to optimize their driver for specific games and has more resources at their desposal. The mesa driver may get withing 10-20 percent of fglrx, but probably no closer. ATI can't very well release code that contains IP that isn't theirs, so open-sourcing fglrx isn't practical either. Fglrx will always have a place, but hopefully a more marginal one as the open-source driver improves.

                              Comment


                              • #60
                                Originally posted by TechMage89 View Post
                                Saying fglrx needs to go away is rather impractical. The mesa 3d driver will never equal the 3d performance of fglrx, simply because ATI spends the time and money to optimize their driver for specific games and has more resources at their desposal. The mesa driver may get withing 10-20 percent of fglrx, but probably no closer.
                                Maybe for the current generation of cards, but that won't be true forever. As open-source developers come up with graphics/memory management/etc. optimisations, a technology base will develop that will feed from and into other graphics drivers, ideas will be shared, and performance will increase exponentially. By that point, closed-source developers will be re-implementing some ideas from the open-source community (or straight-out stealing code if they dare), and future hardware will be developed with [then-]exisiting technology in mind. If companies like AMD are bringing out technologies like Fusion, they need to support it out of the box on open OSes, so they'll need to continue commissioning open drivers, which will also drive the closed-source driver closer the open one(s).

                                At least that's the way I'd like it to happen. There's currently a lot of value in fglrx, and there will be for a while, but I'd gladly take a substantial performance hit for an open driver - I already am taking a minor performance hit running Windows games on Wine/Cedega anyway

                                Comment

                                Working...
                                X