Announcement

Collapse
No announcement yet.

Full EXA Composite For R300-500 GPUs

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

  • #11
    Radeon vs. RadeonHD: http://www.phoronix.com/vr.php?view=12052
    Michael Larabel
    https://www.michaellarabel.com/

    Comment


    • #12
      Originally posted by an0n1m0us View Post
      This news makes very little sense. I was told in an IRC chat that the Radeon driver was dead, that it was a case of RadeonHD slowly becoming usable and the proprietary driver as the only two options. Also doesn't Alex work for AMD now? Or was that somebody else. If so, why isn't this EXA support going into RadeonHD?
      This may seem confusing, but the key point to remember is that only the display hardware changed significantly between 4xx and 5xx -- for all of the other blocks, including acceleration, the hardware is pretty much unchanged between 4xx and 5xx. In driver terms, this means that only the modesetting part needs to be different and the (larger) acceleration code should be common. Unfortunately the X driver framework is not broken up that way, leaving us two alternatives :

      - separate driver for newer chips, duplicate the acceleration code across the two drivers (radeonhd)
      - one driver with separate modesetting code for older & newer chips, one copy of the acceleration code (radeon)

      All of the acceleration work being performed recently (Textured Video, EXA rotate & blend, 3D) uses the 3D engine, which in turn requires DRI support in the driver. Today the radeon driver has DRI support but radeonhd does not, so in the short term acceleration work is being done using radeon. Adding DRI support and porting across the existing 2D & video acceleration code is top priority for radeonhd, since that will allow acceleration work to be done using radeonhd, not just in radeon.

      As long as we keep the acceleration code common between the two drivers, work done in one driver will be able to immediately benefit the other anyways.
      Last edited by bridgman; 19 March 2008, 08:28 AM.
      Test signature

      Comment


      • #13
        Ah, I had remembered a few quotes from the radeonhd developers along the lines of "we're trying to keep things similar to make sharing code easier" from the forum and from FOSDEM talks. I guess the drivers diverged enough for this to be no longer the case.

        EDIT: Thanks for the clarification of modesetting / acceleration.

        After reading today's article, my big question is which method leads to kernel-level modesetting, ideally, platform independent (non-x86) kernel-level modesetting?

        I'm a tad confused as to what AtomBIOS actually is. When I heard it being discussed before, the idea of parsing and scripts, made me think it was a way to keep the interface high-level, by passing tokens to the GPU, it then turned these into all the necessary register changes internally. Thus it not only kept the driver smaller, but let the CPU focus on other things. If that's what it does, I'm okay with using it so long as docs are released. If AtomBIOS is just a way of putting x86 blobs in firmware, i.e. the tokens are turned in x86 assembly for the CPU, I think the Novell developers are right, and it should be avoided.

        Comment


        • #14
          Originally posted by yoshi314 View Post
          i would not mind having two separate drivers. r5xx and newer have some substantial changes to 2d acceleration, and it seems pretty reasonable to have a separate driver for these cards.
          Not exactly. R5xx has the same 2D core and a very similar 3D core as R3xx and R4xx chips. When we added atombios support to radeon, 2D worked out of the box on R5xx. Also, I originally added EXA Composite support for R3xx/R4xx. Since the 3D engine is so similar it was trivial to add support for R5xx. The only real difference between R5xx and the older chips is the display engine, which with atombios, was easy to support quickly.
          Last edited by agd5f; 19 March 2008, 10:51 AM.

          Comment


          • #15
            Originally posted by Tillin9 View Post
            I'm a tad confused as to what AtomBIOS actually is. When I heard it being discussed before, the idea of parsing and scripts, made me think it was a way to keep the interface high-level, by passing tokens to the GPU, it then turned these into all the necessary register changes internally. Thus it not only kept the driver smaller, but let the CPU focus on other things. If that's what it does, I'm okay with using it so long as docs are released. If AtomBIOS is just a way of putting x86 blobs in firmware, i.e. the tokens are turned in x86 assembly for the CPU, I think the Novell developers are right, and it should be avoided.
            It is literally a set of scripts and data tables stored in the the rom on the card. The scripts are specific to a certain tasks (turning on/off an output, setting the PLL, setting crtc timing, etc.). The atombios script interpreter in the driver decodes the scripts and programs the registers. The scripts basically break down to a list of registers and what values to program them with based on paramters you pass to the script. This allows us to write modesetting code and sort out any HW specific tweaks once (in atom code stored in the rom), then everything else (drivers, bios, etc.) is able to utilize that. Since they are scripts they can even be run even on non-x86 platforms. This allows you to post atom-based cards on powerpc or arm, etc.

            Comment


            • #16
              Originally posted by Tillin9 View Post
              Ah, I had remembered a few quotes from the radeonhd developers along the lines of "we're trying to keep things similar to make sharing code easier" from the forum and from FOSDEM talks. I guess the drivers diverged enough for this to be no longer the case.
              I don't think anything has changed. AFAIK we all still believe that acceleration code can be shared with relatively few changes. The two drivers store information in different data structures but it should be pretty easy to isolate those differences.

              Originally posted by Tillin9 View Post
              After reading today's article, my big question is which method leads to kernel-level modesetting, ideally, platform independent (non-x86) kernel-level modesetting?
              Both methods could work fine for kernel modesetting. I think Dave (the kernel DRM maintainer) is leaning towards AtomBIOS because it allows the modesetting code to be smaller and require fewer changes for new GPUs, but that is more of a preference than a black/white choice.
              Test signature

              Comment


              • #17
                Originally posted by bridgman View Post
                Both methods could work fine for kernel modesetting. I think Dave (the kernel DRM maintainer) is leaning towards AtomBIOS because it allows the modesetting code to be smaller and require fewer changes for new GPUs, but that is more of a preference than a black/white choice.
                I guess it will be atombios. Thinking backing this is that windows driver use that so it has to work, i was told that such things is obvious

                Comment


                • #18
                  Thanks for all the clarification. If AtomBIOS is just a lookup table designed so that drives can be smaller and documentation needs not be at the level of set this register, then set that register, I think its more than okay. Especially if everything is being documented anyway.

                  Just to mention I'm eagerly waiting for kernel modesetting, I have a MIPS box I'd love to equip with an X1550.

                  Comment


                  • #19
                    Originally posted by Tillin9 View Post
                    Thanks for all the clarification. If AtomBIOS is just a lookup table designed so that drives can be smaller and documentation needs not be at the level of set this register, then set that register, I think its more than okay. Especially if everything is being documented anyway.
                    We are providing the register documentation, and, on the radeon driver at least, we print out every operation in each script so you can cross reference the register guide to see exactly what it's doing if you are interested.

                    Comment


                    • #20
                      From testing the new branch on my R480 (X800 GTO^2), it seems that scrolling is significantly faster, but dragging windows (even switching windows) is much slower than XAA.

                      Great work nonetheless.

                      Comment

                      Working...
                      X