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.

After reading many Phoronix articles, I gather that legal review of code (in AMD) can take a really long time, and sometimes code is never even released due to concerns that potential "IP" or "patents" will be lost (or in the case of video acceleration bullshit concerns over DRM). Is this true?

In that case, if people external to AMD contributed more, would that speed up development since there's no legal barrier on them?

Also, I would like to know from the AMD employees here if they consider the information and specifications already released by AMD sufficient to make the drivers stable and feature-complete (the features I'm thinking about are very good power management, full 2D and 3D acceleration, OpenGL 4.3 support, OpenGL ES 3.0 support, OpenCL 1.2 support - all depending on hardware capability of course).

After reading many Phoronix articles, I gather that legal review of code (in AMD) can take a really long time, and sometimes code is never even released due to concerns that potential "IP" or "patents" will be lost (or in the case of video acceleration bullshit concerns over DRM). Is this true?

In that case, if people external to AMD contributed more, would that speed up development since there's no legal barrier on them?

Code itself doesn't go through review other than the devs making sure there is no additional IP being released with it. It's the big chunks of new hardware programming info that take time... not because programming info itself needs to be protected but because programming info sometimes reveals internal design info that we can't easily get agreement to release.

Even then, it's usually not the review that takes time, it's figuring out what to do when the answer is "no" the first (or second, or third) time. The process is kind of a parallel activity -- get internal agreement on what information we can expose (that's what takes the time) and make sure the initial code we plan to release which uses that info stays within the bounds of what we have approval to release.

Key point though is that other than a couple of remaining areas like power management and UVD, driver progress is primarily a function of the amount of developer time available to work on it, so additional contributions definitely speed up development.

Originally Posted by sandy8925

Also, I would like to know from the AMD employees here if they consider the information and specifications already released by AMD sufficient to make the drivers stable and feature-complete (the features I'm thinking about are very good power management, full 2D and 3D acceleration, OpenGL 4.3 support, OpenGL ES 3.0 support, OpenCL 1.2 support - all depending on hardware capability of course).

Power management no (but we're working on it), everything else pretty much yes. I say pretty much because there are always questions and problems that come up during development but we can usually respond to those pretty quickly if we can lay hands on the information internally. As am example, I don't think we have written documentation that says "this is how you implement tesselation on xxx generation of hardware" (because we usually have to write code ourselves to figure it out anyways), so our devs either write the initial code themselves or work with the community devs who are implementing new functionality. You can watch a lot of that happening on #dri-devel and #radeon.

There are exceptions to everything, of course. HDMI audio information turned out to be a bit of a black hole, which we didn't expect at all, while other areas turn out to be easier than we expected. Normally driver devs don't have to care about "where the hardware came from" but when you try to release programming info to the public everything that ever happened in the last ten years of HW development becomes a possible roadblock. We can generally get through or around all the issues eventually, but it tends to take finite calendar time as well as effort and so is hard to speed up by throwing more resources at it.

HDMI audio information turned out to be a bit of a black hole, which we didn't expect at all, while other areas turn out to be easier than we expected.

Hi John, thanks for all your work. I'm curious if HDMI audio is something that is still being worked on? I recently bought a nettop that has a Radeon 4310 card in, and I'd love the ability to passthrough TrueHD / DTS-HD content. Do you think this will ever be possible? For those interested, is there a mailing list or wiki that might have status updates? I find it to be a difficult subject to track.

I still don't understand why IP review seems to be the biggest overall roadblock with open source driver development in AMD's case. I have never heard of any such problems from Intel developers, and certainly I haven't seen month or even year long delays that could be attributed to legal issues.

It's not a good sign when the processes inside a company make it impossible to work efficiently.

I guess AMD probably uses too much licensed IP, intead of developed in house. Among this IP even though the tone here is to hate patents. At least patents are public documents, so you can read it and reverse engineer or design around. AMD's biggest problem are probably Trade Secrets, which can also be licensed, but are worthless if ever published. So in the license agreement there should be a clause stating that AMD would have to pay a heavy penalty if it releases documents (and/or) that teaches someonelse's trade secrets.

Thus, they are stuck at endlessly trying to write code to talk to a part of the chip without disclosing how it actually works. Don't expect too much.

Given the current state of affairs, I would rather have them release closed source modules, which would talk to the rest of the open stak and slowly open waterver they feel possible to (noveau does something similar right?). But even then, maybe these can be reverse engineed too...

The issue is not a *lot* of third party IP but rather the presence of *any* third party IP unless there are very clear lines between what is 100% ours and what may contain a mix of AMD and third party IP. In many cases the third party IP is just a licensed standard (the audio and video-out areas are lousy with external standards), not actual hardware or software tech.

The only place this has been a real problem so far was HDMI audio, where the more we investigated the murkier it all became... and that was all related to everyday standards, not what you normally think of as licensed technology. Everywhere else third party IP has just been "one more thing we have to investigate".

A small closed source module with open source code above and below is so easy to reverse engineer that it might as well be open source unless we invest a lot of time in obfuscation. I would rather spend time getting approval to expose in open source.

I still don't understand why IP review seems to be the biggest overall roadblock with open source driver development in AMD's case. I have never heard of any such problems from Intel developers, and certainly I haven't seen month or even year long delays that could be attributed to legal issues.

You might want to talk to some of the Intel developers who were active back in 2007-2009. Intel started the process of releasing *code* well before we did (and there was some "waa waa see what Intel is doing" in our initial proposals for code release), but we actually obtained approval to release *documentation* before they did and I'm sure there was a bit of "waa waa see what AMD is doing" discussion inside Intel before their documentation started to flow.

Other companies just don't say anything until the code/docco/whatever is released. We are trying to be more open but it does have drawbacks as well as benefits.

The issue is not a *lot* of third party IP but rather the presence of *any* third party IP unless there are very clear lines between what is 100% ours and what may contain a mix of AMD and third party IP. In many cases the third party IP is just a licensed standard (the audio and video-out areas are lousy with external standards), not actual hardware or software tech.

The only place this has been a real problem so far was HDMI audio, where the more we investigated the murkier it all became... and that was all related to everyday standards, not what you normally think of as licensed technology. Everywhere else third party IP has just been "one more thing we have to investigate".

A small closed source module with open source code above and below is so easy to reverse engineer that it might as well be open source unless we invest a lot of time in obfuscation. I would rather spend time getting approval to expose in open source.

The point I was trying to make is not related to the total amount of third party IP, but the relative amount, i.e., intel has been able to release PM code and hardware video accelaration. I assume this is because those blocks are completely desinged in house or at least contain very little third party IP. Not trying to say here that in house is necessarily better, but it does give more flexbility with regard to open source.

You are probably right about the small closed source module. But I thought that UVD and PM were right there next to HDMI audio in the queue to get approval to release code. Wouldn't in these cases a "big module" be an alternative?

Also, maybe you should point out to the AMD execs that Chromebooks are starting to get traction. Samsung, acer, lenovo and now HP are puting out models, and all of them, with the exeption of samsung with "intel inside". So the argument that OEMs are not requesting linux support is getting weaker by the minute... Maybe just not from AMD, I wonder why. It's sad really. I would be all over a kabini chromebook with proper drivers and coreboot. It would trounce anything intel has to offer in the price range.

I don't even get what's the point of AMD being the "cost effective" solution if it comes with the windows license...