Announcement

Collapse
No announcement yet.

Bringing The R600 Gallium3D Driver Up To Speed

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

  • #51
    Originally posted by HokTar View Post
    It seemed from outside they were sometimes pretty lost having no idea what is causing a certain problem. It was my impression, I might as well be wrong on this. Only Alex can tell this.
    Welcome to driver development.

    Alex has access to internal devs and architects, including both hardware and software teams. Even so, I didn't get the sense that Alex and Matthew were fighting "lack of hardware knowledge" problems as much as trying to find the right design approach for integrating PM into the new KMS stack and making that new design actually work.

    The approach they ended up with is different from fglrx, but it allows one implementation to be used across many generations of GPU, while the fglrx driver uses different approaches depending on the GPU generation. This makes the open source drivers more maintainable over a long period of time.

    HokTar, I don't really understand your previous comments. If you look back, any time anyone "proudly said there were three devs" there actually *were* three devs, so I don't see what's wrong with saying that at the time. Ditto your comments about management; are you saying that management is doing something wrong because we are not funding the entire open source development effort ourselves on top of the fglrx work which drives most of our sales ?

    I really don't think Corbin's comment about getting a driver working in three months was for a *useable* driver, just for the basic framework which could then evolve into a useable driver over time.
    Test signature

    Comment


    • #52
      Originally posted by HokTar View Post
      I don't want to hinder anybody's efforts. I was referring to the fact that so far you always said that you have 3 oss devs (which unfortunately decreased to 2 about half a year ago) and in addition only Alex's work is apparent to oss *consumers*. So I guess I was more like "you should not be proudly say we have 3 devs when it actually comes down to be just 1".
      I guess I don't understand how you can ignore Richard's and Cooper's work. Anyone using 3D on 6xx/7xx is using their work, and Richard was working on GLSL right up until the end of last year. If you're saying that anyone not making a public commit every week is "dead to you" I guess that's OK, but I don't understand it.

      Originally posted by HokTar View Post
      And some more about this "be proud" thing. Alex is doing an awesome work, granted. But still, evergreen is pretty much nowhere near, dynpm is far from being finished - I think this is AMD's side right now. On the oss side Jerome is writing r600g and Marek and Corbin *almost* finished r300g while Dave started so many projects to add some interesting features.
      The information required for dynamic PM has been out for over a year already; it's hardly something that only AMD could work on. Alex was working on dynpm mostly because he was interested in it, and partly because we needed to have at least something equivalent to ForceLowPowerMode for KMS users.

      Seems like I'm disagreeing with everything you say today; sorry about that

      Originally posted by HokTar View Post
      All in all, I had the feeling that AMD is falling behind on its part - in my opinion due to lack of manpower - and thus I said what I said.
      That's the part that baffles me - our commitment never included providing the manpower in the first place, so how does lack of manpower constitute "falling behind on our part" ?

      Originally posted by HokTar View Post
      Providing the docs is much appreciated and seems to work just fine. I don't expect AMD to write all the drivers, but for example you should have done that with dynpm - just publish the powerplay bits of fglrx and don't make Alex and co. spend months to figure out how it works.
      The power management functionality in fglrx is woven all through millions of lines of code. There's a core module which handles hardware settings but Alex & Matthew had that part figured out early. You can't just "take the power management bits out of fglrx" and plug them into the open source stack - removing a Goa'uld symbiote would be easy by comparison.

      With respect, I think you may be underestimating the complexity of writing a modern graphics driver.
      Test signature

      Comment


      • #53
        Originally posted by bridgman View Post
        I guess I don't understand how you can ignore Richard's and Cooper's work. Anyone using 3D on 6xx/7xx is using their work, and Richard was working on GLSL right up until the end of last year. If you're saying that anyone not making a public commit every week is "dead to you" I guess that's OK, but I don't understand it.
        Well, I'm not ignoring, I only said that I haven't seen anything from them in about 5-6 months. This time period is a *bit* more than 1 commit/week, so I think you are exaggerating too much here.

        Originally posted by bridgman View Post
        Seems like I'm disagreeing with everything you say today; sorry about that
        How could we have a conversation if we would agree on everything?
        My only concern is that I don't intend to insult anyone. As far as I can keep it that way it's fine. If I ever overstep that line please let me know!

        Originally posted by bridgman View Post
        That's the part that baffles me - our commitment never included providing the manpower in the first place, so how does lack of manpower constitute "falling behind on our part" ?
        Yeah, this is exactly what makes everybody confused, because every single time this is the ultimate answer. I mean what should I think: you write code but you still mention every time that you provide the docs and expect the community to write the actual drivers. So you say something and do a bit of the opposite. Go figure.
        I'm _not_ saying you should stop committing. I only think that this causes some confusion.

        Originally posted by bridgman View Post
        The power management functionality in fglrx is woven all through millions of lines of code. There's a core module which handles hardware settings but Alex & Matthew had that part figured out early.
        I was referring more to this part and didn't know that it is already done.

        Originally posted by bridgman View Post
        You can't just "take the power management bits out of fglrx" and plug them into the open source stack
        I never said or expected this. Even though I'm just a mechanical engineer I thought this was the case.

        Originally posted by bridgman View Post
        removing a Goa'uld symbiote would be easy by comparison.
        My favourite! Stargate FTW!

        Comment


        • #54
          Originally posted by bridgman View Post
          I guess I don't understand how you can ignore Richard's and Cooper's work. Anyone using 3D on 6xx/7xx is using their work, and Richard was working on GLSL right up until the end of last year. If you're saying that anyone not making a public commit every week is "dead to you" I guess that's OK, but I don't understand it.
          In a very active opensource project with lots and lots of developers where everyone's developing pretty much everything and not committing could mean someone else does what you were designing instead that might be an understandable point of view imo. There you could end up dead in the fashion that you never get anything public because someone else does it first. A bit different for this graphics drivers, admittedly.

          Comment


          • #55
            Originally posted by HokTar View Post
            I mean what should I think: you write code but you still mention every time that you provide the docs and expect the community to write the actual drivers. So you say something and do a bit of the opposite. Go figure.

            I'm _not_ saying you should stop committing. I only think that this causes some confusion
            We're not saying something and doing the opposite, we're saying something and doing *more*

            I agree about the confusion, but I don't really know how to address it. We (AMD and the community developers) send out a consistent message, but once that message has been digested and restated by a half dozen people it doesn't seem to hold up so well.
            Test signature

            Comment


            • #56
              Originally posted by bridgman View Post
              We (AMD and the community developers) send out a consistent message, but once that message has been digested and restated by a half dozen people it doesn't seem to hold up so well.
              Maybe more propaganda towers are needed so people get the message directly? :3

              Comment


              • #57
                Originally posted by nanonyme View Post
                Then again, you could hypothesize that since KMS is said to be somewhat more CPU-intensive than UMS at the moment (unless this is obsolete information), it would be very apparent in glxgears since glxgears fps mostly depends on how fast your CPU is.
                I think glxgears is mostly affected by the extra memory copy in the DRI2 paths, rather than by KMS directly. Either way, complaining that gears is a few hundred fps slower is pretty silly. Replicate the slowdown in a real application that is running under 300fps and people might pay attention.

                Comment


                • #58
                  Awesome work! Seams like every kernel now have some new and interesting feature!

                  Comment


                  • #59
                    Slightly off topic, but I've been meaning to ask this for a while...

                    bridgman, are there any plans from X.org or AMD for a campaign to attract new blood? I'm thinking specifically of the Endless Vacation of Code which could do with a bit more publicity.

                    Perhaps writing letters to the CS departments of different colleges and universities, presenting the opportunity, would reach the right people? (Especially if it had an AMD letterhead )

                    (Getting Phoronix to mention EVoC a couple of times couldn't hurt either of course!)

                    Comment


                    • #60
                      X.org should create a learning program (irq channel?), were you could go and ask questions and directions were to start if you want to be a Xorg dev.

                      Comment

                      Working...
                      X