"Radeon Settings" GUI Control Panel May Be Open-Sourced For AMD Linux Users

[bridgman]

Go ahead, open it up! (Like nvidia-settings has been for years...)

IIRC the fglrx control panel was open as well, at least that's what I was told by the devs. There were a few different implementations over the years so not 100% sure the most recent one was open, but our general pattern has been open control panels as well.

Why would they release the control panel as closed source in the first place?

The most recent one was initially written for Windows, and Windows users tend not to care either way AFAICS.

[anda_skoa]

The most recent one was initially written for Windows, and Windows users tend not to care either way AFAICS.

Exactly! So no reason not to have it open.

Or did you mean your Windows developers don't care if their collegues on other platforms have to do extra work?

Cheers,
_

[bridgman]

I don't really understand the question. The same people do the extra work related to preparation for open sourcing no matter which OS the work is being done for. If there is no market need and no perceived market benefit why not spend the effort on something that the customers *do* want ?

[anda_skoa]

I don't really understand the question.

Apparently there is now extra effort necessary to make something open that the Windows developers created.
If it had been open in the first place, that extra effort would not have been necessary.

So maybe the Windows developers didn't care that this extra effort would have to be spent or they didn't consider that their work could benefit the work of others.

Does "the customer doesn't care" imply "the collegues don't care"?
If yes, should it?

If there is no market need and no perceived market benefit why not spend the effort on something that the customers *do* want ?

Well, apparently someone now needs to spend extra effort that wouldn't have been necessary if the original developers had thought a tiny bit about their collegues needs additional to the customer needs.

Is there no perceived benefit in making someone's coworkers' lifes easier by not artifically creating obstacles?

Or maybe even an "us vs. them" culture, where a team would avoid doing anything that could potentially benefit another team?

Cheers,
_

[bridgman]

Sorry, I really don't understand what point you are trying to make here.

You mentioned "artificially creating obstacles"... do you actually mean that (and if so can you help me understand what you have in mind ?) or do you just mean "not doing the open source prep work which nobody had asked for, at the cost of not being able to do work which people *had* asked for" ?

[anda_skoa]

Yes, intentionally creating obstacles would of course be worse, but this sounds like a situation where additional effort could have been avoided by thinking about other developers' needs in advance.

It could of course also be a marketing thing: open sourcing something can probably be spun more effectively than developing it that way in the first place.

Cheers,
_

[bridgman]

I guess I don't understand why you think of this as "additional effort (that) could be avoided"... open sourcing something that we also use internally *is* additional effort whether the work is done earlier or later.

You keep implying that open sourcing something written for and integrated into the Windows tool & build framework is free and that is just not the case.

[anda_skoa]

No, sorry, I am not trying to imply that at all.

Of course open sourcing something after it has been written is a extra effort.
Comments, commit logs, etc. need to be reviewed, code might have to be rewritten to remove hacks, etc.

The missed opportunity, which would have avoided the extra effort, would have been to develop it like that in the first place.

With a bit of forward thinking management could have arrived at the conclusion that the tool might not only be of interest to the customers using Windows but also to customers using Linux or macOS.
At which point they could have determined that the company's resources would not be sufficient to port the code and require community help, for which they would need access to the source code.

I know, this is a lot of thinking, but contrary to popular believe it do consider it possible that managers are actually capable of it.
Not in this case, obviously, but in general.

[bridgman]

Of course open sourcing something after it has been written is a extra effort.
Comments, commit logs, etc. need to be reviewed, code might have to be rewritten to remove hacks, etc.

The missed opportunity, which would have avoided the extra effort, would have been to develop it like that in the first place.

Ahh, we're definitely talking about different things then. The effort you are talking about is normal practice anyways - even when we don't open source our code we occasionally provide it to key partners under a source code license so we always need to assume that others will be looking at our code. The work I'm talking about is tasks like:

- disconnecting the power-related logic from the lower levels of the Windows driver framework
- isolating power management / system management / DRM functions (they can be integrated for efficiency in Windows but not when open sourcing)
- replacing internal libraries (which have build-time logic for real silicon or various emulators/simulators) with non-proprietary equivalents
- setting up separate build frameworks independent of our production build/test systems
- removing dependencies on MS proprietary header files

etc...

[duby229]

I don't really understand the question. The same people do the extra work related to preparation for open sourcing no matter which OS the work is being done for. If there is no market need and no perceived market benefit why not spend the effort on something that the customers *do* want ?

Hold on, How many -years- have we all been saying that AMD desperately needs a better control panel application? Been at least since 2007 that I've been harping on it. If AMD doesn't know their customers want one by now........