Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 26

Thread: VIA Releases New Documentation, But It's Old

  1. #11
    Join Date
    May 2008
    Location
    Germany/NRW
    Posts
    510

    Default

    I also think Michael has been bashing VIA a little bit to hard in the recent past. IIRC the r500-based cards also already were pretty old by the time AMD released the documentation, but it was still cheered at by everyone including Michael.
    I guess that was because many people already had a r500-card back then anyway. VIAs problem imho is that nobody has their chips currently, so that documentation covering old hardware only benefits the very few owners of those chips. If VIA would release the documentation for its current chips, that'd be more interesting for (and cheered at by) linux-users in general because that'd be something they could base a purchase of new (VIA) hardware on.
    ... I'm not entirely sure if it's getting clear what I mean, my english fails me. :>
    Last edited by Zhick; 01-12-2010 at 03:48 PM.

  2. #12
    Join Date
    Aug 2007
    Posts
    6,645

    Default

    Until it is a laptop nobody will use via when a pci-e/agp card could be added.

  3. #13
    Join Date
    Nov 2007
    Location
    Die trolls, die!
    Posts
    525

    Default

    Thanks via. Nvidia, shame on you. Even via is somehow able to release documentation.

  4. #14
    Join Date
    Mar 2009
    Location
    in front of my box :p
    Posts
    818

    Default

    Quote Originally Posted by Kano View Post
    Until it is a laptop nobody will use via when a pci-e/agp card could be added.
    Not the full truth.
    There are a lot of miniITX boards (or smaller systems) floating around and these definitely would make e.g. a nice HTPC or something, but they often only have 1 PCI slot so you really have to decide what to put in. And this is classic PCI so go find a PCI card today. There aren't many.

    And even with the laptops it would be great to get them to fly. I know of a few with VIA GPU. Older models but also newer, even the recent draft for the next OLPC contain a lot of VIA stuff iirc..

  5. #15
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    333

    Default

    Quote Originally Posted by Zhick View Post
    I also think Michael has been bashing VIA a little bit to hard in the recent past. IIRC the r500-based cards also already were pretty old by the time AMD released the documentation, but it was still cheered at by everyone including Michael.
    I guess that was because many people already had a r500-card back then anyway. VIAs problem imho is that nobody has their chips currently, so that documentation covering old hardware only benefits the very few owners of those chips. If VIA would release the documentation for its current chips, that'd be more interesting for (and cheered at by) linux-users in general because that'd be something they could base a purchase of new (VIA) hardware on.
    ... I'm not entirely sure if it's getting clear what I mean, my english fails me. :>
    VIA is rather hard of hearing, always has been. They also manage to squander opportunity after opportunity, and it required the SUSE guys to and AMD management to attempt to free ATI properly (which by and large failed in the end), and a lot of good marketing for ATI (undeservedly), before VIA also decide to try to clean up its image. Sadly though, it's done the VIA way, and not even half as well executed as it should be.

  6. #16
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    333

    Default

    Quote 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.

  7. #17
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,541

    Default

    ???

    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 at 09:43 AM.

  8. #18
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    333

    Default

    Quote 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.

    Quote 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?

  9. #19
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,541

    Default

    Quote 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.

    Quote 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.

    Quote 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.

    Quote 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.

    Quote 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.

    Quote 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 at 01:44 PM.

  10. #20
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    333

    Default

    Quote 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.

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •