Announcement

Collapse
No announcement yet.

AMD Releases OpenCL ATI GPU Support For Linux

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

  • #41
    Originally posted by bridgman View Post
    Well, there's the first mistake (not yours)

    There are no deadlines. We make rough estimates for how long a small group of developers, all working on multiple projects, will take to do something they've never done before. We try to update the estimates as new information comes in, but if anyone thinks of that as a deadline the discussion is out of control already.
    A poor choice of words on my part there. What I was referring to was when Michael writes a post about how some feature is going to be done next week, or later this month, and then nothing visible to users happens on that front for another 6 months. People get frustrated because they were expecting something to be done even if it actually wasn't anywhere close, so I know the usual tendency is to try to be as vague as possible about when things are going to be done.

    I know it's tough to give good estimates the first time you do something, especially when it involves a whole framework as large as Gallium that may not be working 100% since you are one of the first to try to get it all working.

    Comment


    • #42
      Originally posted by smitty3268 View Post
      I know it's tough to give good estimates the first time you do something, especially when it involves a whole framework as large as Gallium that may not be working 100% since you are one of the first to try to get it all working.
      When you hear an estimate on software, a good bet is to double it and then increase it by an order of magnitude. In other words, when you hear "it will be ready by tomorrow", you should translate that to "it should be ready in two weeks from now".

      As an added bonus, sometimes you'll be pleasantly surprised ("hey cool, it only took one week after all!")

      Comment


      • #43
        Ah yes, the good old "times two and add thirty" rule

        When I joined ATI I made myself unpopular in a variety of ways. One of them was asking "what level of confidence do you want ?" when someone asked me for a schedule. If you look at the typical distribution of completion times for a given project, as you increase time the probability of completing at that time goes up quickly to a "most likely" value then trails off slowly with a long tail, ie where the time to complete may be 5x, 10x or higher than the most likely time.



        If you measure the area under the curve you can calculate the probability of the project finishing on or before a certain time. The 50% point (half the time early, half the time late) is normally close to, but not the same as the most likely time to complete.

        Each project has :

        - a lower bound (essentially no chance of finishing before this time)
        - a "most likely" schedule
        - a 50% confidence or "50/50" schedule, ie half the time you'll finish before, half the time you'll finish after
        - various "high confidence" points, typically 80% and 90% confidence are used
        - maximum time is usually unbounded... projects are sometimes just doomed and can suck up resources forever

        The exact shape of the curve, and therefore the relationship between the different points, is a complex function of risks, task sensitivity to those risks, and task interdependence. I'm not including even scarier things like changes to requirements or priorities during the project.

        This is where it gets complicated, of course. The "high confidence" schedules are quite far down the tail of the curve, and are much longer than the most likely or 50/50 times.

        One of the great joys of project management is that when you are managing a portfolio of projects with shared resources you need to use the 50/50 point for each task so that over time your resource usage matches the estimate, but you don't want to make commitments based on the 50/50 point because that means you'll be late half the time. You end up having to keep two schedules - one that you use for internal management and one that you use to make commitments, and the two numbers are usually pretty far apart. Eliyahu Goldratt's Critical Chain describes how to integrate the two schedules in a manageable way.

        Where am I going with all this ?

        1. When an individual developer talks about how long an individual task might take, they are usually either talking about the minimum (ie "it will take at least this long") or the "most likely" time. This is what you would normally call a SWAG.

        2. When we talk about project schedules (a project being a collection of tasks) within a larger rearchitecture initiative we are normally talking about the 50/50 point, which is optimum for allocating resources and figuring out how much work should be bitten off at a time. This is what you would normally call "a plan".

        3. When something "really needs to be done by a certain time" you need to plan with 80% or 90% confidence, which either means significantly longer schedules or significantly fewer features. This is what you would normally call "a deadline".

        So... one more time... how long is Gallium3D gonna take ?
        Last edited by bridgman; 10-16-2009, 07:13 PM.

        Comment


        • #44
          My guess is it'll be announced as "coming next week" by Phoronix perpetually, then eventually get a stable release in April-May.

          Comment


          • #45
            Well have anyone got the opencl baby to run?

            I just downloaded the beta driver from ati's stream site and the stream sdk.

            I got this system:
            ubuntu 9.10
            radeon 4650

            The driver runs, but I got a "Testing use only, Unsupported hardware", bottom right off my screen. 2d, 3d and so works fine, but when I try run a demo sample from the SDK, I get a segmentation fault.

            Code:
            (gdb) run
            Starting program: ~/ati-stream-sdk-v2.0-beta4-lnx64/samples/opencl/bin/x86_64/HelloCL 
            [Thread debugging using libthread_db enabled]
            HelloCL!
            Creating a context
            For test only: Expires on Sun Feb 28 00:00:00 2010
            
            Program received signal SIGSEGV, Segmentation fault.
            0x00007ffff4b946ea in ?? () from /usr/lib/libaticaldd.so
            Anyone got any ideas?
            Last edited by tball; 11-14-2009, 08:15 AM.

            Comment


            • #46
              Probably best to post on the Stream forum at developer.amd.com; that's where the Stream folks hang out. Don't think there has been much testing on Ubuntu 9.10 but that wouldn't explain the Unsupported Hardware icon; first thought is some kind of installation issue with the driver.

              Comment


              • #47
                There are 2 watermarks possible, one is unsupported hardware, that means you have to replace the /etc/control file and the other is a check for /etc/signature which is missing on beta drivers. You can take both files from any other driver.

                Comment


                • #48
                  Good point, I forgot that beta drivers displayed the watermark. Thanks.

                  Comment


                  • #49
                    But That wont solve my segmentation fault I guess. I don't care about the watermark actually. I just want the opencl driver to work.

                    Comment


                    • #50
                      Yeah, the watermark was a red herring. I don't suppose you have a free partition to try it with Ubuntu 9.04, do you ?

                      The SDK is a beta, tested on 9.04, and I would be surprised if it were trouble free on 9.10.

                      Comment

                      Working...
                      X