If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I'm a developer and I love open source software, but this idea that open source software progresses faster than closed source is just silly. If this were true then the original topic(HD 7000 2D accel) wouldn't have made the news in December of 2012. Can open source software progress faster than closed source? Sure, but such an oversimplified claim is borderline ridiculous.

There are many examples of proprietary software that pushed innovation and/or usability: UNIX, Photoshop, etc.

In the case of Photoshop, the open source world has had plenty of time to catch up and make software that is far better than Photoshop, assuming open source does indeed progress faster. IMO, GIMP is the closest and it does a good job of being an open source alternative but GIMP it isn't exactly pushing the boundaries. Now, don't get me wrong. I personally use GIMP and would never buy Photoshop but I'm also able to see past my own use cases and realize not everyone is the same.

This is of course ignoring the fact that if you take financial incentive away from programmers then there will be many less programmers writing software than there is today(including those that write open source software). Yes, programmers do get paid to write free software but they are far outnumbered by the folks that write proprietary software. Yes, companies sell support for free software but again this is a very small market in the grand scheme. Many(most?) open source developers have a day job involving proprietary software.

Why is selling support for a free open source program ethically better than selling a proprietary program with support?

And why does almost every conversation on this site end up in a open source vs proprietary software argument?

---------------

Has anyone tried these new patches for HD7000 that can tell us more about their experience with them?

Just to be clear: Photoshop has dozens of (probably poorly paid) Indian developers and a huge budget behind it,
while I can probably count the number of GIMP contributors on my right hand.
I believe Open Source progresses faster, given the same resources as proprietary software.

In the case of Photoshop, the open source world has had plenty of time to catch up and make software that is far better than Photoshop, assuming open source does indeed progress faster.

Well, like with professional audio software you probably need very experienced people to implement most stuff efficiently. I think for quite some features you need at least a M.Sc level of education/book reading for even understanding the theory/math behind it.

further thoughts

Originally Posted by dalingrin

I'm a developer and I love open source software, but this idea that open source software progresses faster than closed source is just silly. If this were true then the original topic(HD 7000 2D accel) wouldn't have made the news in December of 2012. Can open source software progress faster than closed source? Sure, but such an oversimplified claim is borderline ridiculous.

<omitted>

There are many examples of proprietary software that pushed innovation and/or usability: UNIX, Photoshop, etc.

<omitted>

This is of course ignoring the fact that if you take financial incentive away from programmers then there will be many less programmers writing software than there is today(including those that write open source software). Yes, programmers do get paid to write free software but they are far outnumbered by the folks that write proprietary software. Yes, companies sell support for free software but again this is a very small market in the grand scheme. Many(most?) open source developers have a day job involving proprietary software.

<omitted>

This hardly seems to be a fair comparison. If ATI/AMD were a bit more open about their proprietary hardware, then the free software drivers could progress more rapidly. The free software drivers seem to be hamstrung by internal ATI/AMD review processes about what will be made public vs. what will be kept secret. This is why I question ATI/AMD's committment to free software.

UNIX is a bad example for "proprietary" software that "pushed innovation." AT&T shared source code freely with the BSD project and others in the early years. Moreover, many of the key innovations in UNIX, such as Berkeley sockets and TCP/IP, were developed at Berkeley, not AT&T. In fact, it was 4.3 BSD that pushed AT&T to write System V in order to compete with the BSD system!

While it does seem likely that there are more people paid to write proprietary software than free software, it also seems likely that an increasing number of people are being paid to write free software. The uptick in the number of funding sites for free software projects supports this notion. These sites are demonstrating that people are willing and able to pay developers for features in free software.

This hardly seems to be a fair comparison. If ATI/AMD were a bit more open about their proprietary hardware, then the free software drivers could progress more rapidly. The free software drivers seem to be hamstrung by internal ATI/AMD review processes about what will be made public vs. what will be kept secret. This is why I question ATI/AMD's committment to free software.

That's not entirely fair. Some stuff does take longer to release than others, but it basically comes down to manpower and community interest. The frequency with which we can release code/information depends directly on how busy we are. Also there usually aren't nice programming guides ready for release so we have to either write code to take advantage of the new feature, or write programming information for the community, both of which take time. We generally try and push out enough working code and documentation so that that community can run with it if they want to implement features before we get to it. There are a number of areas where the information has been available for a while, but no one has done anything with it until recently or not at all (MSAA, HiZ, geometry/hull/domain shaders, programmable interpolation, hardware bits for additional GL extensions, etc.). There are also areas where things could be improved that have a major impact that have nothing to do with hardware information (improving the driver memory manager, adding more common OpenGL/OpenCL infrastructure, improving EXA/glamor, etc.).

