Announcement

Collapse
No announcement yet.

"Ask ATI" dev thread

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

  • Sort of. We're moving the current code off into a legacy branch and then removing 3xx-5xx code from the main driver source tree, so beginning with Cat 9.4 all monthly Catalyst drivers will only support 6xx and up. This applies to all OSes.

    Separately, we plan to provide quarterly updates for Windows off the legacy branch, but that will mostly be fixes for security issues and maybe newly released apps/games. No support for new OS releases.

    That model won't work with Linux, since :

    (a) the equivalent of new OS releases come along pretty much every month so the legacy branch would quickly fall behind, and

    (b) most Linux users are not just expecting the current level of fglrx functionality on their 3xx-5xx GPUs but ongoing improvements in areas like video playback, 2D performance and suspend/resume.

    We looked at the options and decided that it made more sense to provide ongoing support via the open source drivers than by spending the same effort porting the current fglrx functionality to new OS and kernel versions.
    Last edited by bridgman; 03-17-2009, 04:13 PM.

    Comment


    • Thanks for clearing that up for me bridgman!

      Comment


      • Hello bridgman, I have a question about the open source drivers and Ubuntu 9.04.

        I will have to use the radeon or radeonhd driver since Catalyst 9.4 won't support my x1600 mobility. I use my laptop to work at school, and with fglrx I always set the powerstate option to 1, it saves my battery and keeps my computer quiet (thank you AMD for the auto-powerstate option :love: ).
        The question is: Will I be able to do the same thing with the open-source drivers?

        The different powerstates seem to be coded in the bios of the card (or something like thats), so maybe it is possible to set the state I want to use in the xorg.conf?

        Comment


        • bridgman, thanks for the quick response. I personally really like everything possible to be free on a system, but I can understand that in some cases there are mitigating circumstances that can prevent this. However, do you know if there are any specific problems with getting the Radeon CP microcode in a non-blob and documented format? Has ATI said they have any problems with this in the past, and has anyone asked them?

          Thank you!

          Comment


          • @static_drc have you asked Intel about their microcode blob for their cpus?

            Comment


            • @energyman Intel integrated video card drivers have no undocumented binary sections of microcode. They work very well with free software drivers. So do integrated video cards from VIA. As for AGP/PCI cards, the 3dfx Voodoo series works well with free software drivers, but they are not so powerful and are hard to come by nowadays.

              Do you know if there are difficulties in the release of the documentation of the Radeon CP microcode? What are the difficulties?

              Thank you!

              Comment


              • static_drc I said CPU not GPU.

                If you are 'Hardcore' about GPUs you have to be hardcore about CPUs as well - which rules out intel. Or AMD (who do the microcode updates via bios), and probably via too.

                Comment


                • Originally posted by static_drc View Post
                  However, do you know if there are any specific problems with getting the Radeon CP microcode in a non-blob and documented format? Has ATI said they have any problems with this in the past, and has anyone asked them?
                  I guess the first thing I should mention is that I work for ATI/AMD and (among other things) organize the technical reviews of information we hope to release.

                  At the start of the open source graphics project one of the tasks was working out the overall approach -- which areas would be most useful to developers, which areas posed the highest risk for us, and what combination of information would let us support the development of good free drivers without posing an unacceptable risk in the other markets where we sold the same products (ie other OSes). Opening the microcode was identified as one of the highest risk areas, with no apparent benefit (since other GPUs also use microcode in the same way but either hide it on the chip or load it transparently from ROM at power-up).

                  I don't want to go into details, but the problem in a nutshell is DRM. On other platforms, we are obligated to deliver secure and robust DRM implementations (Digital Rights Management), and that becomes much more difficult if we expose any of the hardware internals other than the driver programming model (registers and command packets). This is also why we have not released information in areas such as the UVD video processor. Again, the risk is not what could be done with Linux, but what could be done with the information on other OSes.

                  The open source graphics project was basically built on the idea that we could open up enough information to allow the development of fully free drivers *without* revealing enough information -- either directly or by "moving the starting point for reverse engineering" -- to put our products at risk in other markets. So far the project has been well received, and hopefully we can depend on the free software leaders to treat all non-free microcode equally, whether it be loaded by the driver or burned into the chip.
                  Last edited by bridgman; 03-17-2009, 07:14 PM.

                  Comment


                  • @energyman I am so sorry! I misread what you said. AMD and Intel CPUs work fine with the Linux-libre kernel, which only contains free software.

                    Do you know if there are any problems with ATI releasing the documentatin for the Radeon CP microcode? What are the problems?

                    If this is a difficult question, or if this is not the right place to ask, then please let me know.

                    EDIT: I'm sorry! My question was answered while I was typing my reply. I really appreciate you taking the time to answer my question. I now understand the reasons for keeping the microcode the way it is. I continue to support ATI in how much they contribute to the free and open source software community. Thank you!
                    Last edited by static_drc; 03-17-2009, 06:50 PM.

                    Comment


                    • static_drc, I think the reason the CPUs work with Linux-libre is that microcode patches are *usually* applied by the BIOS at system startup, before the kernel runs. Microcode loaders were added to the kernel in order to simplify system maintenance and improve reliability; removing them from the kernel means that the user either runs with older CPU microcode or is forced to flash their BIOS image with a new blob to get the latest microcode.

                      Taking CPU microcode blobs out of the kernel doesn't get rid of them, it just forces them to be managed in another (less convenient) part of the system.
                      Last edited by bridgman; 03-17-2009, 07:44 PM.

                      Comment


                      • Originally posted by bridgman View Post
                        Taking CPU microcode blobs out of the kernel doesn't get rid of them, it just forces them to be managed in another (less convenient) part of the system.
                        Actually iirc Linux kernel 2.6.29 allows loading of the CPU microcode on-boot via the kernel. I've understood this is a new feature since I didn't see it in the CPU config section earlier but I did notice it there while trying out 2.6.29. (While the AMD microcode didn't even seem to apply for my CPU. Meh) The idea might be that while you do need some kind of microcode to boot at all, you get a more up-to-date version of the microcode when the system starts. If you want to check what I mean, look for symbols MICROCODE_AMD and MICROCODE_INTEL.

                        Comment


                        • Originally posted by bridgman View Post
                          so beginning with Cat 9.4 all monthly Catalyst drivers will only support 6xx and up. This applies to all OSes.

                          Separately, we plan to provide quarterly updates for Windows off the legacy branch, but that will mostly be fixes for security issues and maybe newly released apps/games. No support for new OS releases.
                          Well doesn't the 9.3 driver add official support for windows7 ?
                          So windows users get windows7 support before they get "No more new OS support".

                          Comment


                          • AFAIK the Win7 driver API (WDDM 1.1) is for 6xx-and-up products only since it requires DX10 support.

                            Comment


                            • Originally posted by nanonyme View Post
                              Actually iirc Linux kernel 2.6.29 allows loading of the CPU microcode on-boot via the kernel. I've understood this is a new feature since I didn't see it in the CPU config section earlier but I did notice it there while trying out 2.6.29. (While the AMD microcode didn't even seem to apply for my CPU. Meh) The idea might be that while you do need some kind of microcode to boot at all, you get a more up-to-date version of the microcode when the system starts. If you want to check what I mean, look for symbols MICROCODE_AMD and MICROCODE_INTEL.
                              Yep. My understanding, though, is that a couple of "totally free" Linux projects take the CPU microcode and associated loaders out again.

                              As you can imagine, there is a lot of debate about this, and some *very* long email threads

                              Comment


                              • Originally posted by bridgman View Post
                                AFAIK the Win7 driver API (WDDM 1.1) is for 6xx-and-up products only since it requires DX10 support.
                                Well i didn't know that.

                                Comment

                                Working...
                                X