문제

저는 OMAP3430용 비디오 코덱을 개발 중입니다.이미 C++로 작성된 코드가 있고 DSP를 활용하기 위해 코드의 특정 부분을 수정/포팅하려고 합니다(제가 가지고 있는 SDK(OMAP ZOOM3430 SDK)에는 추가 DSP가 있습니다).

매우 적은 양의 데이터(~250바이트)에서 실행되는 작은 for 루프를 포팅하려고 시도했지만 다른 데이터에서는 약 2M 번 수행되었습니다.그러나 CPU와 DSP 간의 통신으로 인한 과부하는 이득(있는 경우)보다 훨씬 더 큽니다.

나는 이 작업이 일반 컴퓨터의 GPU용 코드를 최적화하는 것과 매우 유사하다고 가정합니다.내 질문은 어떤 종류의 부품을 포팅하는 것이 도움이 될까요?GPU 프로그래머는 이러한 작업을 어떻게 처리합니까?

편집하다:

  1. GPP 애플리케이션은 0x1000바이트 크기의 버퍼를 할당합니다.
  2. GPP 애플리케이션은 DSPProcessor_ReserveMemory를 호출하여 자동 페이지 정렬을 고려하기 위해 할당된 버퍼보다 ​​4K 더 큰 크기를 사용하여 할당된 각 버퍼에 대한 DSP 가상 주소 공간을 예약합니다.총 예약 크기도 4K 페이지 경계를 따라 정렬되어야 합니다.
  3. GPP 애플리케이션은 DSPProcessor_Map을 호출하여 할당된 각 버퍼를 이전 단계에서 예약된 DSP 가상 주소 공간에 매핑합니다.
  4. GPP 애플리케이션은 GPP에 할당된 버퍼에 매핑된 가상 주소 공간의 기본 주소를 DSP 실행 단계에 알리기 위한 메시지를 준비합니다.GPP 애플리케이션은 DSPNode_PutMessage를 사용하여 메시지를 DSP에 보냅니다.
  5. GPP는 memcpy를 호출하여 처리할 데이터를 공유 메모리에 복사합니다.
  6. GPP 애플리케이션은 DSPProcessor_FlushMemory를 호출하여 데이터 캐시가 플러시되었는지 확인합니다.
  7. GPP 애플리케이션은 버퍼에 대한 쓰기가 완료되었으며 DSP가 이제 버퍼에 액세스할 수 있음을 DSP 실행 단계에 알리는 메시지를 준비합니다.또한 메시지에는 버퍼에 기록된 데이터의 양이 포함되어 있어 DSP가 복사할 데이터의 양을 알 수 있습니다.GPP는 DSPNode_PutMessage를 사용하여 DSP에 메시지를 보낸 다음 DSPNode_GetMessage를 호출하여 DSP에서 메시지를 다시 들을 때까지 기다립니다.

이후 DSP 프로그램 실행이 시작되고 DSP는 처리가 완료되면 메시지로 GPP에 알립니다.그냥 시도해 보려고 DSP 프로그램 내부에 어떤 처리도 넣지 않았습니다.방금 GPP에 "처리 완료" 메시지를 보냈습니다.그리고 이것은 여전히 ​​많은 시간을 소비합니다.내부/외부 메모리 사용량 때문일까요, 아니면 단순히 통신 과부하 때문일까요?

도움이 되었습니까?

해결책 3

제가 측정한 바에 따르면 CPU와 DSP 사이의 한 메시징 주기는 약 160us가 걸립니다.이것이 내가 사용하는 커널 때문인지, 아니면 브리지 드라이버 때문인지는 모르겠습니다.하지만 간단한 메시지 주고받기에는 매우 오랜 시간이 걸립니다.

총 계산 부하가 메시징에 필요한 시간과 비슷할 경우에만 알고리즘을 DSP로 이식하는 것이 합리적인 것 같습니다.알고리즘이 CPU와 DSP의 동시 컴퓨팅에 적합한지 여부.

다른 팁

