Until it is a laptop nobody will use via when a pci-e/agp card could be added.
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.
Until it is a laptop nobody will use via when a pci-e/agp card could be added.
Thanks via. Nvidia, shame on you. Even via is somehow able to release documentation.
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..
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.
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.
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?
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.
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.
Last edited by bridgman; 01-13-2010 at 01:44 PM.
But why stop at the coarse sanitizing all the time?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.
So you _are_ trying to hide how the chip is programmed?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'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 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.
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.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?
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)."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.