Announcement

Collapse
No announcement yet.

RadeonHD Driver To Use AtomBIOS

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

  • #31
    So kernel modesetting is on the way? Cool...

    Any estimate on when we'll be seeing it in the a release? It's one feature I'd love to get my hands on.

    Comment


    • #32
      keep an eye on airlied's blog, I guess...

      http://airlied.livejournal.com

      Comment


      • #33
        so, what you're telling me is that we're going to have two versions of the xf86-video-ati driver?

        I can appreciate using the AtomBIOS for initial support. At the same time, I'm with the radeonhd developers in that I would much prefer the driver go straight to the registers. And it just so happens that "ati" uses the former while "radeonhd" does the latter. So it seems the two drivers have unique puproses - one to let people use new cards NOW without fglrx, and one down the road which is "more ideal". I kinda like it that way, even if I don't have money to blow on new video cards every couple months.

        Comment


        • #34
          Originally posted by jeffro-tull View Post
          so, what you're telling me is that we're going to have two versions of the xf86-video-ati driver?

          I can appreciate using the AtomBIOS for initial support. At the same time, I'm with the radeonhd developers in that I would much prefer the driver go straight to the registers. And it just so happens that "ati" uses the former while "radeonhd" does the latter. So it seems the two drivers have unique puproses - one to let people use new cards NOW without fglrx, and one down the road which is "more ideal". I kinda like it that way, even if I don't have money to blow on new video cards every couple months.
          Not sure I understand about "two versions of the -ati driver". I expect that once kernel modesetting is available all drivers will have the option to use it rather than using the modesetting code built into the X driver. Once the modesetting drm is in common use I expect modesetting in the X driver will pretty much go away and the X server will finally be able to run as regular user code. I expect the modesetting code in the X driver will stay in the source tree for a while, for cases where a drm is not available, although there are relatively few OSes which don't support a drm today.

          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.
          Last edited by bridgman; 07-06-2008, 01:21 AM.

          Comment


          • #35
            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.

            After all.. That's the reason people buy these cards, isn't it? It's not like anybody really cares that some 2D optimization allows Firefox to render a page imperceptibly faster. If that is all that mattered then everybody would be using Intel cards and not give a crap.

            But for some things I want to do having good 3D support is very important.

            Comment


            • #36
              Originally posted by bridgman View Post
              Not sure I understand about "two versions of the -ati driver". I expect that once kernel modesetting is available all drivers will have the option to use it rather than using the modesetting code built into the X driver. Once the modesetting drm is in common use I expect modesetting in the X driver will pretty much go away and the X server will finally be able to run as regular user code. I expect the modesetting code in the X driver will stay in the source tree for a while, for cases where a drm is not available, although there are relatively few OSes which don't support a drm today.

              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.
              yeah, I was in a hurry, on my way away from the computer and posted before I read anywhere near as much as I should have. you can just ignore my previous post.


              After reading all the posts in this thread, I understand but still have some concerns. AtomBIOS doesn't seem to do that much, in the grand scheme of things (initialization and modesetting are certainly non-trivial, but other stuff I've read made it seem much more prominent in driver writing). Now I'm thinking "AtomBIOS? What's the big deal? Use it, dammit!"

              At the same time, I'm concerned, like others, as to why there will be two drivers. It's like they're using the same means to the same end. Aside from legacy support in one, what will be the difference between the two? Looks like some developers need to kiss and make up.

              Comment


              • #37
                Originally posted by stan View Post
                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.
                The NTSC versus PAL thing is indeed limits imposed in the specific atombios implementation for the specific card.

                Originally posted by stan View Post
                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?
                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.

                Originally posted by stan View Post
                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.
                The free hardware documents are indeed the winner here. But sadly we're straying more and more from our initial proposal to AMD in this respect.

                Comment


                • #38
                  Originally posted by mycroes View Post
                  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.
                  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.

                  Comment


                  • #39
                    Originally posted by remm View Post
                    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.
                    There are several aspects to an answer here.

                    First of all, in a project like this, you have two sorts of people, those who do the talking, and those who do the coding. Where the coders usually get bogged down is one of many possible issues: Being stalled on hardware or documentation, or waiting for answers to technical, undocumented questions. Human factors, like Matthias breaking a bone in his right hand. Or being bogged down to the talkers mode.

                    Mostly though, those 6 months you use there were not wasted while waiting for code to be written, they were wasted everywhere else.

                    Then, you state that you want to see work done one the "useful part" right away. Do you realise that this means brushing all problem under mat, and leaving a lot of users in the cold, who can never see this useful part as their hardware doesn't come up properly in the first place? And when you say that the modesetting bit will be solved afterwards, you are mistaken. Such a thing only happened once, where the pressure of the free software community was horribly high, and where some smart people in intel hired a lot of developers who were forced to work on modesetting. In all the other situations, there never was time spent on going back and doing some things Right.

                    Comment


                    • #40
                      Originally posted by val-gaav View Post
                      the good question right now is...

                      Since the differences between radeonhd and radeon drivers start to disappear, shouldn't the both drivers just merge or agree that radeon is for chips up to r400 and radeonhd for r500+ ?
                      This was the original intention, sadly some people saw this differently and then wasted a lot of resources.

                      Comment


                      • #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; 07-06-2008, 03:06 PM.

                              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

                                Working...
                                X