Announcement

Collapse
No announcement yet.

The Linux 2.6.36 Kernel Will Have Some Fun DRM

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

  • #16
    Originally posted by yotambien View Post
    I know what you mean. Still, coming from somebody with the "AMD Linux" tag it sounds hilarious.
    Yep. The knowledge already exists, of course, it's just spread around tens of millions of lines of code and (temporarily, at least) the heads of hundreds of developers, and it would take dozens of people to find and extract that information. Alex and Richard do work with the hardware and proprietary driver teams but since most of the design work for a new chip happens 1-2 years before launch it's hard to find anyone who remembers the details -- and the proprietary driver code is *way* too big to be much help when looking for the "one bit you missed".

    Now that we are more or less caught up with new hardware introduction we're going to see if we can combine the open source driver design effort with the proprietary driver design activities, so we can find "the right heads" more efficiently. Don't know how well that will work but hopefully over the next year we can make that happen.

    Comment


    • #17
      Originally posted by bridgman View Post
      Alex and Richard do work with the hardware and proprietary driver teams but since most of the design work for a new chip happens 1-2 years before launch it's hard to find anyone who remembers the details
      Sounds like this is now the time for Alex or Richard to ask Question about SI, NI and Fusion

      Comment


      • #18
        Originally posted by bridgman View Post
        Yep. The knowledge already exists, of course, it's just spread around tens of millions of lines of code and (temporarily, at least) the heads of hundreds of developers, and it would take dozens of people to find and extract that information. Alex and Richard do work with the hardware and proprietary driver teams but since most of the design work for a new chip happens 1-2 years before launch it's hard to find anyone who remembers the details -- and the proprietary driver code is *way* too big to be much help when looking for the "one bit you missed".

        Now that we are more or less caught up with new hardware introduction we're going to see if we can combine the open source driver design effort with the proprietary driver design activities, so we can find "the right heads" more efficiently. Don't know how well that will work but hopefully over the next year we can make that happen.
        In that case, I didn't know what you meant. I thought the situation was something like, "we now know how to correctly program these chips within the OSS design". Instead, it seems that you were actually missing hardware details.

        Now, this comment obviously comes from somebody whose coding skills go no further than solving equations in python, but, if some OSS developers have access to the millions of lines of code you talk about, i.e. they work not only from the released documentation but also from closed code, how do they manage to restrict themselves and not implement the solutions adopted in the closed driver? Are the drivers so different in complexity, size and design that there are no low hanging fruits to be taken from that information? Not that I doubt of their professional integrity, of course : )

        Comment


        • #19
          Originally posted by trapDoor View Post
          Almost. There is still support for HDMI Audio output to do and that is related to kernel. But yeah, most of the fancy kernel-based stuff like KMS, power management, suspend support - they appear to be completed.
          Hopefully, this will put the performance in the range of the 4xxx series. On the open source drivers, the 5xxx is significantly slower on Fedora than the 4xxx. None the less, I love my Radeon HD 5750.

          Comment


          • #20
            Originally posted by yoshi314 View Post
            i wonder how much difference does hyperz make, in raw numbers.
            Nothing major. At some point in the past, I disabled Hyper-Z in Windows using a tweak tool. It was with a Radeon 9800Pro. There was no difference in performance, at least when using 3DMark.

            Comment


            • #21
              Intel GMA 4500MHD?

              I really hope Intel will be on time (2010 Q3) with its 4500MHD full hardware H.264 support.

              Comment


              • #22
                Originally posted by yotambien View Post
                In that case, I didn't know what you meant. I thought the situation was something like, "we now know how to correctly program these chips within the OSS design". Instead, it seems that you were actually missing hardware details.
                It's a bit of both. In theory we have all the hardware details; in practice we have the hardware details from when the hardware was designed, which is theoretically the same as what was implemented but in practice may be a bit different. The last couple of generations haven't had that problem but it was a real challenge back in the 5xx/6xx days. We can also comb through bug reports and the associated fixes, but anyone who has searched an engineering-level bug tracker for matches to their symptoms understands how fruitless that can be despite everyone's best efforts.

                In many cases we know what registers need to be programmed and what to put in them, but there are subtle seauencing dependencies which are not documented anywhere.

                The devs have fairly easy access to 99% of the HW details and can work through the driver and hardware teams to get to maybe 99.9% fairly easily. That last 0.1% is a real pain though... and quite often the chip seems completely broken until you find that last 0.1% ;(

                There are all kinds of troubleshooting tools, it's just that modern high end GPUs are really big and complex. That works OK when the effort is spread across thousands of people, but it's a bit hard for a small team to do the same. That's why I have hope for piggybacking on the original design effort.

                Originally posted by yotambien View Post
                Now, this comment obviously comes from somebody whose coding skills go no further than solving equations in python, but, if some OSS developers have access to the millions of lines of code you talk about, i.e. they work not only from the released documentation but also from closed code, how do they manage to restrict themselves and not implement the solutions adopted in the closed driver? Are the drivers so different in complexity, size and design that there are no low hanging fruits to be taken from that information? Not that I doubt of their professional integrity, of course : )
                Normally the devs work from HW documentation, diagnostic code and information they get from hardware and driver teams (not the actual driver code). Anything pulled directly from the proprietary driver code needs to be reviewed to a greater extent than normal. We basically need to differentiate between "how the chip is programmed" (which we want to release), "how our driver is designed", and "how the chip is designed" (we don't want to release the last two. The practices are constantly evolving, but this is what we do today.

                EDIT - I wonder if having to delete and repost rather than edit is artificially inflating my post count ?

                Comment


                • #23
                  In other news, R800 (EG) acceleration will be picked up in Linux Kernel 2.6.48! It means you suckers who bought the cards will wait for another 3 years! haha

                  Comment


                  • #24
                    Originally posted by Nille View Post
                    Sounds like this is now the time for Alex or Richard to ask Question about SI, NI and Fusion
                    SI OSS support: 2016 AD
                    NI OSS support: 2020 AD
                    Fusion support: who knows?

                    Comment


                    • #25
                      Originally posted by FunkyRider View Post
                      In other news, R800 (EG) acceleration will be picked up in Linux Kernel 2.6.48! It means you suckers who bought the cards will wait for another 3 years! haha
                      It's already in 2.6.35. I'm sure some bugs will be found but AFAIK we are running EXA, Xv and 3D on 2.6.35 today.

                      You're not wrong though. It will be in 2.6.48 as well

                      Comment


                      • #26
                        Originally posted by FunkyRider View Post
                        SI OSS support: 2016 AD
                        NI OSS support: 2020 AD
                        Fusion support: who knows?
                        Alex already has a Fusion board (the Ontario APU).

                        Comment


                        • #27
                          Originally posted by bridgman View Post
                          Alex already has a Fusion board (the Ontario APU).
                          Me wants, either!

                          Comment


                          • #28
                            I actually saw quite a big difference with HyperZ on my nasty Radeon IGP 345M. It turned what was otherwise a completely useless piece of crap into something that was almost usable. I was able to switch from 800x600 to 1024x768 in some games like RTCW. Yes, I realise this chip was never meant for games but that's all I had at the time.

                            Comment


                            • #29
                              Originally posted by bridgman View Post
                              Alex already has a Fusion board (the Ontario APU).
                              Can I haz one? Pleaze.

                              Comment


                              • #30
                                can anyone explain benefits of this? " R600/700 tiling support"

                                Comment

                                Working...
                                X