Announcement

Collapse
No announcement yet.

Radeon HD 7000 Series Open-Source Still A Mess

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

  • #16
    Originally posted by Gusar View Post
    You mean the U/V swap that causes "blue people"? That was worked around in libvdpau-0.5, shouldn't be an issue anymore.
    That's good to know.

    Comment


    • #17
      FWIW, radeonsi can handle much more than 'some basic 3D demos' now. It runs many real games / apps fine. 3D apps run at full acceleration including page flipping. We're very close to enabling full glamor 2D acceleration as well.

      Obviously it's not nearly as mature as r600g yet, but it's certainly ready for wider testing by early adopters.

      Comment


      • #18
        Originally posted by allquixotic View Post
        Michael you should just advise people to use Ivy Bridge GPU on Linux. ...
        Umm, maybe I missed some tags here. But the nice surprise comes when intel uses some Imagination Technologies HW again and builds in a PowerVR chip labeled as "genuine intel". Nah, I don't trust that stuff from them.
        It is of course a sad thing that the fglrx puts HD4/3/2xxx series already to legacy and that the free stack still is far from being feature complete on the newest GPU arch. I'm quite fine with my HD5xxx (R800/Evergreen) and the free driver stack. But currently there are few things to make the Linux user completely happy on the GPU market. :/

        edit: It's always a good idea to check the feature matrix on GPUs.

        http://www.x.org/wiki/RadeonFeature
        http://nouveau.freedesktop.org/wiki/FeatureMatrix
        http://www.x.org/wiki/IntelGraphicsDriver
        http://www.openchrome.org/trac/wiki/SupportedHardware / http://www.openchrome.org/trac/wiki/TOC
        probably something for matrox exists as well
        Last edited by Adarion; 11-24-2012, 08:37 AM.

        Comment


        • #19
          Originally posted by RussianNeuroMancer View Post
          Enduro supported since Catalyst 12.10.
          So I can use my discrete card to render stuff and display it on the intel card? I googled a bit but I found exactly zero information on how to use it. Do you know more?

          Comment


          • #20
            Originally posted by deanjo View Post
            That's what you get when you basically rebrand old tech though.
            indeed, rebranding is deceiving.
            this time they deceived me into believing, that whole ordeal of building AMD-exclusive PC would be a futile idea :\

            Originally posted by bridgman View Post
            It would have been better if the article had specified "GCN architecture" (HD 77xx through HD 79xx) rather than "HD 7000", since only the top end of the HD 7xxx range uses GCN and that's where the big driver changes were required. Trinity and the rest of the HD 7xxx lineup use VLIW architecture and have generally been supported at launch (or at least when we hear about the new SKU).
            that is reassuring to know. thanks.

            Comment


            • #21
              Originally posted by MrCooper View Post
              FWIW, radeonsi can handle much more than 'some basic 3D demos' now. It runs many real games / apps fine. 3D apps run at full acceleration including page flipping. We're very close to enabling full glamor 2D acceleration as well.

              Obviously it's not nearly as mature as r600g yet, but it's certainly ready for wider testing by early adopters.
              I am interested in the word "we're" in your statement. What exactly is your involvement with the driver?

              Comment


              • #22
                Other than the shader compiler Michel pretty much wrote radeonsi. Everyone helped with testing and debugging the driver but MrCooper (that's just his IRC handle BTW) drew the short straw for initial SI userspace support.
                Last edited by bridgman; 11-24-2012, 08:05 PM.

                Comment


                • #23
                  Nice, Larabel should mark him as a driver developer.

                  Comment


                  • #24
                    Excuse my ignorance, but when something is crap and open source, doesn't the community rush to fix it? I thought that was the very reason many Linux users want software to be open source. Where are all the zealots?

                    Comment


                    • #25
                      Originally posted by FutureSuture View Post
                      Excuse my ignorance, but when something is crap and open source, doesn't the community rush to fix it? I thought that was the very reason many Linux users want software to be open source. Where are all the zealots?
                      No.

                      In order to fix something you have to know can and have the will. Linux would have never been what it is now without companies paying developers. Most of the work on AMD FOSS drivers comes from people on the AMD payroll. And redhat i think.

                      Comment


                      • #26
                        Originally posted by 89c51 View Post
                        No.

                        In order to fix something you have to know can and have the will. Linux would have never been what it is now without companies paying developers. Most of the work on AMD FOSS drivers comes from people on the AMD payroll. And redhat i think.
                        So open source isn't to be held in as high regards as I thought it was, hm? I mean, it is certainly more desirable than closed source software, but considering how companies still hold a vast majority of the power as nothing seemingly gets done without them...

                        Comment


                        • #27
                          Not sure I agree. As long as the code is public and there are developers outside the HW vendor who know the code well enough to work on it, the community *has* the power. The question is if and when it makes sense for them to use it.

                          Graphics drivers get more complex every year as expectations go up for features and performance, and that in turn makes it harder for part-time developers to find enough time to make real progress on the drivers, but the ability to "grab the wheel at any time" is there in principle.

                          Most of the developers working for HW vendors or distros work as "part of the community" anyways, so you do get a largely vendor-independent group making most of the key architectural decisions. The transition to kernel modesetting was a good example, with developers from a half-dozen different companies working together on various bits of the solution, and in many cases the developers *were* independent when they started work on KMS but continued working on it after going to work at Red Hat, AMD, Intel etc...

                          I think you get a more accurate picture of how open source works if you imagine all the work being done by volunteers, then consider that some of the "volunteering" is done by individuals and some is done by (ie funded by) large companies. I can only be sure about AMD but it's probably safe to say that all the large companies expect/allow their developers to work as part of the community and to strike a balance between community priorities and company priorities.
                          Last edited by bridgman; 11-25-2012, 12:11 PM.

                          Comment


                          • #28
                            Originally posted by FutureSuture View Post
                            So open source isn't to be held in as high regards as I thought it was, hm? I mean, it is certainly more desirable than closed source software, but considering how companies still hold a vast majority of the power as nothing seemingly gets done without them...
                            It has nothing to do with how high is regarded or code quality or whatever. The development would just be much much slower. Its different having someone code everyday as his job than someone doing it on his spare time.

                            Comment


                            • #29
                              Originally posted by bridgman View Post
                              Graphics drivers get more complex every year as expectations go up for features and performance, and that in turn makes it harder for volunteer developers to find enough time to make real progress on the drivers, but the ability to "grab the wheel at any time" is there in principle.
                              Maybe it's just me, but I'd say it's really the complexity which keeps people from contributing.
                              The threshold to enter that business seems rather high.
                              There's this promising project to write documentation and guides for new GPU driver developers
                              http://cgit.freedesktop.org/~marcheu/lgd/
                              So far it's a very good read, IMHO, but it's incomplete and progress seems to be slow at best.
                              I'd say this is a *very* important project and a first version is hopefully completed soon (I doubt it).
                              It's not like it will automagically spit out better drivers immediately but it might help to lower
                              the threshold for new contributors, which are new to GPU hardware and the graphics stack.

                              AFAIK there's no comparable literature available yet. Otherwise please point me to it.
                              I'll buy it immediately. And I don't mean books on generic driver development on Linux.
                              Last edited by entropy; 11-25-2012, 12:18 PM.

                              Comment


                              • #30
                                There are conflicting views on the value of documentation though, even among the active developers. If you apply a classic triage model to the pool of potential developers and divide them into...

                                - those who will learn enough by asking questions & reading code to work effectively without documentation
                                - those who wouldn't be able to learn without documentation but would & will become effective developers if given a decent docco starting point
                                - those who would read the documentation but still not be able to deal with the complexity of the hardware & code in the time they have available

                                ... the big debate is over the size of the middle category, the ones who would be helped by documentation. If the work contributed by that middle group is more than the work it takes existing developers to write and maintain documentation, then the community is ahead. If not, then the community loses.

                                The argument against a big push on documentation is that it would mostly help potential part-time developers, and the aggregate work available from the successful ones would be less than the time required to write & maintain the docco because of their part-time nature.

                                IMO the solution is to find the right level of detail. I think everyone agrees that documenting where to find the code and how to build/install it is worth doing, so the question is whether documenting one or two more levels of detail would help and where we reach the point of diminishing returns. I suspect we reach that point quite early, ie that the optimal point would be maybe 5-10 pages *total* of well-written design docco divided across the major component projects (eg a page or two for stack-level plus a page or two for each major component) and kept ruthlessly up to date.

                                That would be enough to let potential developers get a lot further into the code quickly, and hopefully enough that they can start tinkering and asking good questions (where "good" in this case means "other developers feel that answering the questions is a good use of their time").

                                One of the obvious challenges would be how to avoid the documentation growing past the point where it can be maintained, since documents (and code) tend to grow during periods of enthusiasm then rot when the enthusiasm wanes.

                                It would be nice if code and docco automatically got smaller when fewer people were available to work on them but nobody knows how to do that yet AFAIK
                                Last edited by bridgman; 11-25-2012, 12:42 PM.

                                Comment

                                Working...
                                X