Проблеми са ХД звуком у АМДГПУ управљачким програмима примају закрпе, ДРМ сада може да се бави врућим прикључивањем

АМД

Иако су Радеон / АМД ГПУ добили бољу Линук подршку са новијим ГПУ моделима, аудио подршка је била до сад занемаривана. Закрпу је недавно гурнуо СУСЕ-ов Такасхи Иваи, који такође одржава звучни подсистем у главном језгру Линука. Закрпа бави се неким свеукупним проблемима са АМДГПУ аудио подршком.

Тренутни проблеми са АМДГПУ звуком врте се око неких графичких процесора да би ХДМИ / ДП аудио подршка каснила АМДГПУ кодом за приказ (ДЦ / ДАЛ) који треба поправити у језгру, неколико аудио формата није подржано и све грешке у одређеним деловима стацк возача. Међутим, СУСЕ-ов Такасхи Иваи објавио је сет закрпа за Радеон / АМДГПУ ДРМ управљачке програме.

Оно што ове закрпе раде је пружање подршке за ДРМ аудио компоненту за драјвере Радеон и АМДГПУ Дирецт Рендеринг Манагер - укратко, режим ДРМ аудио компоненте за ХДМИ и ДисплаиПорт интерфејсе ће омогућити очитавање аудио прикључака и ЕЛД, без хардверског приступа . То у основи значи да му се може дозволити правилно руковање врућим утикачима, чак и ако је систем у режиму обуставе рада. Међутим, стазе АМДГПУ ДЦ кода нису правилно састављене у тренутном облику закрпе.

Дакле, у основи, закрпа се обраћа само Радеону и делу АМДГПУ-а - ДЦ подршка још није укључени.

Такасхи је дубље објаснио закрпе:

Управљачки програми за АМД / АТИ ХДМИ кодеке нису имали везивање аудио компонената као и915, али је радио само са традиционалним ХД-аудио нежељеним догађајем за откривање ХДМИ прикључака и очитавање ЕЛД-а након тога. Ово је представљало проблем на много начина: пре свега пролази кроз хардверску транзицију догађаја (од уписивања у ГПУ регистар, окидача ХД-аудио контролера и на крају до управљања нежељеним догађајима ХД-аудио-а), који је често непоуздан и може пропустити неке могућности. Друго, за свако руковање нерешеним догађајима и очитавање ЕЛД-а потребно је изричито укључивање / искључивање када је кодек у суспензији рунтиме-а. Последње, али не најмање важно, што је најважније, буђење хотплуга може пропустити када је ХД-аудио контролер у обустави рада. Поготово је последња тачка велики проблем због недавне промене релевантне за вга_свитцхероо која присилно омогућава рунтиме ПМ за АМД ХДМИ контролере.

Ова питања се решавају увођењем аудио компоненте; обавештење о хотплуг-у врши се директним повратним позивом функције, што је тачније и поузданије, и може се обрадити без стварног хардверског приступа, тј. није потребан окидач ПМ рунтиме, а ХД-аудио добија догађај чак и ако је у току обуставити. Исто је и за ЕЛД упит, јер се чита директно из кешираних ЕЛД бајтова ускладиштених у ДРМ управљачком програму, па се може прескочити читав приступ хардверу.

Дакле, ту је: ова закрпа имплементира везивање аудио компонената са АМД / АТИ ДРМ управљачким програмом. Највећа разлика од примене и915 је та што је ово везивање потпуно необавезно и може се омогућити асинхроно у ходу. Односно, управљачки програм ће се пребацити са нежељеног ХД-аудио догађаја на обавештени повратни позив једном када се ДРМ компонента веже. Слично томе, када се ДРМ возач истовари, обрада догађаја ХДМИ такође се враћа у застарели режим.

Такође, још једна разлика од и915 је та што АМД ХДМИ региструје компоненту у управљачком програму кодека, док и915 ХДМИ кодек претпоставља да је везивање компоненте већ извршено. Стога АМД код такође одјављује везивање компоненте на излазу из кодека. “