Announcement

Collapse
No announcement yet.

ATI R600g Gains Mip-Map, Face Culling Support

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

  • #61
    Originally posted by Agdr View Post
    Isn't the VA-API support through xvba-video good enough for the closed driver? (I haven't tried it personally, so I have no opinion)
    XvBA has been problematic with many cards and has been broken with Evergreen cards since forever. I think the author of xvba-video himself was so frustrated with the state of XvBA that he stated to not really care much about it. If he decides to abandon it then sooner or later there's a real chance of ABI breakage.

    Sure you can reverse-engineer it, but why should you. If AMD was as a good open source citizen such as Intel it would just open source their XvBA library. Not that I expect them to do so, but they could at least open up the native API. Even Nvidia is not like that!

    Comment


    • #62
      Originally posted by bridgman View Post
      That doesn't do much for the consumer PC client market, of course, so that's the next thing we need to address. For now, gbeauche's VA-API to XvBA adapter is a real nice way to try out the code while we finish development.
      When, in 2020? I see you already add support for the Llano and Ontario APUs to XvBA but you could not even fix the Evergreen bug .

      Comment


      • #63
        Originally posted by Agdr View Post
        [...]
        Why not just adapt to the changes in the open drivers?
        The Linux kernel has an approximately 3 month release cycle, which should give time to prepare at least a Linux-only update for any ABI changes.
        Also, incompatible changes to the ABI tend to be frowned upon (see the Nouveau ABI break debate for instance).
        [...]
        I don't think the closed source driver kernel module will ever want to merge upstream with linux kernel, there is an ABI/API freeze that comes with linux kernel, it's a good thing for most of the kernel as 99% of the others driver have simpler API/ABI interface and most of them goes through a common interface that abstract hw details.

        GPU on the other hand is quite unique (i might be lacking knowledge on some part of the kernel here so feel free to correct me) each hw is exposing its own API to the userspace, each API is different and close to the hw. As it's we big chunk of code we never get the API right the first time, if i were to redo KMS today there is few major things i would change.

        Take in this into account, i am pretty sure closed source people want to keep their freedom of changing the API from one version to the other (fglrx bundle kernel + userspace alltogether) if they had to keep backward compat it would likely endup with a kernel module with several different path and quickly grows like a monster blob.

        Comment


        • #64
          Originally posted by monraaf View Post
          When, in 2020? I see you already add support for the Llano and Ontario APUs to XvBA but you could not even fix the Evergreen bug .
          Apples and oranges. Support for new GPUs comes at least semi-automatically as a result of code sharing across multiple OSes. Bug fixing in Linux-specific code has to be done the old fashioned way. We'd kinda like to finish and release XvBA before anyone complains that we're not fixing bugs fast enough. Remember that XvBA hasn't actually been announced outside of the embedded market, and we don't *have* an embedded Evergreen part.

          Comment


          • #65
            Make that "we don't have an embedded Evergreen part *yet* ..."

            Stinkin' edit limit.

            Comment


            • #66
              Originally posted by bridgman View Post
              Apples and oranges. Support for new GPUs comes at least semi-automatically as a result of code sharing across multiple OSes. Bug fixing in Linux-specific code has to be done the old fashioned way. We'd kinda like to finish and release XvBA before anyone complains that we're not fixing bugs fast enough. Remember that XvBA hasn't actually been announced outside of the embedded market, and we don't *have* an embedded Evergreen part.
              It doesn't really matter if you have officially released it or not. People know that their AMD GPU has support for hardware accelerated H.264 decoding, and they know that unlike with products of the competition they can't make use of it in Linux. So they are going to complain, whether you like it or not .

              So in my eyes even though you have not officially released XvBA, you have not fixed this Evergreen bug that has been plaguing me for over 6 months. Naturally I'm not very satisfied with this!

              Comment


              • #67
                Sure, complaining about us not releasing a consumer PC-oriented video decode solution is fair.

                It's important that you complain about the right thing if you want anyone other than me to listen

                Comment


                • #68
                  Originally posted by monraaf View Post
                  Even Nvidia is not like that!
                  On the other hand, nVidia would likely not even reply to queries like the ones being made here, and contributes essentially nothing to open source, while AMD does contribute the foundations for open source development both as documentation and code and seems willing to improve things if possible.

                  Comment


                  • #69
                    Sooooo...let's see. From what I am hearing, the best way to improve the situation with Linux for Linux enthusiasts like myself is to change the market. Converting as many individuals who are likely to be satisfied with Linux is a good start. That way, there will be less Windows/Mac market share which would reduce the benefit to firms like ATI to keep certain parts of their drivers closed.

                    Comment


                    • #70
                      Originally posted by Prescience500 View Post
                      Sooooo...let's see. From what I am hearing, the best way to improve the situation with Linux for Linux enthusiasts like myself is to change the market. Converting as many individuals who are likely to be satisfied with Linux is a good start. That way, there will be less Windows/Mac market share which would reduce the benefit to firms like ATI to keep certain parts of their drivers closed.
                      No that wouldn't help, or is not the problem.

                      The problem is not enough developpers that do optimisation work. If you want to imrpove the Linux situation then... well... go contribute.

                      The docs are out there.

                      Realy that's the only way to go right now...

                      Comment


                      • #71
                        Originally posted by Prescience500 View Post
                        Sooooo...let's see. From what I am hearing, the best way to improve the situation with Linux for Linux enthusiasts like myself is to change the market. Converting as many individuals who are likely to be satisfied with Linux is a good start. That way, there will be less Windows/Mac market share which would reduce the benefit to firms like ATI to keep certain parts of their drivers closed.
                        And seduce them from Windows 7 how? You'll be telling them that the extra cash they shelled out for a discrete card will only get them 70% of the capabilities of a Windows driver, unless of course, they can convince 100 of their friends to switch. Then, only then, will ATI respond with a driver that meets or exceeds the Windows driver.

                        Uhm, yeah. That'll work.

                        Comment


                        • #72
                          latest r600g and ioquake3
                          http://mirror.netkas.org/r600g/q3_1.png

                          http://mirror.netkas.org/r600g/q3_2.png

                          http://mirror.netkas.org/r600g/q3_3.png

                          Comment


                          • #73
                            Originally posted by glisse View Post
                            if i were to redo KMS today there is few major things i would change.
                            If and when there will be a comprehensive radeon KMS documentation, this stuff would probably deserve to be included. As in, post-implementation thoughts, how could it be better if someone ever wants to go back at it.

                            Comment


                            • #74
                              Originally posted by netkas View Post
                              latest r600g and ioquake3
                              Some patience? Probably more sense to check git log on which features have been implemented and then go try with the respective demos to see if the implementations are sound and work.

                              Comment


                              • #75
                                Actually, I'm quite impressed that it runs ioquake already. Once it can run OpenArena more or less like r600c, I'll switch

                                Comment

                                Working...
                                X