방정식 개발 로그

글쓴이: 이대근 (ㄷㄱ)


VGA 성능 방정식이 잘 맞지 않는 부분이 생겨 이 부분을 수정하게 되었습니다.
아직까지 ATI 그래픽카드 쪽에선 계산상 큰 문제가 없었는데
메모리 대역폭이 512bit, 448bit, 256bit, 320bit, 384bit 뭐 이렇게 희한하게 변화하는 NVIDIA 그래픽카드 쪽에선
메모리 대역폭-ROP-SP-TMU 이런 각 요소들의 가중치가 실제와 달라 계산이 잘 맞아 떨어지지 않더군요.

대표적으로 280 vs 275의 경우라든지 480 vs 570의 경우...
사소한 차이지만 이들 사이에서 성능의 역전현상이 일어나는 걸 제대로 캐치하지 못하는 문제가 있습니다.
아마 현행 방정식 모델이 메모리 대역폭의 영향력을 너무 과대평가하고 있는 게 아닌가 싶습니다.
(실제로는 메모리 대역폭이 적지만 클럭이 높은 275, 570쪽이 280, 480보다 성능이 좋았지만-
제 방정식 모델에서는 메모리 대역폭이 발목을 잡아 275, 570보다 280, 480의 성능이 더 좋게 나옵니다)

큰 틀에서 SP / TMU / ROP / 메모리 대역폭 - 이 4 요소는 건드리지 않고
각 요소의 가중치를 재조정해 좀 더 실제 성능관계와 가까운 결과값을 낼 수 있도록 해야겠습니다.


+ 프로젝트 추가!

현재의 방정식은 각 회사별로 SP갯수를 따지는 아키텍처가 다른 등의 이유로
각 회사별 방정식이 따로 있었습니다.
따라서 5850과 460의 성능 비교라든지... 이런 식의 서로 다른 회사 VGA간의 직접 성능비교는 불가능했는데
사실 많은 분들이 궁금하신 건 460과 285의 성능 비교, 이런것보단 ATI vs NVIDIA 이런 거잖아요~ ㅋㅋ

(그동안 6970이 580보다 느리다, 이렇게 확실한 비교를 못하고
5870과 5970의 사이일 것이다... 이런 애매한 예측밖에 못 한 이유이기도 합니다.
결과적으로 정확한 예측이긴 했지만 ㅋㅋ)

그래서...

차기 버전에서는 SP 갯수나 TMU 갯수같은 외견상의 스펙이 아니라
픽셀 필레이트, 텍스처 필레이트 같은 값을 직접 입력받도록 할까 구상도 해봤습니다 -_-
(하지만 이 경우 유저들이 엑셀파일을 받아가더라도 그래픽카드 성능을 계산해보기 쉽지 않다는 문제가;;;)


암튼 향후 계획을 요약하면

1. 구성요소별 가중치 재조정
2. ATI / NVIDIA 방정식 통합

두가지쯤 되겠군요.ㅋㅋ


//


방정식 개발 로그를 적어둘까 하는데 -_-; 과연 호응이 있을지.ㅋㅋㅋ

일단 간략히 리뷰하자면-

1. GPU 내부에서 일어나는 연산을 세 단계로 구분했습니다.
     (1) 쉐이더 연산 - 오브젝트의 모양을 형성합니다. SP 갯수 x SP 클럭에 비례
     (2) 텍스처 매핑 - 쉐이더에 질감을 입힙니다. TMU 갯수 x 코어클럭에 비례
     (3) 래스터라이징 / 렌더링 - 만들어진 3D 오브젝트들을 2D화 & 모니터에 그려냅니다.
          ROP 갯수 x 코어클럭에 비례

2. GPU 내부의 각 단계에서 발생하는 레이턴시는 코어클럭에 반비례한다고 가정했습니다.

3. GPU 외부에서 발생하는 레이턴시(데이터 전송, 그냥 잉여시간 등)는 대역폭에 반비례한다고 가정했습니다.
     (메모리 대역폭은 메모리클럭 x 메모리 비트수에 비례)

즉 위의 다섯개 항(쉐이더, 텍스처, 렌더링, 코어 내부 레이턴시, 코어 외부 레이턴시)이 방정식을 구성하는데
현재 메모리 대역폭의 과대평가 문제를 해결하기 위해 구상 중인 아이디어 한가지는 이겁니다:
-> 코어 외부 레이턴시 항을 두개로 쪼개, 메모리 접근 레이턴시와 데이터 전송 레이턴시로 구분하는 겁니다.
이 경우 데이터 전송 레이턴시는 기존처럼 메모리 대역폭에 반비례하게 되고 (메모리 비트수와 유관)
메모리 접근 레이턴시는 메모리클럭에만 관계하는 새로운 항이 됩니다. (메모리 비트수와는 무관)
즉 기존의 방정식 모델보다 메모리 비트수가 관여하는 영향력이 상대적으로 줄어드는 것이죠.

......

음....
더 자세한 얘기는 나중에.ㅋㅋ


//


메모리 접근 레이턴시와 데이터 전송 레이턴시를 시뮬레이션 해본 결과 이 둘을 구별하는 게 의미가 없더군요.
(데이터 전송에 걸리는 시간이 압도적으로 길었습니다)

그렇다면 메모리 쪽의 과대평가를 해결하기 위해 상대적으로 다른 요소의 가중치를 늘려야 하는데
코어클럭이 높은 275 / 570이 280 / 480에 비해 우위에 설 조건을 만들어주려면 코어클럭이 직접 영향을 미치는
코어 내부 레이턴시의 비중을 늘리거나, 코어클럭에만 관여하는 별도의 항을 만들어야 할 것 같습니다.
(물론 명목상으론 두개의 항이 되겠지만 실제 계산시엔 동류항으로 합쳐지겠죠. 같은 변수를 공유하니...)

GPU의 연산도 CPU와 마찬가지로, 프론트엔드의 페치/디코드 과정 이후에 백엔드에서 각 연산을 수행하므로
프론트엔드에서의 연산시간 명목으로 코어클럭에만 비례하는 새로운 항을 추가하는 게 대안이 될 듯 합니다.


//


코어클럭에만 비례하는 항을 추가했더니 듀얼 GPU 구성의 성능이 제대로 캐치되지 못하는 결점이 보였습니다.
(대개 듀얼 GPU라 해도 GPU클럭은 싱글 GPU 카드와 비슷한 수준이기에...)
듀얼 GPU 구성시 프론트엔드의 연산시간도 반으로 줄도록 계산하는 것이 합리적인데
그러기 위해선 GPU 갯수를 별도로 입력받아 '프론트엔드 연산성능'항에 넣어줘야 할 것 같습니다.