Hisilicon 기린920 그래픽 성능/T-Rex, Manhattan 클럭 설정 추정.

-

하이실리콘 기린920(Hisilicon Kirin920) 벤치마크 결과가 GFX벤치 사이트에 올라왔습니다.

(링크 : http://gfxbench.com/device.jsp?benchmark=gfx30&os=Android&api=gl&D=Huawei%20Honor%206%20%28H60-L01%29)

하이실리콘은 화웨이(Huawei)의 (일종의) 자회사로 팹리스 업체입니다.

(썩 좋은 성능은 아니었지만) 대표적인 제품이 K2V3

 

기린920은 Cortex-A15 x4 + Cortex-A7 x4, Mali-T628MP4 600MHz의 사양을 갖고 있다고 알려져 있습니다.

이름이 기린인건 중국 업체라서 그런듯.

Cortex-A15 클럭은 1.7~2.0GHz로 알려져있는데, GFX벤치 결과의 시스템 정보상에는 1.7GHz로 나옵니다.

그리고 LTE Cat.6 통합 AP 입니다

 

(링크 : http://www.antutu.com/view.shtml?id=7879)

 

 

-

쓸데없는 사전정보가 길었는데 바로 본론으로 들어가겠습니다.

기린920 결과를 보면 맨해튼 오프스크린 8.0 fps 입니다.

600MHz라는 클럭을 생각해도 엑시노스5250의 T604, 엑시노스5260의 T628MP3 결과가 3.7 fps 수준인걸 생각하면 많이 높습니다.

최근 엑시노스5422가 최적화의 영향으로 맨해튼 성능이 올라갔는데^[각주:1] 이와 연계해서 성능-클럭 관계를 분석해보겠습니다.

 

그러기위해서는 먼저 정확한 클럭을 알아야합니다.

엑시노스5422 성능과 커널을 통해서 파악되는 엑시노스의 성능-클럭 패턴은 이렇습니다.^[각주:2]

1. 텍셀필레이트 결과를 통해 클럭을 계산.

2. DVFS 테이블에서 1.의 클럭과 가장 가까운 값을 찾음.

3. DVFS 테이블에서 2.에서 찾은 클럭 바로 윗 단계 클럭이 티렉스, 맨해튼 클럭.

 

커널을 뒤져본 결과 엑시노스의 GPU DVFS 테이블은 다음과 같습니다. (단위 : MHz)

(모든 엑시노스 제품이 나오지 않은건 기린920과의 비교를 위해 말리 계열만 쓰기때문입니다.)

5250 - 100 160 266 350 400 450 533

5420/5422 - 100 177 266 350 420 480 533(543)

5260 - 160 266 350 450 560 667

 

그리고 GFX벤치 상에서 나타나는 위 제품의 테스트 결과는 다음과 같습니다.

	MP	Texel fillrate (MTex/s)	T-Rex off (fps)	Manhattan off (fps)
5250	4	1429	15.5	3.6
5420	6	2189	25.0	6.5
5422 (기존)	6	2113	27	8.8
5422 (최근)	6	2551	28.9	10.1
5260	3	1213	14.8	3.7
Kirin920	4	1683	16.5	8.0

 

텍셀필레이트 결과로 클럭을 추정해보면,

	MP	Texel fillrate	계산 클럭(MHz)	DVFS 클럭(MHz)	T-Rex/Manhattan 클럭(MHz)
5250	4	1429	357	350	400
5420	6	2189	365	350	420
5422 (기존)	6	2113	352	350	450 (유효클럭[각주:3])
5422 (최근)	6	2551	425	420	480
5260	3	1213	404	400	450
Kirin920	4	1683	421	420??	600??

 

이 클럭을 기준으로 클럭,MP당 프레임을 계산해보면,

(이런 방식을 쓴다는건 프레임이 MP, 클럭에 비례한다는 가정이 깔린겁니다.)

 

 

- 클럭당성능 : 티렉스

Mali-T600 계열을 보면 10.0 수준이 나옵니다.

그런데 5260은 높고 기린920은 낮습니다.

이제와서 티렉스 결과가 최적화될 가능성은 낮기때문에 이 둘의 추정클럭이 잘못 됐을 가능성이 높습니다.

 

5260은 450MHz보다 높다는건데, 테이블 다음 클럭인 560MHz로 계산하면 8.8 이 나와서 오히려 낮아집니다.

중간 클럭으로 봐야하는데 5422의 기존 결과의 유효클럭이 테이블상의 420, 480MHz가 아닌, 중간값인 450MHz인 사례를 생각하면 5260에서도 같은 방식이 적용될 가능성이 있습니다.

450, 560의 중간클럭이 505MHz = 500MHz 정도로 볼 수 있겠네요.

 

기린920은 600MHz로 가정했을 때 낮게 나온걸로봐서 실제 클럭은 더 낮은 것으로 보입니다.

텍셀결과에서 계산된 420MHz를 적용하면 9.8 이 나와서 어느정도 들어맞습니다.

 

티렉스 클럭 추정.

5260 - 유효 500MHz

기린920 - 420MHz

 

 

- 클럭당성능 : 맨해튼

맨해튼에서 5422가 10%정도 최적화된건 전에 이미 언급했습니다.^[각주:4]

 

기린920은 기존 5422와 같은 수준입니다.

맨해튼 클럭은 600MHz로 가정한건데 550~560MHz 선으로 낮춰잡으면 최근 5422와 비슷한 수준까지 올라는갑니다.

티렉스와 달리 변수가 많아서 클럭을 낮춰잡는게 쉽지는 않아보입니다.

그냥 가장 최근의 최적화까지는 반영되지 않았다고 보는게 타당할듯.

 

5420, 5260, 5250 결과는 다 비슷합니다.

5250 결과가 좀 낮은데 클럭은 350MHz로 낮춰잡으면 2.6 정도로 맞춰집니다.

뒤에서 기린920 추정 클럭을 놓고 얘기하겠지만 결론만 말하면 맨해튼 클럭이 티렉스 클럭보다 낮을 가능성은 낮아보입니다.

그런 측면에서 5250 맨해튼 클럭은 350MHz 보기는 힘듭니다.

 

 

- 결론

원래 MP수 늘어나고 클럭 올라가면 비례해서 성능이 올라가지는 않는데 뭐 그런건 해결해서 냈겠지요.

 

	MP	Texel fillrate (MTex/s)	계산 클럭 (MHz)	T-Rex 클럭 (추정, MHz)	Manhattan 클럭 (추정, MHz)
5250	4	1429	357	400	400
5420	6	2189	365	420	420
5422 (기존)	6	2113	352	450 (유효클럭[각주:5])	450 (유효클럭[각주:6])
5422 (최근)	6	2551	425	480	480
5260	3	1213	404	500 (유효클럭)	500 (유효클럭)
Kirin920	4	1683	421	420	600

 

 

 

- 기린920 GPU 클럭

맨해튼 클럭이 43%(420->600), 낮게 잡아도 31%(420->550) 높습니다.

 

가능성1. 티렉스 테스트 결과가 클럭대비 낮게 나와서 클럭이 낮게 추정.

이게 가장 일반적인 해석입니다.

현재로는 이럴 가능성이 높고요.

 

가능성2. 같은 클럭 설정이면 티렉스보다 맨해튼에서 AP 전체 소비전력이 낮다.

화웨이가 제대로 된 클럭 셋팅을 했다면 티렉스든 맨해튼이든 CPU 클럭(=소비전력)은 동일할 겁니다.

기린920은 A15+A7 빅리틀이기때문에 GFX벤치 조건에서 절대적인 CPU 소비전력이 높지도 않을거고요.

그런데 티렉스 클럭과 맨해튼 클럭이 다르다는건 같은 클럭이라도 티렉스에서의 GPU 소비전력이 맨해튼에서의 소비전력보다 높다는게 됩니다.

 

정확한 자료는 아니지만 엑시노스5422 커널를 보면,^[각주:7]

28nm Mali-T628MP6이 420MHz에서 2.3W, 600MHz에서 3.81W 입니다.  (543MHz에서 3.45W)

MP6 전력이니 MP4 전력은 낮을텐데 단순히 2/3 하면 부정확합니다.

코어와 비코어 부분의 전력을 나눠서 계산해야하는데 그걸 정확히 모르니...

그래서 그냥 2/3 해버리면,

각각 420MHz 1.53W, 600MHz 2.54W, 543MHz 2.30W

2.54 -> 1.53 : -40%

2.30 -> 1.53 : -23%

아무리 차이가 나도 동클럭에서 이렇게 차이가 많을거라 보기 힘듭니다.

그리고 벤치마크 버전이 올라가면서 부하가 높아지는데 소비전력이 낮아진다는게 쉽게 납득가지도 않고요.

굳이 가능성을 생각한다면 프레임이 줄어들면서 인터커넥터에서 부하가 줄어들었을 가능성?

최신 API를 지원하고 프레임을 올리기위해 각종 최적화 기술이 적용되면서 비코어의 부하가 낮아졌을 가능성?

폴리곤 수가 늘어나면서 코어의 부하는 심해졌는데 코어의 성능이 부족하면서 비코어의 자원이 남아돌면서 결과적으로 비코어의 부하가 줄어들었을 가능성?

 

이 부분에 대해서는 좀 더 돌아가는 상황을 지켜보면서 검토가 필요할듯 합니다.

 

 

 

1. http://gamma0burst.tistory.com/743 [본문으로]
2. http://gamma0burst.tistory.com/743 [본문으로]
3. http://gamma0burst.tistory.com/743 [본문으로]
4. http://gamma0burst.tistory.com/743 [본문으로]
5. http://gamma0burst.tistory.com/743 [본문으로]
6. http://gamma0burst.tistory.com/743 [본문으로]
7. http://gamma0burst.tistory.com/717 [본문으로]