OMAP3430에는 온보드 DSP가 없으며 시스템 버스에 연결된 IVA2+ 비디오/오디오 디코드 엔진이 있고 Cortex 코어에는 DSP와 유사한 SIMD 명령이 있습니다.OMAP3430의 GPU는 PowerVR SGX 기반 장치입니다.프로그래밍 가능한 셰이더가 있지만 CUDA 또는 OpenCL과 같은 범용 프로그래밍에 대한 지원은 없다고 생각합니다.제가 틀렸을 수도 있지만 그런 지원은 들어본 적이 없어요

내장된 IVA2+ 인코딩/디코드 엔진을 사용하는 경우 이 장치에 적합한 라이브러리를 사용해야 하며 내가 아는 특정 코덱만 지원합니다.이 모듈에 자신만의 라이브러리를 작성하려고 하시나요?

Cortex에 내장된 DSPish(SIMD 지침)를 사용하는 경우 일부 코드를 게시하세요.

개발 보드에 추가 DSP가 있는 경우 DSP는 무엇이며 OMAP에 어떻게 연결됩니까?

데스크톱 GPU 질문에 관해서는, 비디오 디코드의 경우 공급업체에서 제공한 함수 라이브러리를 사용하여 하드웨어를 호출합니다. Linux의 Nvidia용 VDAPU, Windows의 유사한 라이브러리(PureViewHD라고 생각합니다)가 여러 개 있습니다.ATI에는 또한 온보드 디코드 엔진을 위한 Linux 및 Windows 라이브러리가 모두 있습니다. 이름은 모르겠습니다.

전송하는 데이터의 시간 기반이 무엇인지는 모르지만 SDK 사양 시트에 나열된 TMS32064x에는 매우 강력한 DMA 엔진이 있다는 것을 알고 있습니다.(원래 ZOOM OMAP34X MDK라고 가정합니다.64xx가 있다고 나와 있습니다.) OMAP에 비슷한 것이 있으면 최대한 활용하기를 바랍니다.64xx의 내부 RAM에 "핑퐁" 버퍼를 설정하고 DMA에 의한 전송 핸들이 있는 공유 메모리로 SDRAM을 사용하는 것이 좋습니다.외부 RAM은 6xxx 시리즈 부품에서 병목 현상이 발생하므로 성능 향상을 위해 내부 메모리에 잠글 수 있는 모든 것을 유지하십시오.일반적으로 이러한 부품은 내부 메모리에 있는 경우 프로세서 코어에 8개의 32비트 단어를 버스하는 기능이 있지만 직접 액세스 RAM으로 매핑할 수 있는 캐시 수준에 따라 부품마다 다릅니다.TI의 비용에 민감한 부품은 "매핑 가능한 메모리"를 다른 칩보다 더 멀리 이동시킵니다.또한 부품에 대한 모든 설명서를 TI에서 PDF로 무료로 다운로드할 수 있습니다.그들은 심지어 나에게 TMS320C6000 CPU와 명령어 세트 매뉴얼 및 기타 여러 책의 하드카피를 무료로 제공했습니다.

프로그래밍에 관한 한 수행 중인 수학을 최적화하려면 "프로세서 내장 기능" 또는 인라인 어셈블리 중 일부를 사용해야 할 수도 있습니다.64xx의 경우 부동 소수점 코어가 내장되어 있지 않기 때문에 가능하면 정수 연산을 선호합니다.(이것들은 67xx 시리즈에 있습니다.) 실행 장치를 살펴보고 단일 주기에서 발생할 수 있는 방식으로 다양한 부품이 다양한 작업을 목표로 하도록 계산을 매핑할 수 있다면 최고의 성능을 얻을 수 있습니다. 그 부분들 중.명령어 세트 매뉴얼에는 각 실행 단위에서 수행되는 작업 유형이 나열되어 있습니다.계산을 이중 데이터 흐름 세트로 나누고 루프를 약간 풀 수 있다면 전체 최적화가 켜져 있을 때 컴파일러가 "더 좋을" 것입니다.이는 프로세서가 왼쪽과 오른쪽으로 나누어져 양쪽에 거의 동일한 실행 단위가 있기 때문입니다.

도움이 되었기를 바랍니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top