Announcement

Collapse
No announcement yet.

RadeonHD Driver To Use AtomBIOS

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

  • RadeonHD Driver To Use AtomBIOS

    Phoronix: RadeonHD Driver To Use AtomBIOS

    We've talked all too often about AtomBIOS and there being two different open-source drivers that support the same ATI Radeon hardware with the key architectural difference between the two just being the use of this video BIOS abstraction layer. From the beginning, AMD was planning to have their Novell partners use AtomBIOS when writing this new (at the time, R500/600) driver, but the developers ultimately declined. These developers have expressed their opinions on AtomBIOS, which range from it being an unbearable mess to this design being nothing more than writing open-source code to power someone else's closed-source work. However, under pressure by AMD, the developers are now preparing to use AtomBIOS to a much greater extent within the xf86-video-radeonhd driver. In this article we'll tell you more about what's gone on and where you can checkout this AtomBIOS-bearing RadeonHD driver.

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    and settling for a de facto standard driver for the R600+ GPUs
    I think you meant R500+.

    they will begin focusing on open-source 3D support for the Radeon HD 4800 series
    ...and Radeon HD 3000 series, I assume.

    ...

    Interesting changes, I like that the development will be a lot faster from now on... who knows where we would have been now if they had used AtomBIOS from the beginning?

    Comment


    • #3
      Originally posted by d2kx View Post
      I think you meant R500+.
      Nope, for R600+ according to where they are in development and those that I've talked with -- since the R500 3D is quite similar to the R300/400 and is already up and running for R500.

      Originally posted by d2kx View Post
      ...and Radeon HD 3000 series, I assume.
      Nope, RV770 Radeon HD 4800 series 3D.
      Michael Larabel
      https://www.michaellarabel.com/

      Comment


      • #4
        AtomBIOS might be a way to create an artificial market segmentation: AMD/ATI could sell the exact same hardware with two versions of AtomBIOS burnt on each. One version of AtomBIOS would advertise a higher functionality and thus command a higher price. With a FOSS driver that accesses the registers directly you can't hide trickery like that. I seem to remember a thread about some AMD cards only doing TV-out via NTSC while others only via PAL, and someone saying that they only thing stopping them from outputting via both formats is the AtomBIOS selectively advertising which protocols are allowed.

        It might be cheaper for AMD to mass produce the same card than multiple hardware permutations of it, so differentiating them through binary blob BIOS would make economic sense. As far as users are concerned, this sucks 100% because they can't use the hardware to its full extent. Any way you look at it, it's an anti-consumer measure.

        Proponents of AtomBIOS are using the Windows driver and fglrx as examples of existing drivers that already use AtomBIOS. How about Mac OS X -- does it access the registers directly?

        Don't get me wrong, I really appreciate that AMD is opening up their driver (they are light years ahead of NVidious when it comes to being FOSS-friendly), but the best thing would be to let the open-source X.org drivers know how to use the registers directly.
        Last edited by stan; 04 July 2008, 11:55 AM.

        Comment


        • #5
          I have to jump in here. I don't see why this discussion keeps turning into "using AtomBIOS *instead of* getting documentation to use the registers directly". It's not one or the other, it's both.

          I fully expect that over time developers will need to hard-code around AtomBIOS in places, and we are providing documentation to allow that. The documentation is needed anyways in order to understand and troubleshoot what the driver is doing.

          The question is simply what should happen *first*. Using AtomBIOS for the initial implementation means that functionality gets into users hands faster, and that we don't have to write "here's how to write a driver for this chip" documentation just "here's what the blocks and registers do". Remember that we have to *write* all of this documentation -- it's not just a question of pulling it off the bookshelf and dumping it on a web site.
          Test signature

          Comment


          • #6
            Open source atombios?

            Could it perhaps be a possibility that ATI will open up atombios? I think that would be great for all ATI drivers. I think there's no fundamental issue with a partly universal layer, especially since on top all drivers try to deliver a totally universal layer. So if every ATI driver were to use atombios, and atombios would be open source this means everybody can be happy about it, it means developers can propose changes to how atombios works which might benefit ati for it's proprietary driver and in the end I think it will improve the quality of drivers for ati hardware overal.

            I know it's not always possible to open up any piece of proprietary software, but it seems to me atombios should be purely ati's property.

            Also, if the drivers all use atombios and it won't open up, some group can focus on creating an atombios equivalent with the same api, might be useful, might not. Either way I would think of it as a plus if the atombios part is open source too.

            Comment


            • #7
              Actually we did open up the atombios interpreter and header files at the start of the project, so understanding the command and data tables is not a problem. The remaining concern is that the atombios command tables themselves are in bytecode form and have to be disassembled, but since we *write* the command tables directly using bytecodes the disassembly output is identical to the source code in most cases. The only "lost information" is comments... but BIOS developers don't seem to be big on commenting their code in the first place

              If you're interested, you can look in the radeonhd source code at : http://gitweb.freedesktop.org/?p=xor...adeonhd;a=tree

              src/atombios/ contains the source code we provided, and the includes folder contains the atombios.h header which shows how to interpret the command and data tables. It's pretty cryptic but it's what we use in house as well. We started writing more intelligible atombios documentation at the start of the project but back-burnered the work when it became clear that atombios was not being used. We should probably restart that effort.
              Last edited by bridgman; 04 July 2008, 02:19 PM.
              Test signature

              Comment


              • #8
                This should have been obvious ... Use AtomBIOS first to get 2D support quickly and work on the useful part (3D), then go back to do cleaner 2D later on. Six months (almost) wasted. Too bad the Novell folks are far less religious dealing with tainted technologies when it is about Microsoft.

                Comment


                • #9
                  It's water under the bridge now. Probably easiest for everyone if we just focus on all the cool new things we will be doing
                  Test signature

                  Comment


                  • #10
                    How about fixing all compiler warnings in the Atom BIOS code? Also what about supporting older Radeon cards with radeonhd? I can not test that driver with my RV410.

                    Comment

                    Working...
                    X