Until it is a laptop nobody will use via when a pci-e/agp card could be added.
Announcement
Collapse
No announcement yet.
VIA Releases New Documentation, But It's Old
Collapse
X
-
Originally posted by Kano View PostUntil it is a laptop nobody will use via when a pci-e/agp card could be added.
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..Stop TCPA, stupid software patents and corrupt politicians!
Comment
-
Originally posted by Zhick View PostI 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. :>
Comment
-
Originally posted by bridgman View Post... and for the record, agd5f has done more work in this area than anyone I know, including myself...
Comment
-
???
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; 13 January 2010, 09:43 AM.Test signature
Comment
-
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 ?
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 PostAlex 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.
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
-
Originally posted by libv View PostIn 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 libv View PostWhatever 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).
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 PostThere 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.
Originally posted by libv View PostCurrently 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.
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 PostWhy 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?
Originally posted by libv View PostFrom 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?Last edited by bridgman; 13 January 2010, 01:44 PM.Test signature
Comment
-
Originally posted by bridgman View PostWe 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 bridgman View PostWhether 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.
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.
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.
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.
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.
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
-
Originally posted by libv View PostWith 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 libv View PostSo 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.
Originally posted by libv View PostBut why stop at the coarse sanitizing all the time?
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 PostSo you _are_ trying to hide how the chip is programmed?
Originally posted by libv View PostI'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.
Originally posted by libv View PostI 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.
Originally posted by libv View PostSo 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?"
Originally posted by libv View PostNow 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.
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 PostAh, 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.
Originally posted by libv View PostSo 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?
Originally posted by libv View PostYour idea of what is a community seems limited to "mostly alex and the redhat guys".
Originally posted by libv View PostAs no-one really is getting access to anything much, especially not any time close to the hardware release (and the time of fglrx support).
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 PostNow, 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.
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; 16 January 2010, 01:13 AM.Test signature
Comment
Comment