Announcement

Collapse
No announcement yet.

There are many more readers than members

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

  • #81
    Originally posted by bridgman View Post
    Not sure I agree there. You are describing systems to let large numbers of developers collaborate efficiently on large projects without getting in each others way. Graphics driver development is more like the opposite situation - 20 or 30 projects that need to be done, each with a fraction of a developer at best
    True, but these systems also scale down gracefully as well.

    Here's my description of Launchpad on my website (which applies to the other systems as well):

    infinityOS has a project at Launchpad, a website that integrates bug fixing, feature planning, commiting code, and answering questions into a simple easy to use UI. All you need to do to participate in infinityOS' development is sign up for an account.
    In order to get developers working on your project, you have to make it that easy to commit code and document it. A system such as Launchpad and the others would allow you set one up in a matter of an hour. Hell most of them allow you to import Git code, with all the branching and commenting attached.

    Comment


    • #82
      Let me ask around. My sense is that the challenge of understanding the code, hardware and problem domain is an order of magnitude more significant than the challenge of dealing with basic git and bugzilla functions, although I'll be the first to admit that initial use of git involves more "chanting of carefully memorized incantations" than working intuitively.

      Some of the problems that a system like Launchpad solves, however, are mostly problems of scale, so to a large extent different sized projects need to focus on different problems. Right now the open source driver community's biggest challenge IMO is the relative hostility of the technical environment - complex, performance-critical code shared across a variety of different GPU architectures,where a significant percentage of the common errors result in the same symptom - a locked-up GPU.

      I'm actually wondering if a GPU simulator might be the biggest single contributor to lowering the entry threshold for driver development.

      Comment


      • #83
        Originally posted by bridgman View Post
        Some of the problems that a system like Launchpad solves, however, are mostly problems of scale, so to a large extent different sized projects need to focus on different problems. Right now the open source driver community's biggest challenge IMO is the relative hostility of the technical environment - complex, performance-critical code shared across a variety of different GPU architectures,where a significant percentage of the common errors result in the same symptom - a locked-up GPU.

        I'm actually wondering if a GPU simulator might be the biggest single contributor to lowering the entry threshold for driver development.
        Clarity and transparency are always your best friend.

        I'm going to quote the Cathedral and the Bazaar, which is the open source development bible:

        "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone." or "Given enough eyeballs, all bugs are shallow."

        Even if people won't be directly contributing code, such a system would enable testers to more easily find bugs and allow you to fix them. You won't have the problem that was mentioned in the first post of this thread, where someone has found a bug, but didn't want to learn the system to file it.

        In order to fix bugs, your testers have to be able to report them so you know about them. You want as few technical barriers as possible between your testers and your bug tracking system.

        ----------

        As an aside, I recommend you read over the Cathedral and the Bazaar (if you haven't already). It is free online and pretty short (20ish pages).

        Implementing each "law" it contains will streamline your project and make development much faster and easier.

        http://www.catb.org/~esr/writings/ca...hedral-bazaar/

        Comment


        • #84
          Just to make it easier for you, as I'm sure you're short on time, here's a law of the laws in the Cathedral and the Bazaar (though some of them admittingly do not apply to this project):
          1. Every good work of software starts by scratching a developer's personal itch.
          2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
          3. Plan to throw one away; you will, anyhow.
          4. If you have the right attitude, interesting problems will find you.
            [*[When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
          5. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
          6. Release early. Release often. And listen to your customers.
          7. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
            [*[Smart data structures and dumb code works a lot better than the other way around.
          8. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
          9. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
          10. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
          11. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.
          12. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
          13. When writing gateway software of any kind, take pains to disturb the data stream as little as possible?and never throw away information unless the recipient forces you to!
          14. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
          15. A security system is only as secure as its secret. Beware of pseudo-secrets.
          16. [b}To solve an interesting problem, start by finding a problem that is interesting to you.
            Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.[/b]


          I've bolded some of the laws for good measure.

          Comment


          • #85
            Gah. I REALLY hate the edit limit on this forum.

            Comment


            • #86
              I have to disagree. Frankly most Ubuntu users don't have the slightest idea how to file good bug reports, and I'm saying this as an Ubuntu user myself. There is only a handful of developers. The last thing you want is them wasting time holding hands of clueless users. Those who do have a clue will find their way to the freedesktop bugzilla, the git repos and the mailing lists themselves.

              Comment


              • #87
                Originally posted by monraaf View Post
                I have to disagree. Frankly most Ubuntu users don't have the slightest idea how to file good bug reports, and I'm saying this as an Ubuntu user myself. There is only a handful of developers. The last thing you want is them wasting time holding hands of clueless users. Those who do have a clue will find their way to the freedesktop bugzilla, the git repos and the mailing lists themselves.
                Eh. It takes 10 sec to mark a bug as "Won't fix" and make it disappear from your bug list.

                Comment


                • #88
                  Originally posted by bridgman View Post
                  I'm actually wondering if a GPU simulator might be the biggest single contributor to lowering the entry threshold for driver development.
                  Is that something that AMD could realistically contemplate releasing, or would it need to be an outside effort? If the latter, do you think that the released docs are good enough to at least get a good start on it?

                  Comment


                  • #89
                    I believe there is enough documentation and support available to write one as an outside effort (heck, I would work on that one), but my first step would be to see if there was something internal we could release to at least kickstart the effort.

                    We can't release the simulators we use for pre-silicon development because those rely on the actual GPU logic design files (and you can understand how we might be a bit touchy about publishing those), but I think there was some work on a functional simulator written against the programming model rather than the logic design. One more thing to add to my to-do list ;(

                    Comment


                    • #90
                      Originally posted by darkphoenix22 View Post
                      Eh. It takes 10 sec to mark a bug as "Won't fix" and make it disappear from your bug list.
                      You can't really "won't fix" low quality bug reports. That sends the wrong message - that there *is* a bug but for some reason users are stuck with it. Again, the challenge here is the domain complexity - a problem in one driver might manifest itself as a problem in a different driver as a result of compositing, for example - and the high learning curve before someone can even file good bug reports.

                      Seriously, we need more developers and really knowledgeable testers who can sort through user issues and distill them to something the devs can sink their teeth into, not a fatter pipe from end users to the few devs we have today.

                      Comment

                      Working...
                      X