Announcement

Collapse
No announcement yet.

RadeonHD Driver To Use AtomBIOS

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

  • #41
    Originally posted by bridgman View Post
    No plans to skip the 6xx family. I have one in my home PC, there's no damn way we're skipping it
    What driver are you using?

    Comment


    • #42
      Originally posted by bridgman View Post
      What do you see as the benefit of direct register programming in a general sense ? The cost to develop and support the code is perhaps 5x as high and there seem to be relatively few cases where it is needed.
      This figure is greatly exagerated, especially since radeon, when it came around, took a lot of the hard work straight from radeonhd.

      The difference between both drivers is this; the intention to provide for everyone, or the intention to provide only for 80% of the users. The former means that one gets bogged down figuring out what's wrong, the latter means people running straight back to fglrx (which, given ATIs recent push there, might not be entirely undesired).

      Comment


      • #43
        Originally posted by drag View Post
        The way I see it.. I don't see any point on not using the Vbios if it's open source and all that. Sure it's written in byte-code and not C, but so what? This vbios stuff isn't dependent on a particular architecture, is it?

        Anyways any resources being spent on producing 3D drivers is time well spent. If the vbios solves problems and allows people to concentrate on getting good 3D support then thats a terrific thing.
        BIOS is software treated like a black box, both by the developers of the bios and the people using this black box. It is hardly ever perfect, and especially in this case, hard to fix.

        What problems do you want to see fixed in your case? In a perfect world, your display lights up correctly, and everything is well... But the world is never perfect, and you'll swear to nvidia all of a sudden if you happen to be unlucky.

        Comment


        • #44
          Originally posted by libv View Post
          This was the original intention, sadly some people saw this differently and then wasted a lot of resources.
          In fairness, the complete "original intention" was that radeonhd would initially be built on AtomBIOS and would replace radeon beginning with R5xx.

          I know there were other proposals but our plan was always to use atombios. That said, I think we were all a bit surprised by how much of the existing radeon acceleration infrastructure "just worked" on 5xx, so if we were doing the project again splitting between 5xx and 6xx might have been the better choice. Hard to say.

          You nailed the big question in one of your earlier posts -- whether our first priority is getting full functionality for *most* users or basic functionality for *all* users, where "all" includes platforms such as Mac systems running without BootCamp, non-x86 CPUs and OSes which do not yet have DRM support. We see "full functionality for most users" as our first priority, although I suspect that "most" in this case is closer to 95% than 80%.

          Originally posted by libv View Post
          What driver are you using?
          Right now I'm using the VESA driver , at least until (a) I get a reliable modem connection when running Linux, and (b) I figure out why the PC is locking up occasionally even with the VESA driver or with "that other OS".

          Originally posted by libv View Post
          ATI has always been squarely against being able to replace your graphics card bios. Even when specific BIOS versions might have noticeable bugs, you will still not be allowed to work around them by just flashing in a new BIOS.
          Yes and no. We are still generally against re-flashing the ROM because of the warranty and support problems that come along with it, but I believe we leave the final decision to our board partners. I think there was a fan controller profile issue with some early 3870 boards which was addressed with a BIOS reflash. As a safe alternative to flashing, we put a mechanism into the atombios framework which allows tables to be replaced on the fly by the driver.

          Originally posted by libv View Post
          We have repetively asked ATI to provide us with information about the apple versions of radeonhd hardware, as most of the long standing bugs are related to apple. We have yet to receive any relevant information.
          I agree you have not received all the information you need, although obviously we need to get that information from Apple since it's their hardware design and they provide a portion of the driver stack.
          Last edited by bridgman; 06 July 2008, 03:06 PM.
          Test signature

          Comment


          • #45
            I was wondering, when it have been decided to stay with TTM or move to Intel's GEM.

            Does that change anything in regards to the ati and radeonhd drivers?

            Comment


            • #46
              Originally posted by Louise View Post
              I was wondering, when it have been decided to stay with TTM or move to Intel's GEM. Does that change anything in regards to the ati and radeonhd drivers?
              The memory management code is all in the kernel (the drm component) so most of the work is outside the ati and radeonhd drivers. Once memory management is up and running, however, both drivers will need to be modified to use the drm's memory manager rather than performing those functions itself.

              Kernel modesetting is easier by comparison, since the driver can choose whether or not it wants to use KMS, but AFAIK memory management will require more coordination across the components.

              As far as TTM vs GEM goes, the general consensus seems to be to use the GEM calls for "core" functions, since non-driver components such as DRI2 need to use the memory manager and therefore require commonality across drivers, and to allow the rest of the API calls to be driver-specific. There seem to be some areas where TTM is preferable, at least for discrete graphics, and it sounds like the final solution is likely to be a mix of GEM and TTM concepts.

              The TTM/GEM discussion may have delayed development of memory manager and kernel modesetting by a month or two but it was probably all for the best, since the devs generally seem to feel that some of the ideas in GEM help to address some long-standing problems.
              Last edited by bridgman; 06 July 2008, 01:41 PM.
              Test signature

              Comment


              • #47
                Originally posted by bridgman View Post
                The memory management code is all in the kernel (the drm component) so most of the work is outside the ati and radeonhd drivers. Once memory management is up and running, however, both drivers will need to be modified to use the drm's memory manager rather than performing those functions itself.

                Kernel modesetting is easier by comparison, since the driver can choose whether or not it wants to use KMS, but AFAIK memory management will require more coordination across the components.
                Hmm not really, the plan to stop the X server running as root, means you have to use kernel based modesetting with a DRM exposed acceleration architecture. This is part of securing X properly not with duct tape and bonghits.

                There will be one kernel memory manager for radeon and one modesetting implementation, Userspace drivers are for accel only via submission of command buffers to the DRM.

                Dave.

                Comment

                Working...
                X