performance estimation : occupancy
GPU를 이용해 가속을 할 때 생각보다 성능이 많이 개선되지 않았다고 느낄 때가 많다. 또 성능 평가를 어떻게 해야하는지도 모르고 막연히 빨라지겠지 기대할 수 도 있다.
성능에 영향을 주는 중요한 요인 중 하나가 occupancy다. 말 그대로 점유율을 뜻하는데 이전 포스팅에서 적었듯이 GPU에서 global memory를 접근하는 것은 매우 큰 비용이 발생한다. 따라서 context switching이 원활하게 일어 날 수 있도록 CU에 Work Group(WG)이 많이 올라와 있는것이 유리하다. 결국 WG를 많이 올리는 동시에 kernel program이 빠른 속도로 수행되는 적절한 지점을 찾는 것이 중요하다.
WG를 무작정 많이 올리는 것이 가능할까?
당연히 resource는 유한하고 제약이 있다. Radeon R9 290X를 두고 예를 들어보자.
CU안의 resource를 보면 다음과 같다.
vector unit
vGPR(vector General Purpose Register)
sGPR (scalar General Purpose Register)
LDS (Local Data Share)
vector unit 당 최대로 올릴 수 있는 WF(WaveFront) 가 10개로 제한되어 있다. 따라서 CU당 총 40개의 WF가 올라 갈 수 있는데 WG가 4WF로 이루어져 있다면 총 10개의 WG이 CU에 올라갈 수 있는 것이다.
256kB vGPR : 4 * 64 * 4 * 256
순서대로 4 vector unit , 64 lane, 4byte, 256 vGPR를 의미한다.
정리해보면 64K vGPR이 존재한다. 즉 최대로 사용할 수 있는 vGPR이 64K 개라는 것인데 만약 kernel에서 하나의 WI(Work Item)가 42개의 vGPR를 사용하고, 하나의 WG에 4WF로 이루어져 있다면 하나의 WG가 42_256 vGPR을 필요로 한다. 따라서 64K / 42_256 = 6.095.. 6개의 WG을 올릴 수 있다.
8kB sGPR : 4 * 2K
순서대로 4byte, 2K sGPR을 의미한다
즉 CU에서 최대로 사용할 수 있는 sGPR이 2K 개로 만약 WG이 4WF로 이루어져있고 WF당 50 sGPR를 필요로 한다면 WG당 200 sGPR을 필요로 한다. 따라서 10.24, 10개의 WG가 CU에 올라갈 수 있다.
64kB LDS
간단하게 하나의 WG에 4kB의 local memory를 할당해 준다면 64 / 4 = 16, 즉 16WG를 올릴 수 있다.
결과적으로 위 4개의 제약사항을 모두 만족할 수 있는 WG가 CU에 올라가게 된다. 따라서 occupancy는 다음과 같다
댓글 없음:
댓글 쓰기