The Fallacy Behind Open-Source GPU Drivers, Documentation

[elanthis]

Not sure how to reply to this. You're basically saying that we should redesign our products to make things easier for open source driver developers. Honestly, that is not likely to happen.

No. I'm not sure how to say this any more clearly, dude. Last try: it's bullshit to say that customers want proprietary software. That's all I'm saying. Nothing more, nothing less. Completely irrelevant to the story of AMD drivers or anything I expect or demand or desire that AMD do. I'm simply saying that when you list out the reasons that both drivers exist, "users want a proprietary driver" is complete horseshit. They want media playback. Microsoft and the media conglomerates and the electronics companies have decided that to get media playback users must swallow proprietary software and DRM. That doesn't mean users want it. Given the option, any consumer who knows the difference would opt for DRM and proprietary software to die in a fire. So yeah, AMD is not going to invest into FOSS drivers the way they invest into Catalyst or ever release Catalyst's source, ever, period, and nobody should fault them for it because it would be horrendously stupid business. Just don't ever claim that's because consumers want it that way.

[kirillkh]

You're basically saying that we should redesign our products to make development less stressful for open source driver developers.

Err, no. The conversation went like this:
Me: can the GPU be virtualized?
You: no, but we have some internal tools, which we won't open source, as it would expose our internal hardware design. We can give you remote access to these tools, though, if you prove yourself worthy.
Me: wait, that's not a solution, because it defeats the purpose of building a FOSS driver (and wouldn't solve the problem anyway, because newcomers won't get access when they need it most). So the only solution I see is if you implement this and that instructions, and that should do the job.

I just showed that what you said didn't solve the problem and offered another solution. If you say that solution is unrealistic either, I'm fine with that.

[ssam]

so what is the perfect dev setup? something like this

1 test box, with graphics card (preferably with easy access to swap it), serial port, and network. no valuable data.

1 dev machine.

set of scripts that lets you write some code on the dev machine, compile it, and get the test box to netboot it. you have a serial link to debug over. hard crashes don't matter because there is no persistent data.

integrate git bisecting, benchmarking etc, so you can quickly test different setups.

maybe you could have several test machines with different cards. when you hit run on the dev machine, the new code is booted on each test machine.

[Ex-Cyber]

So the only solution I see is if you implement this and that instructions, and that should do the job.

I can't really claim to be an expert on chip design, but I don't see any simple way to do this without opening up the risk of creating even more problems. The hardware to read/write the relevant internal registers might already exist in the form of a scan chain, but that's not something that chip companies are generally going to go out of their way to expose/document. Even if you could somehow lock down or idiot-proof it (tiny embedded microcontroller operating the scan chain?), you'd still need to make sure that the code managing the state dump(s) is immune to the same sorts of driver bugs that you want to recover from. Creating a state dump isn't very useful if the next thing you do is clobber it with a stray DMA.

[DeepDayze]

Bridgman stated in my ATI bashing thread the following, on page 1, and I quote:

"We work with the community to make initial support available (working code and/or docs) and the open source community does most of the enhancement work. We were told multiple times "just give us programming information and the community will do the rest" - we are doing that and more."

Anyone else want to take a poke at me?

ok will you provide us with a link to where Bridgman says that? Or will you just please shut up. If you have the hard evidence we'd gladly would like to see it.

I feel that AMD has been much more open with docs than they rightfully should be and we should be thankful for the work of Bridgman et al in getting as many ATI cards working for those who have them.

Then why not contribute in some way to X Org development rather than bashing the devs?

/end rant

[deanjo]

ok will you provide us with a link to where Bridgman says that? Or will you just please shut up.

Great little link up top called "Search"

http://www.phoronix.com/forums/showpost.php?p=161267&postcount=2

[bridgman]

No. I'm not sure how to say this any more clearly, dude. Last try: it's bullshit to say that customers want proprietary software. That's all I'm saying. Nothing more, nothing less. Completely irrelevant to the story of AMD drivers or anything I expect or demand or desire that AMD do. I'm simply saying that when you list out the reasons that both drivers exist, "users want a proprietary driver" is complete horseshit. They want media playback. Microsoft and the media conglomerates and the electronics companies have decided that to get media playback users must swallow proprietary software and DRM. That doesn't mean users want it. Given the option, any consumer who knows the difference would opt for DRM and proprietary software to die in a fire. So yeah, AMD is not going to invest into FOSS drivers the way they invest into Catalyst or ever release Catalyst's source, ever, period, and nobody should fault them for it because it would be horrendously stupid business. Just don't ever claim that's because consumers want it that way.

Elanthis, I have *never* said that users want a proprietary driver and I wish you would stop claiming that I did. What I have said multiple times is that users want features and performance comparable with other OSes, and that we can only deliver those things into a small market through code sharing with other OSes (because the cost of implementing a new driver would be too high for the market to justify). A consequence of the code sharing is that the resulting drivers also need to be delivered in binary form rather than exposing source code.

Err, no. The conversation went like this:
Me: can the GPU be virtualized?
You: no, but we have some internal tools, which we won't open source, as it would expose our internal hardware design. We can give you remote access to these tools, though, if you prove yourself worthy.
Me: wait, that's not a solution, because it defeats the purpose of building a FOSS driver (and wouldn't solve the problem anyway, because newcomers won't get access when they need it most). So the only solution I see is if you implement this and that instructions, and that should do the job.

I just showed that what you said didn't solve the problem and offered another solution. If you say that solution is unrealistic either, I'm fine with that.

A couple of things. I never discussed remote access to the tools and we have no intention of providing that. Alex and Richard are AMD employees working on the open source drivers.

Your proposed solution involves major changes at the lowest level of the chip (which, for performance reasons, will end up impacting blocks all over the chip), which in turn is what lead to my commment that you are asking us to redesign our products in order to simplify the job of non-AMD open source developers. I think we are saying the same thing, you just don't like the way I'm saying it

[deanjo]

A consequence of the code sharing is that the resulting drivers also need to be delivered in binary form rather than exposing source code.

What OS "forces" you to have a closed source driver? MS allows opensource drivers and OS X allows opensource drivers so what OS that AMD supports requires drivers to be closed source?

[Ex-Cyber]

What OS "forces" you to have a closed source driver? MS allows opensource drivers and OS X allows opensource drivers so what OS that AMD supports requires drivers to be closed source?

Who said that it's forced by the OS? It's more likely to be forced by license agreements with third parties covering bits of the shared code and/or the hardware features that they enable.

[bridgman]

Drivers for most of the other OSes have to implement robust DRM, and implementing robust DRM in an open source driver is not really practical with the current state of hardware design.

I have never seen an open source driver meet the certification requirements (particularly DRM) for those OSes, although I agree that it is possible in principle.