Announcement

Collapse
No announcement yet.

VIA Releases New Documentation, But It's Old

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

  • #16
    Originally posted by bridgman View Post
    ... and for the record, agd5f has done more work in this area than anyone I know, including myself...
    With Alex having spent and spending most of his time rewriting radeonhd into radeon and undermining radeonhd, and your statement above, part of why you never answered much of our (the radeonhd developers) questions is explained.

    Comment


    • #17
      ???

      The commit logs seem to indicate that most of the code flowed the other way (acceleration code moving from radeon to radeonhd).

      Maybe you are talking about the move to KMS, ie code going into drm rather than radeon ?

      Alex wrote most of the documentation released in the last couple of years, including figuring out how to program the chips. Not sure how that becomes a bad thing.

      I guess you are saying we should have put less effort into 3D and more effort into supporting modesetting without AtomBIOS (which we don't even do in-house) ? If so, that's a fair criticism, but we didn't feel those were the right priorities.
      Last edited by bridgman; 01-13-2010, 08:43 AM.

      Comment


      • #18
        Originally posted by bridgman View Post
        ???

        The commit logs seem to indicate that most of the code flowed the other way (acceleration code moving from radeon to radeonhd).

        Maybe you are talking about the move to KMS, ie code going into drm rather than radeon ?
        In as far as the timing of things do not already make things clear on their own, these commits tell a rather clear story:
        b7774c28
        0abfe315

        It is from a few weeks before alex had "officially" joined ATI, but I co-wrote the proposal to AMD to free ATI hw 2 months before i actually had joined SUSE, so one cannot state that alex his actions were just random acts to a persons hobby project anymore, not with the history that follows.

        Originally posted by bridgman View Post
        Alex wrote most of the documentation released in the last couple of years, including figuring out how to program the chips. Not sure how that becomes a bad thing.

        I guess you are saying we should have put less effort into 3D and more effort into supporting modesetting without AtomBIOS (which we don't even do in-house) ? If so, that's a fair criticism, but we didn't feel those were the right priorities.
        Whatever happened to all those register docs we got in the early days?

        You stated somewhere that documentation does not come falling out of the sky. In ATIs case, most of the lowlevel documentation is dumps from databases anyway. Not everyone needs to wait until someone has written a nice novel about it, some people actually manage to do useful things with register dumps (cfr radeonhd in the summer of 2007).

        There is also plenty of documentation still sitting around, waiting to be finally released. When we at SUSE got docs from AMD, we got pre-sanitised ones, and we've always been told that they would become public pretty much as-is, soon. I haven't been at SUSE anymore for about a year now, and i still have many documents that aren't free yet, making these docs rather a bit older than the ones VIA just released.

        Currently the claim is that r8xx modesetting code is "under review". You could hand out the register specs and the document which describes the usage of the r8xx version of atombios and the changes needed compared to previous versions. I have such a doc for dce 3.0 and/or 3.2, and since most of evergreen happened _after_ the ATI/AMD merger and the release of the first batch of docs, i guess that this display controller will have a similar document.

        Why is such information not available, why do you release the ISA doc instead? Who can make use of the ISA doc when modesetting is not doing anything yet?

        From this all the following question can be asked: Are your documentation releases meant to drive development and make ATI a properly free company, or are they just used to keep the punters quiet while useful code gets released and controlled from in-house as to not hurt fglrx too much?

        Comment


        • #19
          Originally posted by libv View Post
          In as far as the timing of things do not already make things clear on their own, these commits tell a rather clear story:
          b7774c28
          0abfe315

          It is from a few weeks before alex had "officially" joined ATI, but I co-wrote the proposal to AMD to free ATI hw 2 months before i actually had joined SUSE, so one cannot state that alex his actions were just random acts to a persons hobby project anymore, not with the history that follows.
          We have said multiple times that it was an independent effort. I agree the fact that Alex was not working for AMD at the time does not *prove* it was independent, but it does not *disprove* it either. In the end you either choose to believe us or not.

          Originally posted by libv View Post
          Whatever happened to all those register docs we got in the early days?

          You stated somewhere that documentation does not come falling out of the sky. In ATIs case, most of the lowlevel documentation is dumps from databases anyway. Not everyone needs to wait until someone has written a nice novel about it, some people actually manage to do useful things with register dumps (cfr radeonhd in the summer of 2007).
          Whether the information is low level or high level it still needs to be reviewed and sanitized. Big dumps of register info are generally the most time-consuming to sanitize and the least directly useful to developers, so they tend not to be the best use of time.

          Feedback on the initial register docs was not particularly positive, in the sense that they had excruciating detail in areas where nobody cared, and had big gaps in the interesting areas (where IP issues were trickier). We could probably put out a few more docs with the same issues (eg no coverage of PLLs or the new digital output blocks) but I didn't get the impression they would help enough to be worth taking effort away from other activities. Producing docs without the issues you all identified would be a much bigger task; I wasn't planning on doing that yet.

          Originally posted by libv View Post
          There is also plenty of documentation still sitting around, waiting to be finally released. When we at SUSE got docs from AMD, we got pre-sanitised ones, and we've always been told that they would become public pretty much as-is, soon. I haven't been at SUSE anymore for about a year now, and i still have many documents that aren't free yet, making these docs rather a bit older than the ones VIA just released.
          Remember that there were two levels of sanitizing. We did a "coarse" sanitizing before sending out under NDA to minimize the risk of "tainting" developers with knowledge that they would not be able to use in future development, but you received docs before detailed IP review. Our expectation was that the final docs would be similar to the "coarsely sanitized" ones - sometimes that was the case, sometimes not, depending on what turned up during the IP review.

          Originally posted by libv View Post
          Currently the claim is that r8xx modesetting code is "under review". You could hand out the register specs and the document which describes the usage of the r8xx version of atombios and the changes needed compared to previous versions. I have such a doc for dce 3.0 and/or 3.2, and since most of evergreen happened _after_ the ATI/AMD merger and the release of the first batch of docs, i guess that this display controller will have a similar document.
          The IP review is primarily concerned with the programming info implicit in the code, not the code itself. Handing out register specs (which document a lot of unused registers as well as the ones currently being used) makes the review slower, not faster.

          I don't think we found nice handy driver developer notes for the 8xx display logic similar to what we had for the earlier DCE changes but I'll check with Alex.

          Originally posted by libv View Post
          Why is such information not available, why do you release the ISA doc instead? Who can make use of the ISA doc when modesetting is not doing anything yet?
          The ISA docs come out of the stream computing team, so different people and different schedule requirements. The ISA info didn't change that much between 6xx, 7xx and Evergreen -- the changes on the modesetting side are bigger and juicier from an IP perspective.

          Originally posted by libv View Post
          From this all the following question can be asked: Are your documentation releases meant to drive development and make ATI a properly free company, or are they just used to keep the punters quiet while useful code gets released and controlled from in-house as to not hurt fglrx too much?
          "Properly free" means different things to different people, but our documentation and code releases are meant to drive development and allow the community to work independently on free drivers. We are obviously leaning more on AtomBIOS than you would like in order to get resources onto 3D sooner, but otherwise I think we are trying to do what you want.
          Last edited by bridgman; 01-13-2010, 12:44 PM.

          Comment


          • #20
            Originally posted by bridgman View Post
            We have said multiple times that it was an independent effort. I agree the fact that Alex was not working for AMD at the time does not *prove* it was independent, but it does not *disprove* it either. In the end you either choose to believe us or not.
            With all the lies and bended truths you have been spewing for the last 2.5 years, i won't believe you, i've seen you in action too much.

            Originally posted by bridgman View Post
            Whether the information is low level or high level it still needs to be reviewed and sanitized. Big dumps of register info are generally the most time-consuming to sanitize and the least directly useful to developers, so they tend not to be the best use of time.

            Feedback on the initial register docs was not particularly positive, in the sense that they had excruciating detail in areas where nobody cared, and had big gaps in the interesting areas (where IP issues were trickier). We could probably put out a few more docs with the same issues (eg no coverage of PLLs or the new digital output blocks) but I didn't get the impression they would help enough to be worth taking effort away from other activities. Producing docs without the issues you all identified would be a much bigger task; I wasn't planning on doing that yet.
            So therefor no docs are being freed at all, not even the ones that were handed to the suse people, and were said to become free. Not even the cute atombios usage docs that we were never handed before early 2008.

            Remember that there were two levels of sanitizing. We did a "coarse" sanitizing before sending out under NDA to minimize the risk of "tainting" developers with knowledge that they would not be able to use in future development, but you received docs before detailed IP review. Our expectation was that the final docs would be similar to the "coarsely sanitized" ones - sometimes that was the case, sometimes not, depending on what turned up during the IP review.
            But why stop at the coarse sanitizing all the time?

            The IP review is primarily concerned with the programming info implicit in the code, not the code itself. Handing out register specs (which document a lot of unused registers as well as the ones currently being used) makes the review slower, not faster.
            So you _are_ trying to hide how the chip is programmed?

            I don't think we found nice handy driver developer notes for the 8xx display logic similar to what we had for the earlier DCE changes but I'll check with Alex.
            I've heard you say similar openly worded things, even stating blatant bent truths ("I do not know") in front of the SUSE developers, the whole SUSE management food chain (all the way to the current CEO) and some similar setup on the AMD side.

            I should've asked you whether you are a betting man, and to what extent you could provide probability estimates to your "i do not know" becoming a "yes there is" or "no there isn't", and then bet you a months of net salary against those odds on your "i do not know" becoming an "yes there is". I would've made a steal just days later.

            So there are such docs, there were such docs for the previous 2 major changes in DCE/atombios. The fact that you openly word it like this now, with all the experience i have had with you, that makes me understand your sentence as: "Yes, there are such docs, and we will claim next week that we just made a happy discovery, which we can release right now, ain't that great?"

            Now you have a choice, either play your usual game, or hide this document from the public forever. But then, you still haven't made the previous docs of the same nature available either.

            The ISA docs come out of the stream computing team, so different people and different schedule requirements. The ISA info didn't change that much between 6xx, 7xx and Evergreen -- the changes on the modesetting side are bigger and juicier from an IP perspective.
            Ah, so the gpgpu team, if that still exists in the same guise. They were a combination of AMD and ATI people that was already completely assimilated into AMD even in 2007. And our hope for a while for getting information and docs without you squandering and delaying it.

            So since this was a completely separate team, what was your part in the release of these ISA docs? You were the one who stuck them online, or?

            "Properly free" means different things to different people, but our documentation and code releases are meant to drive development and allow the community to work independently on free drivers. We are obviously leaning more on AtomBIOS than you would like in order to get resources onto 3D sooner, but otherwise I think we are trying to do what you want.
            Your idea of what is a community seems limited to "mostly alex and the redhat guys". As no-one really is getting access to anything much, especially not any time close to the hardware release (and the time of fglrx support).

            Now, about the statement that you edited out, at the very end of your sentence: "(except for me dying screaming in fire, of course )." I do not think like that. I just want to see you stop twisting truths, stop playing games and stop hiding your own procrastination. But i do realise that this is hard to do, when you're so caught up in all of this, and when you're so used to your current mode of working.

            Comment


            • #21
              Originally posted by libv View Post
              With all the lies and bended truths you have been spewing for the last 2.5 years, i won't believe you, i've seen you in action too much.
              OK, your call. Probably not worth discussing any more then. Just a thought though -- if you see everyone who says something you disagree with as a liar after a while you're going to start feeling surrounded by liars.

              Originally posted by libv View Post
              So therefor no docs are being freed at all, not even the ones that were handed to the suse people, and were said to become free. Not even the cute atombios usage docs that we were never handed before early 2008.
              What makes you think that no docs are being freed at all ?

              Originally posted by libv View Post
              But why stop at the coarse sanitizing all the time?
              We don't. For docs like 6xx acceleration we finished the review (which also ended up needing a significant rewrite since the hardware changed a lot after the initial design docs were written), and released two docs. For smaller docs like the DCE 3.x design notes you mentioned we treated them as lower priority since the content was already well understood by the developers and there was working code as well, and low priority stuff is, well, low priority.

              Luc, maybe the big problem here is that when we work on B instead of A you are focusing on the fact we did not do A and wondering if there is some kind of conspiracy behind the decision, rather than thinking about all the time and effort that goes into B. The reality here is that we have finite time and resources and we try to focus on whatever will allow the development community to make the fastest overall progress. Right now that means getting initial documentation and/or code out for things which are not supported in the drivers rather than going back and releasing internal docs which helped to get earlier parts of the driver stack going.

              You don't have to agree with that approach, but it is what we are doing. If you have good arguments for changing those priorities please let us know.

              Originally posted by libv View Post
              So you _are_ trying to hide how the chip is programmed?
              How did you turn my statement (adding register specs to the initial code/header release would add more IP and make the review process take longer) into a statement that were trying to hide how the chip is programmed ?

              Originally posted by libv View Post
              I've heard you say similar openly worded things, even stating blatant bent truths ("I do not know") in front of the SUSE developers, the whole SUSE management food chain (all the way to the current CEO) and some similar setup on the AMD side.
              Sorry, you lost me here. How is "I don't know" a blatant bent truth ? Sometimes I don't know, and then that's what I say.

              Originally posted by libv View Post
              I should've asked you whether you are a betting man, and to what extent you could provide probability estimates to your "i do not know" becoming a "yes there is" or "no there isn't", and then bet you a months of net salary against those odds on your "i do not know" becoming an "yes there is". I would've made a steal just days later.
              I don't do well at gambling so I generally avoid it. If you see a way to make good money off this, let's discuss.

              Originally posted by libv View Post
              So there are such docs, there were such docs for the previous 2 major changes in DCE/atombios. The fact that you openly word it like this now, with all the experience i have had with you, that makes me understand your sentence as: "Yes, there are such docs, and we will claim next week that we just made a happy discovery, which we can release right now, ain't that great?"
              You ask about the doc, I say I don't know but will ask, then a week later maybe I have an answer. Exactly where is the conspiracy in that ? Our software devs don't normally write hardware documentation in the software design docs like they did for the DCE 3 transition, and the hardware documentation normally focuses more on hardware implementation than on programming model.

              Originally posted by libv View Post
              Now you have a choice, either play your usual game, or hide this document from the public forever. But then, you still haven't made the previous docs of the same nature available either.
              Luc, you aren't listening to what I am saying. We have finite resources and we work on what we feel to be the highest priority stuff first. That usually means we focus on documenting things which are *not* supported in the driver ahaed of things which *are* already supported and working in the driver.

              You mentioned atombios docco earlier; we have three working atombios-based implementations plus the disassembler code you guys wrote and published -- do you really see atombios docco as the highest priority right now ? If something is not a high priority, then we are probably *not* going to be working on it in for a while, but please try to focus on what we *are* doing at least as much as the things we are *not* doing yet.

              Originally posted by libv View Post
              Ah, so the gpgpu team, if that still exists in the same guise. They were a combination of AMD and ATI people that was already completely assimilated into AMD even in 2007. And our hope for a while for getting information and docs without you squandering and delaying it.
              If you were hoping to get graphics information from the GPGPU team that probably wasn't a very good plan.

              Originally posted by libv View Post
              So since this was a completely separate team, what was your part in the release of these ISA docs? You were the one who stuck them online, or?
              I had no part in the release of the ISA docs.

              Originally posted by libv View Post
              Your idea of what is a community seems limited to "mostly alex and the redhat guys".
              Add in Novell and independent developers and you've probably got it nailed. I doubt we're making any of them 100% happy.

              Originally posted by libv View Post
              As no-one really is getting access to anything much, especially not any time close to the hardware release (and the time of fglrx support).
              The plan we announced back in Sep 2007 said that we would start working on open source support *after* new products launched, and that fglrx was always going to be the vehicle for launch-time support since it shares common code used across multiple OSes. Again, you don't have to like it but that is what we said we would do, and what we *are* doing.

              We have been able to cut down the time between launch and initial support with each new generation :

              - the open source project started ~2 years after 5xx launched;
              - we started working on 6xx maybe a year after launch, and were able to include 7xx in the same effort
              - work on 7xx work started around launch but that doesn't really count because we didn't have working 6xx code to build on
              - we were able to start on Evergreen support a bit *before* launch *and* had working 7xx code to build on

              In other words, we've gone from being 2 years behind to starting work around launch time. I think that deserves a "Meets expectations" rating at the very least

              Originally posted by libv View Post
              Now, about the statement that you edited out, at the very end of your sentence: "(except for me dying screaming in fire, of course )." I do not think like that. I just want to see you stop twisting truths, stop playing games and stop hiding your own procrastination. But i do realise that this is hard to do, when you're so caught up in all of this, and when you're so used to your current mode of working.
              I am trying to change some aspects of how we work, particularly the 12 hour days. We actually took real vacations over the holidays, first time in almost three years. It was nice.

              Please try to understand that just because you believe one thing and I believe another, that doesn't make me a liar. I don't say things like that about you, please extend me the same respect.
              Last edited by bridgman; 01-16-2010, 12:13 AM.

              Comment


              • #22
                Fascinating as this discussion is, I'm not 100% sure of it's relevance to VIA doing a doc release.

                From what I've seen, Micheal is being harsh on VIA, but that cynicism is almost certainly not completely unfounded. Actions speak louder than words, and this doc release is certainly better than NOT having the docs, so lets at least thank them for what they have done. Having spoken to BruceChang, I can honestly say that on top of everything bridgman has said about the difficulties of releasing docs there IS a language barrier which won't be helping.

                I have been very happy with my VIA C7-M based netbook, and the only real complaint I have is related to HPs BIOS! (PCI-ids being wrong on a non-VIA component). It's a comfortable desktop with openChrome, and stable enough once I reported my bugs and they were fixed. It might be worth keeping in mind who actually has even halfway credible netbook platforms, because AMD don't, and from what I heard, neither the Intel ones, nor the nVidia ones, actually had adequate FOSS graphics support.

                Comment


                • #23
                  Originally posted by RobbieAB View Post
                  Fascinating as this discussion is, I'm not 100% sure of it's relevance to VIA doing a doc release.
                  We were trying to say something nice about Via's doc release, but it didn't go so well.

                  Comment


                  • #24
                    I know you were, but I just felt that the VIA forum was not the right place for libv and you to have a "You said, he said" argument, especially in a thread where we should all be clapping VIA on the back.

                    Comment


                    • #25
                      What the heck -- at least it keeps the forum busy
                      Last edited by bridgman; 01-16-2010, 02:30 PM.

                      Comment


                      • #26
                        What about VIA CPU docs?

                        When will VIA C7/Nano CPU docs be released? Agner Fog seem to need them.

                        Comment

                        Working...
                        X