That's not entirely fair. Some stuff does take longer to release than others, but it basically comes down to manpower and community interest. The frequency with which we can release code/information depends directly on how busy we are. Also there usually aren't nice programming guides ready for release so we have to either write code to take advantage of the new feature, or write programming information for the community, both of which take time. We generally try and push out enough working code and documentation so that that community can run with it if they want to implement features before we get to it. There are a number of areas where the information has been available for a while, but no one has done anything with it until recently or not at all (MSAA, HiZ, geometry/hull/domain shaders, programmable interpolation, hardware bits for additional GL extensions, etc.). There are also areas where things could be improved that have a major impact that have nothing to do with hardware information (improving the driver memory manager, adding more common OpenGL/OpenCL infrastructure, improving EXA/glamor, etc.).

Maybe I'm the only one but I think this GPU book might also help a lot to attract new developers (new to GPU driver development).

PS. I say "attract new developers" because it feels like you (AMD representatives) are not that happy with the amount of community contributions.

Don't think we are saying that *we* are not happy. There is actually a fair amount of community development activity happening, but it isn't necessarily in the same areas where users have the most interest. If you look at compute, for example, there are a number of active community developers and some of their work crosses over into graphics (compiler fixes, for example).

The idea was that this would be a community-developed driver with a bit of help from AMD, so if you are not happy with the rate of progress, then it's probably fair to say that *you* are not happy with the amount of community contributions.

I understand this, but I also think that most people would be extremely happy with the driver, if the power management and UVD parts which have apparently been written by AMD programmers, were released. These are the main gripes with the open drivers, and also the things where the community can't help much, or their contributions would be already obsoleted by already existing (but yet unreleased due to technical review) code. Correct me if I'm wrong.

In terms of adding GL functionality and optimisations, I think that the community is doing a really good job already. It's just that some people don't realise how difficult a task this is for all of Mesa, and how much has already been achieved.

I feel that the work AMD is doing -- concentrating on CL support and new hardware enablement -- is the right thing to do. If only the PM (and perhaps UVD) were finally fixed, it would be a mean driver!

Don't think we are saying that *we* are not happy. There is actually a fair amount of community development activity happening, but it isn't necessarily in the same areas where users have the most interest. If you look at compute, for example, there are a number of active community developers and some of their work crosses over into graphics (compiler fixes, for example).

The idea was that this would be a community-developed driver with a bit of help from AMD, so if you are not happy with the rate of progress, then it's probably fair to say that *you* are not happy with the amount of community contributions.

That's why I said *feels*.
If it's not the case - that's much appreciated - because I guess it might have a negative impact on your open-source strategy.

Well, indeed, I'm not happy with the progress concerning this book/document.
But I didn't intend to point at those people coming up with the great idea and now have other priorities.
It's IMHO just unfortunate that it seems stalled.

I understand this, but I also think that most people would be extremely happy with the driver, if the power management and UVD parts which have apparently been written by AMD programmers, were released. These are the main gripes with the open drivers, and also the things where the community can't help much, or their contributions would be already obsoleted by already existing (but yet unreleased due to technical review) code. Correct me if I'm wrong.

In terms of adding GL functionality and optimisations, I think that the community is doing a really good job already. It's just that some people don't realise how difficult a task this is for all of Mesa, and how much has already been achieved.

I feel that the work AMD is doing -- concentrating on CL support and new hardware enablement -- is the right thing to do. If only the PM (and perhaps UVD) were finally fixed, it would be a mean driver!

I appreciate all the work the AMD OSS team is doing, so keep it up.

Agree on UVD, and partially agree on PM (community could have done more but I understand why it didn't seem like a good use of limited time), but the discussion was about HD7xxx general support not PM/UVD and I think we're well past the point where AMD-supplied info is the primary gating factor for HD7xxx.

We did explicitly exclude UVD at the start of the program, but also said we would work on finding ways to release some support and we are continuing to make progress on that. I really wish people would stop trivializing the situation though... the fact we started writing code internally doesn't mean that is the code we can release, but the process can't really even *start* until we have working code internally.

PM is a bit of a different story, in the sense that everyone is having to wait for "perfect" (which we knew would be time-consuming and uncertain) simply because "good enough" (improved driver-based PM) didn't come along a year or two ago like we expected. We are pushing ahead with what we hope will be a pretty capable PM solution, but that was never meant to be "the next step" since we knew it would probably take a long time. I did expect PM to play out differently, but I guess that's water under the bridge now.

I really wish people would stop trivializing the situation though... the fact we started writing code internally doesn't mean that is the code we can release, but the process can't really even *start* until we have working code internally.

I wasn't trying to trivialise, I was just going by the information available to me, and it is understandable that I don't have deep understanding of AMD's internal processes, especially ones dealing with technical and legal review