No announcement yet.

AMD Releases Open-Source R600/700 3D Code

  • Filter
  • Time
  • Show
Clear All
new posts

  • #91
    Originally posted by agd5f View Post
    that's called tearing. It should be gone for most users with the latest driver from ati git or the rc release.

    Looks like your driver is too old.
    Hmm, thanks for the info.

    I'll look into it.


    • #92
      Yep, from the log messages your driver is a couple of months old, which would normally be fine but it won't include the recent tear-free work.
      Test signature


      • #93
        Originally posted by bridgman View Post
        Based on the error message, I expect the radeon code in the latest package might not be new enough. Can you get a date or commit number from your log ? The tear-free code only went in a couple of weeks ago.
        Is that tearing the driver itself or bad vsync? Seen plenty of that kind of tearing in (unrelated) landscape-mode for Opera Mobile currently.

        Originally posted by bridgman View Post
        NuShrike, as I mentioned before AMD have announced plans to sell the Imageon division. I have asked internally about the possibility of providing open source support for the handheld products, but I don't think that is likely to happen until new owners have a chance to participate in the decision.
        Thanks for an answer, even if it seems to me there would be complications with the Imageon sharing some internal elements with older Radeons such as raster op codes.

        At least there's some information for moving forward.
        Last edited by NuShrike; 30 December 2008, 08:53 PM.


        • #94
          Tearing is caused by drawing to the same part of the screen that's being scanned out. Right now, there isn't a good way to get rid of it without a performance hit (the radeon anti-tearing code stalls drawing until the scanline has passed the part of the screen the program wants to draw to.) In the future, there's talk of making a double-buffered framebuffer and pageflipping between scanouts.


          • #95
            Guys, tearing is fixed on R500!!! Don't spread an old myth, now. (or at least it doesn't work for TechMage89)

            You should always use the most up-to-date stuff, though

            I'm just soooo happy about the tearing being gone, I placed it as my status in Facebook... I'll keep repeating it over and over... and over...


            • #96
              Originally posted by octoberblu3 View Post
              Absolutely fantastic! Thank you everyone for working towards a better ATI/AMD tomorrow.
              Having todays HW tomorrow!

              Well.. It would be really great if communications developed to the point of having programming specs earlier than cards...

              (Yes if coding specs change last minute then drivers need minor change + rebuild.)


              • #97
                It's already happened. Alex has been sitting in on some of the next-generation GPU design meetings and we are already going through the internal docs for the next couple of generations. We still don't plan to write much more than sample code until after the product launches, but we should at least know how to make the chip run by launch time. For some products we will want to have completed drivers at launch, but those will be handled on a case-by-case basis.

                Catching up quickly with 6 years of hardware development was really difficult. We're hoping that keeping up will be easier.
                Last edited by bridgman; 31 December 2008, 01:53 AM.
                Test signature


                • #98
                  Yes, this is a good idea. When you think of the delay from Windows driver support to Linux (fglrx) for some series ATI did not look good at all - NV always provided beta drivers for new products. Longest delay maybe 1-2 weeks.


                  • #99
                    I think part of the problem is the fglrx release cycle. It works great for open projects because you can always get the latest features as soon as they're coded while at the same time providing a predictable release schedule for distros that include your program.

                    But for closed software like fglrx you really lose both of those benefits, since it often means long waits for the release of implemented features, plus, since you can't easily test pre-release code you can't even rely on features to be available or stable at release.

                    Making "test" builds easily available might fix a lot of that problem, but would probably also be a lot of extra work on such a frequent and rigid release schedule.

                    Just my thoughts.

                    /me off to pray to the video acceleration gods for documentation + fglrx support


                    • Originally posted by RealNC View Post
                      I think it's more than that. We all tend to forget a bit what "open" means. It mainly means that those corporations have access to the source and that brings some benefits, like being able to adapt the code or pay someone to adapt it (or fix it) to their needs. The romantic part of "open" is nice to read about, but we mostly care about the practical benefits. It would be nice if I could fix or pay someone to fix fglrx for me, no?
                      For example movie studios like Dreamworks who build render farms and workstations with high performance needs have a bunch of in-house techs customising their linux workstations and servers for their specific benefits. Under a closed Unix model they had to rely on the OS provider for customisations which invariably means more cash.

                      Of course the film processing apps they themselves develop and sell are all closed sources, but surprisingly most of them have linux versions