AMD Has Been Working On An Open-Source GPU Debug Tool, To Be Released Soon

[geearf]

There are many interesting low cost hifi amplifiers in China, with or without spdif. I bought SMSL SA - 36A PRO and it is really good with my B&W speakers.

http://www.gearbest.com/speakers/pp_448998.html

I have to say, you never cease to amaze!

[geearf]

If be "old ASICS" he meant those that will never be supported by amdgpu driver than it makes sense. It would be too much effort to make DAL/DC interact with the radeon driver as well.

On the other hand GCN 1.0 hardware that will be supported by amdgpu will probably be supported by DAL/DC as well in the future. I'm not affiliated with AMD nor have any inside info so it's just a guess, but it would just create more problems for them to have different paths inside amdgpu with both DAL/DC and the legacy code

Well now there's that:

... or until we (or someone) port the audio code from radeon to amdgpu (for SI).

[geearf]

If be "old ASICS" he meant those that will never be supported by amdgpu driver than it makes sense. It would be too much effort to make DAL/DC interact with the radeon driver as well.

On the other hand GCN 1.0 hardware that will be supported by amdgpu will probably be supported by DAL/DC as well in the future. I'm not affiliated with AMD nor have any inside info so it's just a guess, but it would just create more problems for them to have different paths inside amdgpu with both DAL/DC and the legacy code

Well maybe you're right.

[Ansla]

If be "old ASICS" he meant those that will never be supported by amdgpu driver than it makes sense. It would be too much effort to make DAL/DC interact with the radeon driver as well.

On the other hand GCN 1.0 hardware that will be supported by amdgpu will probably be supported by DAL/DC as well in the future. I'm not affiliated with AMD nor have any inside info so it's just a guess, but it would just create more problems for them to have different paths inside amdgpu with both DAL/DC and the legacy code

[geearf]

As I undertand it AMD does not plan to further improve HDMI audio support in amdgpu without DC (former DAL). So the real question you are asking is "when will DC be upstreamed?". And that question can't be answered more precisely than "hopefully soon".

Hmmm, when I asked @agd5f in the past I believe he said DAL would not include code for the old ASICS.
I assumed that it meant the code would be ported from radeon, but if you're correct that means we'll never get any audio :/

The current code is also broken: if we don't disable audio with xrandr, we get an annoying purple line on the left side.

I don't care that much about upstream, as long as there's a stable patch somewhere that allows me to have audio on amdgpu I'll be happy, I want to be able to use radv with dolphin and co

[Ansla]

As I undertand it AMD does not plan to further improve HDMI audio support in amdgpu without DC (former DAL). So the real question you are asking is "when will DC be upstreamed?". And that question can't be answered more precisely than "hopefully soon".

[geearf]

bridgman
A bit unrelated, but is there a guess as to which kernel will land hdmi audio for SI on amdgpu?

Thanks!

None? :/

[bridgman]

The problem is that almost everything we work on involves some kind of NDA information... but if we decide that something is worth making public we strip out the NDA bits, plug in the rest of the non-NDA bits, and publish. Most of the work which does not involve NDA information is already done in public, eg performance optimizations on the open source drivers.

There are exception cases like umr, and we could potentially have separate policies for those, but none of us are enthusiastic about adding even more policies to the ones we have today.

[chithanh]

I'm still not quite sure what you are so upset about.

I am not upset, I apologize if I gave that impression.

Are you saying that the instant someone puts three lines of code together and compiles it they must be compelled to set up a public repo ? If not, then where is the threshold ?

Compelled? No.

If the code contains NDA information about upcoming GPUs (and as far as I understand, it doesn't really - the real secret is in data, not code) or other reasons for secrecy, then keep it closed by all means. However in the absence of such reasons, having the three lines of code in some public repository would be a better service to the community.

Other reasons I could fathom is that developers do not want others to grab their unfinished code and finish it before them, or taking it into directions they don't want, while taking all the credit. This I understand is what was behind Xgl, Tamil, etc. release decisions, but I think is not the case with the GPU debug tool in question.

[bridgman]

Depends a bit on what you mean by "such things"...

"development work on unannounced chips, particularly dGPUs, will happen in the open by default" - no.

"working on tools happens in the open once they become interesting/useful", that has already largely happened.

"working on tools happens in the open with full community ownership of the code base", that is starting to happen.

"the instant someone has an idea and puts a few lines of code together they must be compelled to set up a public repo", no.