AMD Radeon Software Crimson 15.12 For Linux Released

[duby229]

Nope, I'm saying that the release notes are created by a combination of a really simple automated system and a bit of a human's time. The discussion here is a bunch of people saying that getting full change logs would be easy to 100% automate (in response to my question about whether we really want to divert developer time from improving the driver to improving the change logs) and I'm trying to explain why that is not the case.

duby229, nothing to do with damage control, just responding to all the posts saying "you don't need a human for this" - your latest post just says "oh a developer could do it" which is what I've been saying all along.

Who said that? A computer will never be able to describe why a change was made. I can't think of any knowledgeable person that would expect that. Most of the people that would find themselves reading this thread probably at least consider themselves technically inclined, and would expect logically that the real people developing those changes would document them in an end user friendly manner. Especially on linux where you guys already know that userbase expects that much.

EDIT: My point that I made yesterday is that it's AMD's own policies that prevent real developers from documenting changes in an end user friendly manner. Why exactly do you need a third person to document changes when the authors of those changes should be documenting them on the fly? A third person will never have the intuition the author of those changes had when he made them.

[bug77]

Who said that? A computer will never be able to describe why a change was made. I can't think of any knowledgeable person that would expect that. Most of the people that would find themselves reading this thread probably at least consider themselves technically inclined, and would expect logically that the real people developing those changes would document them in an end user friendly manner. Especially on linux where you guys already know that userbase expects that much.

EDIT: My point that I made yesterday is that it's AMD's own policies that prevent real developers from documenting changes in an end user friendly manner. Why exactly do you need a third person to document changes when the authors of those changes should be documenting them on the fly? A third person will never have the intuition the author of those changes had when he made them.

Basically he's saying most of the time the developer doesn't know which OS is impacted by a given fix. What's puzzling is there should be some validation of any fix saying problem X was successfully tested on Windows/Linux/BSD/whatever and you could generate something based on that (I'm thinking something akin to tags in JIRA).
But then again, that wouldn't jive well with the whole "it might work, we truly don't know and won't bother much to find out" attitude AMD has towards Linux when it comes to Catalyst.

[duby229]

Basically he's saying most of the time the developer doesn't know which OS is impacted by a given fix. What's puzzling is there should be some validation of any fix saying problem X was successfully tested on Windows/Linux/BSD/whatever and you could generate something based on that (I'm thinking something akin to tags in JIRA).
But then again, that wouldn't jive well with the whole "it might work, we truly don't know and won't bother much to find out" attitude AMD has towards Linux when it comes to Catalyst.

I guess what I find hard to believe is that they don't know what will have an effect on linux. Really? I don't buy that at all. Maybe their third person doesn't know, but the guys developing the changes must.

EDIT: And if it's really true that they don't know what effects their changes are going to have on linux, then it really is so much more important now to drop the proprietary driver completely. What they are doing now can't possibly be called support.

[bug77]

I guess what I find hard to believe is that they don't know what will have an effect on linux. Really? I don't buy that at all. Maybe their third person doesn't know, but the guys developing the changes must.

EDIT: And if it's really true that they don't know what effects their changes are going to have on linux, then it really is so much more important now to drop the proprietary driver completely. What they are doing now can't possibly be called support.

Imagine you're working on a piece of those drivers and bug lands on your lap: function drawPinkElephants(int) fails when int > 1. You fix the bug, but can you tell which OS will be affected?
Of course, normally the bug would have attached a list of affected platforms so you can check that you have actually fixed the issue, but, apparently, that's not what happens at AMD.

[duby229]

Imagine you're working on a piece of those drivers and bug lands on your lap: function drawPinkElephants(int) fails when int > 1. You fix the bug, but can you tell which OS will be affected?
Of course, normally the bug would have attached a list of affected platforms so you can check that you have actually fixed the issue, but, apparently, that's not what happens at AMD.

It's simple, will that function be used on linux? If so, document. Period. I'm sure they must be using some sort of revision management system. I can't imagine they are writing catalyst with a text editor and rsync.

[dungeon]

bridgman

Long story short, just tell Raja that Linux people complain on communication, how Linux driver releases are documented, etc... you will need that more and more to be done normal with GPUOpen effort too I guess AMD wants that to succeed, if so - then learn to communcate normally

[bridgman]

bridgmanLong story short, just tell Raja that Linux people complain on communication, how Linux driver releases are documented, etc... you will need that more and more to be done normal with GPUOpen effort too I guess AMD wants that to succeed, if so - then learn to communcate normally

Yep, I think that is understood - my question was whether you all though improving change logs was worth diverting some developer time from improving the driver to improving the change logs and I think I'm hearing the answer is "yes". Thanks all.

[duby229]

I guess I just don't understand why you think resources will have to be diverted. If an improvement was made in the driver -and- it was documented, then improving the driver and improving documentation is exactly one and the same.

EDIT: The only reason that comes to mind is a fault of AMD's policies, which I described yesterday and you claimed you couldn't understand.

[bridgman]

I guess I just don't understand why you think resources will have to be diverted. If an improvement was made in the driver -and- it was documented, then improving the driver and improving documentation is exactly one and the same.

EDIT: The only reason that comes to mind is a fault of AMD's policies, which I described yesterday and you claimed you couldn't understand.

Which specific policy are you talking about (ie what do you think the policy directs developers to do / not do) ?

The changes *are* documented in the form which is most useful to the developers (including references to specific customer requirements and/or hardware and/or issues, but that is not the same as publicly releasable documentation. Is that what you believe is wrong ?

[bug77]

bridgman

Long story short, just tell Raja that Linux people complain on communication, how Linux driver releases are documented, etc... you will need that more and more to be done normal with GPUOpen effort too I guess AMD wants that to succeed, if so - then learn to communcate normally

Well, that's certainly not short, because you don't actually know where that function is used. It may be packaged and shipped with any OS, but that does not guarantee it is actually called.

Yep, I think that is understood - my question was whether you all though improving change logs was worth diverting some developer time from improving the driver to improving the change logs and I think I'm hearing the answer is "yes". Thanks all.

Well, answering a question with a question is, let's say, inelegant. You've made is clear something's messed up with Catalyst on Linux since it's the only piece of software that I know of that can't afford the effort of documenting changes. And despite being singled out in this position, you still seem to suggest everything's just peachy.