Announcement

Collapse
No announcement yet.

R800 3D mesa driver is shortly before release

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

  • #91
    The reason functional programming (languages like lisp are very close to a pure encoding of lambda calculus) is amenable to parallelism is that their constructs are by definition idempotent - all of their data comes as parameters and is not affected by, and does not affect anything outside.

    ..there's nothing stopping you using style that emphasizes purely idempotent functions in C/C++.

    Of course, you can't code everything up to have no effect on the environment. You want the code to display something so you can see the result. You want to take input for hardware devices and so on, and you still need to arbitrate access to these, and then suddenly you're back in the world of mutexes and limited scalability.

    Comment


    • #92
      Originally posted by DuSTman View Post
      The reason functional programming (languages like lisp are very close to a pure encoding of lambda calculus) is amenable to parallelism is that their constructs are by definition idempotent - all of their data comes as parameters and is not affected by, and does not affect anything outside.

      ..there's nothing stopping you using style that emphasizes purely idempotent functions in C/C++.

      Of course, you can't code everything up to have no effect on the environment. You want the code to display something so you can see the result. You want to take input for hardware devices and so on, and you still need to arbitrate access to these, and then suddenly you're back in the world of mutexes and limited scalability.
      right thank you for clearing this
      Most people do not know that the Lambda is amenable to parallelism because its idempotent.

      The limited scalability does not mean you only can use 1 single core.
      this means different cores are for different programs and differed tasks.

      you can use 1000 of cores before you are hit by any limit ;-)

      Comment


      • #93
        Originally posted by DuSTman View Post
        The reason functional programming (languages like lisp are very close to a pure encoding of lambda calculus) is amenable to parallelism is that their constructs are by definition idempotent - all of their data comes as parameters and is not affected by, and does not affect anything outside.
        That helps, but of course you can still write inherently sequential code in such a system.

        Consider for instance a processor emulator:
        emulate(state, cycles_left) = emulate(emulate_instruction(state), cycles_left - 1)
        emulate(state, 0) = state

        In general, all known ways of implementing this have time proportional to cycles_left: it cannot be made sublinear even if you have a number of processors which is polynomial in cycles_left.

        [Note: state must be assumed theoretically to be not limited in size, or in practice not be tiny, otherwise you can solve this in logarithmic time]

        Comment


        • #94
          Originally posted by Agdr View Post
          That helps, but of course you can still write inherently sequential code in such a system.

          Consider for instance a processor emulator:
          emulate(state, cycles_left) = emulate(emulate_instruction(state), cycles_left - 1)
          emulate(state, 0) = state

          In general, all known ways of implementing this have time proportional to cycles_left: it cannot be made sublinear even if you have a number of processors which is polynomial in cycles_left.

          [Note: state must be assumed theoretically to be not limited in size, or in practice not be tiny, otherwise you can solve this in logarithmic time]
          i think this only works if you use "typed lambda calculus"

          thats because the orginal one does not alow you to chance a data typ in the calculation so there is no need to wait for an result because all date need to be there from the start on.

          not all "Functional programming" languages are typed

          and in the orginal 1930 theorie of lambda calculus you can't do this.

          Comment


          • #95
            Originally posted by Qaridarium View Post
            i think this only works if you use "typed lambda calculus"
            This has nothing to do with typed vs. untyped lambda calculus. If you want to write a type signature for emulate, it would be State⊗Integer → State⊗Integer. In general, typed lambda calculus is less expressive than untyped lambda calculus, since the latter can obviously express any well-typed expression. In this case, the typedness of the lambda calculus you're using has nothing to do with this.

            Originally posted by Qaridarium View Post
            thats because the orginal one does not alow you to chance a data typ in the calculation so there is no need to wait for an result because all date need to be there from the start on.
            No values are changing at all. He's expressing an algorithm by recursion. At cycle zero, the machine is in a known initial state. To this we apply the emulation operation which maps the old state to a new state and increments the number of cycles. If you wanted to expand this out, you'd have:
            emulate(emulate(emulate(...emulate(initial_state, 0))...)))
            alternatively, in a language like C, you'd have:

            cycle_count = 0;
            state = initial_state;
            while(1) state = emulate(state, &cycle_count)); // emulate increments cycle_count
            These are completely equivalent computations. In both cases, there's a serial data dependency: you can't compute the next state until you know the current state. Expressing this in lambda calculus or a purely functional style does not in any way remove this fundamental computational property. It would be like claiming that Fermat's last theorem is true in a base-12 number system but not in base-10: it's a mathematical property that's completely independent of a particular representation.

            If you claim to have a faster-than-serial way to solve this emulation problem, congratulations, you've solved the halting problem and disproved one of the most fundamental theorems in computer science.

            Quad, I respect you for your ability to find interesting info. I'm not sure if you're trolling or just confused, but you need to give this up.

            Comment


            • #96
              Originally posted by trapxvi View Post
              Quad, I respect you for your ability to find interesting info. I'm not sure if you're trolling or just confused, but you need to give this up.
              yes i think i'm just confused and the true is i do not know anything about programming Technics and computer theory's..
              i'm just best friend with Google and Wikipedia

              but yes i try my best ;-)

              and yes i should give this up but this isn't my 'nature'


              Originally posted by trapxvi View Post
              If you claim to have a faster-than-serial way to solve this emulation problem, congratulations, you've solved the halting problem and disproved one of the most fundamental theorems in computer science.
              i think the problem in this situation is the 1xdimensional Binary 1/0 system.

              but if you build an 16-dimensional Sedenion Jordan triple computer system you get a high chance to have the result in one of the Dimensions on the first cycle ;-)

              just a joke *happy*

              Comment


              • #97
                Originally posted by trapxvi View Post
                If you claim to have a faster-than-serial way to solve this emulation problem, congratulations, you've solved the halting problem and disproved one of the most fundamental theorems in computer science.
                This does not seem to be correct.
                How would you use such an algorithm to solve the halting problem?

                It seems to me it would instead prove P = NC, which would be very surprising but not proven false (kind of like P = NP).

                Such an algorithm running on a single machine however is provably impossible (e.g. you could emulate computing the sum of an array in sublinear time, which is obviously impossible).

                Comment


                • #98
                  Originally posted by Agdr View Post
                  This does not seem to be correct.
                  How would you use such an algorithm to solve the halting problem?
                  Admittedly I was being a little sloppy with that statement. My thinking was that the program and its input can be described in the state, and a halted state corresponds to a fixed point of the emulate function. If he could somehow do away with the execution of serial emulation steps, it would require him to know in advance if the intial state eventually halts or not (if you require the emulation itself to stop when the fixed point/halted state is reached).

                  Define a halting emulation step by stopping recursion when a fixed point is reached:
                  Code:
                  emulate' x = let y = emulate x in if y == x then x else emulate' y
                  Now if we assume his compiler can parallelize the call "emulate' init" it seems to me that it would have to solve the halting problem since otherwise there's no knowing how many invocations of emulate it's actually replacing. I made the tacit assumption that the compiler would need to know that in order to distribute the work between synchronization points.

                  Of course, the serial data dependency makes it impossible to parallelize. Arguing about how that parallelization would have to be done is like fighting over the color of an invisible object.

                  Comment


                  • #99
                    Originally posted by trapxvi View Post
                    If he could somehow do away with the execution of serial emulation steps, it would require him to know in advance if the intial state eventually halts or not (if you require the emulation itself to stop when the fixed point/halted state is reached).
                    This is not obvious.
                    The problem is "just" trying to calculate faster a fixed number of iterations, and whether emulation reaches a fixed point or not seems immaterial for that.

                    Anyway, this is a known unsolved problem, so it's unlikely anyone knows the solution beyond the widely held conjecture that it's impossible (see http://en.wikipedia.org/wiki/NC_%28complexity%29 and http://en.wikipedia.org/wiki/P-Complete).

                    Comment


                    • As a proud owner of the most expensive ATI desktop video card in existence, the HD5970, I can say this: I appreciate ATI's commitment to open source, and I appreciate their commitment to high performance 3d graphics. But I want to see your executives in the next board meeting dutifully jotting down on their notepads that they need to work on reducing the publicly-visible open source driver development time (the time between official product launch date and open source driver availability). This issue needs high level attention. ATI's leaders need to know that this is a major concern for a lot of people. Management needs to push this through.

                      We can't get faster development times by having workers work faster. That won't happen. They already type 100+ wpm, like most hackers, and can read technical docs even faster. The people who understand the process the best -- the ATI middle and upper managers -- should be the ones figuring out how to minimize the wait time between official launch date and availability of the 2d/3d driver for the new chipset, without fundamentally compromising some other important objective.

                      There's ample proof that managers can do this. First, look at all the proprietary drivers, for Windows, Mac, and Linux; Nvidia, Ati, and Intel. As soon as the product is available in stores, the drivers are there. They may not be bug-free, but they are quite mature on launch day, and all the important features are there -- including full support for the OpenGL and DirectX revisions that the hardware is capable of supporting.

                      Second, look at the open source Intel drivers. Intel commits code to the public freedesktop.org git before their product hits the shelves. Their priorities are clear: no sooner than a motherboard with the latest Intel IGP is available, basic KMS/2d (and lately, basic 3d) are implemented in the latest open source bits. Intel's open source drivers stay as ahead of the game as the proprietary drivers of other companies, give or take a few OpenGL extensions. This wasn't the case when I first got my Intel 945GM based laptop, but the time to deliver has dropped to 0 - 4 weeks since then. Even Phoronix has been aware of this; remember all the "igdng" (intel graphics device next generation) articles?

                      The only reason I say that ATI management is necessary, is because I don't have a proper insight into how ATI runs things internally, to make constructive suggestions myself. Clearly, something is holding up the process. Maybe they can't start work on the driver until after the chip is out to market? Maybe they stay busy on the last generation's drivers until months after the new chip is out? Maybe they don't have enough manpower to get things done in a timely fashion? Maybe they spend 95% of their time waiting for legal to clear their code? Maybe they aren't given the same documentation the proprietary teams have, forcing them to re-discover their company's own hardware? Or more likely (thanks Murphy!) all of the above are true.

                      The reality of the situation is probably more complex than I realize, which is why I think management should get involved. Management in corporations is designed to (1) become aware of goals that the company needs to accomplish, (2) gather information on how that goal can be accomplished best, (3) prioritize that goal alongside others, and then (4) direct people to accomplish those goals. My feeling is that "delivering open source drivers for new chipsets in a timely manner" is not a priority at all for ATI, because if it were on their priority list at all, the drivers would be significantly more punctual than they are -- even if the priority were just "low'.

                      Of course, maybe they're aware of it, but they just consider it such a non-priority that everything else takes precedence. Still, what about process improvement? Any chance of setting a goal of reducing the time to release of the r900 OSS drivers, compared to the r800 ones? And then improve on that for r1000, and improve further for r1100...

                      And then someday I can tell my kids that, once upon a time, when I was growing up, open source graphics drivers sometimes weren't available for months after the product was released......

                      Comment


                      • I think that the major problem is that ATi had a LOT of catching up to do, as they had not only one, but several generations out there for which there was almost no open-source support.

                        I'm pretty sure that timely support is what they are planning for future chips. It didn't work out for Evergreen, since they started writing the OSS drivers 3 years too late -- something that the current developers are not responsible for.

                        Comment


                        • Originally posted by allquixotic View Post
                          As a proud owner of the most expensive ATI desktop video card in existence, the HD5970, I can say this: I appreciate ATI's commitment to open source, and I appreciate their commitment to high performance 3d graphics. But I want to see your executives in the next board meeting dutifully jotting down on their notepads that they need to work on reducing the publicly-visible open source driver development time (the time between official product launch date and open source driver availability). This issue needs high level attention. ATI's leaders need to know that this is a major concern for a lot of people. Management needs to push this through...
                          Already happening, and has been happening for a while. It was part of the original plan we presented to the execs back in 2007.

                          If you look at the timelines for the last few generations (HW launch to 3D support at the level of previous generations) you get something like :

                          5xx - mid-2005 launch, late 2008 support => 3-1/2 yrs

                          6xx - mid 2007 launch, mid-late 2009 support => 2-1/2 yrs

                          7xx - mid 2008 launch, mid-late 2009 support => 1-1/2 yrs

                          EG - late 2009 launch, RSN support => less than 1 yr

                          Fusion - being planned now

                          next gen discrete - being planned now

                          In the meantime the driver also picked up all kinds of nice additions like EXA & textured video accel, GL 2 support including flow control, kernel modesetting, etc...

                          Comment


                          • I can't edit, but after verifying some dates the timeline is probably closer to :

                            5xx - 3 yrs

                            6xx - 2 yrs

                            7xx - 1 yr

                            EG - <1yr

                            Comment


                            • One thing that may not be obvious is that Alex and Richard worked on adding core driver features (finishing the transition to KMS, adding GL 2 support and flow control etc..) in the fall of 2009 rather than starting immediately on Evergreen support.

                              I still believe that was the right thing to do but there are obviously good arguments both ways, particularly if you own an Evergreen GPU.

                              Comment


                              • Originally posted by bridgman View Post
                                EG - <1yr
                                Is that a promise? That leaves about a month and a half left to release it.

                                Do you have any idea about how long we'll have to wait for Fusion? It's supposed to be coming out around Sept. isn't it?

                                Comment

                                Working...
                                X