little hawk

littlehawk.egloos.com

포토로그 마이가든



이렇게된 이유가 뭘까? life


질문자 한마디에서 가볍게 웃고 가자

찰리님 강림ㅋ

GF104/GTX460 has a huge die

Economics of a failed architecture

by Charlie Demerjian

July 21, 2010

Nvdia world iconWHEN WE SAID that Nvidia's Fermi architecture was wrong, most people didn't understand what we meant, they focused on the chips. With the release of the GTX460, one look at the die size puts the problem clearly into focus, and it is quite ugly for Nvidia.

If you recall, we were the first ones to say that the GF100 was huge, 529mm^2, months before anyone else had hard data. This was backed up 8 months later by some pictures on EXPreview. We can now tell you about GF104 die, it is 24.9mm x 14.7mm, and the die size is 367mm^2. (Note: The dimensions are rounded to one significant digit after the decimal point, they are a hair larger so multiplying those rounded numbers gets you 366mm^2. This is not an error, the 367 number is correct, some mad scientists directly measured the die.) For some odd reason, Nvidia didn't give out any die size numbers when talking to the press, almost like they didn't want people to know something before the reviews went up.

The closest site to publish an accurate number was the TechReport with 320mm^2. For that, Scott Wasson wins the mostly-not-crushed-much individually wrapped Kit-Kat stick that wound up in my travel bag after Computex. Congratulations Mr. Wasson, see me at IDF for your prize. No one said that the GF104 was larger than it's closest rival, AMD's Cypress/HD58xx, and that is what Nvidia didn't want you to know.

The problem is simple for Nvidia, the economics of this part don't work out, the underlying architecture is wrong, so the resultant parts start out with an uphill battle. This is a problem for Nvidia, not for the end user. If the GTX460 is priced at a loss, the consumer shouldn't care, they get a deal, and that is the end of it. Retail buyers rarely care if the part is making a profit for the manufacturer.

Cypress/HD58xx is 334mm^2, which makes GF104 about 10% larger. If yields are the same for both parts, that would mean GF104 costs 10% or so more than Cypress to make. Sources in the fab community tell SemiAccurate that the GF104 is nowhere near the yield of Cypress.

As a humorous aside, both chips are made on the same process, TSMC's 40nm, and literally at the same fab. AMD managed to cram 2.15 billion transistors into 334mm^2, about 6.44 million transistors per mm^2. GF104 has 1.95 billion transistors in 367mm^2, about 5.31 million transistors per mm^2. This means AMD's Evergreen architecture is over 20% more space efficient than GF104 while delivering much more raw performance and vastly more performance per watt. When SemiAccurate teases Nvidia's layout and physical design teams, it is for a reason.

Getting back to the story, to use ballpark figures, lets assume Cypress is now yielding at 75% for HD5870 and HD5850 combined, much higher if you add in HD5830. GF104 has one of it's seven shader groups fused off leaving 336 functional shaders, and upping yields. Lets just ballpark that chip's yield at 60% for reasons we can't get into. If Nvidia decides to release more GF104 derivatives, it will up the effective yield, but anything lower on the performance scale would go up against Juniper, a 166mm^2 chip. That is economic suicide.

This means you can get about 150 GF104 die candidates per 300mm wafer, at 60% yields, that is about 90 good parts. Cypress has about 160 candidates, and about 75% yields, meaning 120 good parts per wafer. You can play with the number as much as you like, see what David Morgan did here for example, but the fact that Cypress is smaller and has notably higher yields is the take home message.

If a TSMC 40nm wafer costs $5000, that means each good 5850 or 5870 costs AMD about $42 to make. Each good GF104 costs Nvidia around $56. If you add in 5830s the number goes down for ATI, and the same holds true for any GF104 derivative that Nvidia releases. This is a problem for reasons we will get into later, but not the end of the world for Nvidia.

The Cypress based HD5870 and HD5850 cards seem to be selling for about $380 and $300 at etail respectively while the GF104 based GTX460 sells for $199 and $229 with 768MB and 1GB of memory. If you assume that the card models are split 50-50 for supply, that means AMD cards sell for an average of $340 while Nvidia cards sell for $215 on average. The two Nvidia cards straddle the lowest end Cypress variant, the HD5830, in the market, and are well below the price and performance of the HD5850.

Getting back to the GPU prices, you might recall that Nvidia's silicon component costs about 25% more than AMD's, and the resultant card sells for about 63% of AMD's card sells for. Can you say squeezed margins, if they exist at all? ATI can lop $100 off their retail price and still make more money on Cypress than Nvidia currently makes on GF104.

Nvidia's will make some money on GF104 only as long as AMD feels like letting them. Because TSMC can't make enough 40nm wafers to go around, Cypress is currently supply constrained. Should GF104/GTX460 eat into AMD's marketshare enough to effectively allow Cypress demand to be met by current wafer availability, AMD will drop prices and likely push Nvidia into the red on GF104. It isn't a question of "Can AMD?", it is a question of "Will they?".

If you add in the low end HD5830 card, the numbers get better for AMD. ASPs go down, but so does cost because effective yield goes up. If Nvidia puts out a lower spec GF104 with 6 of the 8 clusters active, they will push yields up, but also push ASPs down a lot. That low end card would be competing with AMD's Juniper, a 166mm^2 part that costs far less than half of what Cypress costs to make. Once again, Nvidia is bringing a knife to a gunfight because their architecture is fundamentally broken.

If Nvidia puts out a higher spec GF104 with all 8 clusters active, they have the ability to raise ASPs, but yields will take a huge pounding, as will supply. This may be good for polishing the halo for the gullible onlookers, but it is doubtful it would help their financial situation much.

In the end, the GF104/GTX460 is a good card for consumers, it is priced right, and slots into a gaping hole in the AMD lineup. That hole exists because it is better for AMD's bottom line for it to be there. Nvidia poked a sleeping lion with the GTX460, and if it decides to roll over and swat the green team they have no defense.

To make matters worse, the Fermi architecture is not just wrong, it was also quarters late. About the time that Nvidia fleshes out the GF10x line with the upcoming GF106 and GF108 variants, AMD will have their next generation called Southern Islands out.

That will let AMD waterfall the prices on the current parts, and leave Nvidia without any place to turn, financially speaking. Best case, Nvidia has a window of a few months before AMD brings down the hammer. In the mean time, the boys in green have to be very careful, poking the sleeping lion might bring that hammer down faster. No matter which way they turn, Nvidia will get squished.S|A

Update: Clarified significant digits.

Discuss this in our forums

그래도 이번엔 다이크기당 성능으로밖에 깔게 없나보군 ㅋ




File under Microprocessors and Mobile and Graphics and Channel and Opinion and Rumors and Desktop and Efficiency and Gaming and Software and Finance



[펌][C/C++] 자료형 정리(문자열) software

출처 : http://www.nicklib.com/bbs/board.php?bo ··· page%3D3

1. C 자료형
char(1), short(2), int(4), long(4), float(4), double(8), bool
문자: char

2. Win32 API 자료형
BYTE(1, unsigned char), WORD(2, unsigned short), UINT(4, unsigned int)
DWORD(4, unsigned long), LONG(4,long), BOOL
문자: UCHAR(unsigned char)
Handle: 대상을 구분하는 4바이트 정수(HWND,HDC...)

MBCS문자(열) 유니코드문자(열) 자동매크로문자(열)
------------ ----------------- ------------------
char wchar_t TCHAR
LPSTR(char*) LPWSTR(wchar_t*) LPTSTR
LPCSTR(const char*) LPCWSTR(const wchar_t *) LPCTSTR

.LPTSTR과 LPCTSTR를 사용하는 것이 좋음.
.OLECHAR(wchar_t), LPOLESTR(LPWSTR), LPCOLESTR(LPCWSTR), OLESTR(x) = _T(x)
3. COM 스트링
BSTR : 문자열 길이를 시작전에 저장하고, 이어서 유티코드문자열을 저장하는 방식
LPCWSTR -> BSTR : 생성안됨. 생성함수를 이용해야 함.
BSTR bstr = sysAllocString(L"HELLO HI"); // 메모리 할당
sysFreeString(bstr); // 메모리 제거
VARIANT: 문자열이 들어올때 BSTR과 동일
4. CRT(c runtime library)지원 스트링 클래스 (#include "comdef.h")
4-1. _bstr_t
:BSTR 랩퍼 클래스, 메모리 할당/제거를 자동으로 수행

. LPCSTR, LPCWSTR -> _bstr_t
:_bstr bstr = "hello hi";
. _bstr_t -> LPCSTR, LPCWSTR
: LPCSTR psz1 = (LPCSTR)bs1;
. _bstr_t -> BSTR
: 형변환 안됨. 함수이용
BSTR bstr = bs1.copy();
sysFreeString(bstr); // BSTR은 사용후 메모리 해제를 해야함.
4-2. _variant_t
:VARIANT 랩퍼 클래스, 메모리 할당/제거 자동 수행

. LPCSTR, LPCWSTR -> _variant_t
: _variant_t v1 = "hello hi";
. _variant_t -> _bstr_t -> LPCSTR,LPCWSTR
: LPCSTR psz1 = (LPCSTR)(_bstr_t)v1;
5. ATL 지원 스트링클래스
5-1 CComBSTR : BSTR랩퍼클래스, 메모리할당/제거 자동 수행
. LPCSTR, LPCWSTR -> CComBSTR
CComBSTR bs1 = "hello hi";
. CComBSTR -> BSTR -> LPCWSTR
BSTR bs = (BSTR)bs1;
. BSTR -> CComBSTR
CComBSTR bs2; bs2.Attach(W2BSTR(L"hello hi");
5-2 CComVariant: VARIANT랩퍼클래스, 메모리할당/제거 자동 수행
. LPCSTR, LPCWSTR -> CComVariant
CComVariant bs1 = "hello hi";
. CComVariant -> CComBSTR -> BSTR -> LPCWSTR
CComBSTR bs = bs1.bstrVal;
6. STL 스트링
6-1 string
. LPCSTR -> string
string str = "hello hi";
. string -> LPCSTR (형변환 안됨. 함수 이용)
LPCSTR psz = str.c_str();
6-2 wstring
. LPCWSTR -> wstring
wstring str = "hello hi";
. wstring -> LPCWSTR
LPCWSTR psz = str.c_str();
7. MFC 스트링
. LPCSTR, LPCWSTR -> CString
CString str = "hello hi";
. CString -> LPCTSTR
1. LPCTSTR lpsz = (LPCTSTR)str;
2. LPTSTR lptsz = str.getBuffer(0), str.ReleaseBuffer(); (올바른 사용)
3. LPTSTR lptsz = (LPTSTR)(LPCTSTR)str; (잘못된 표현)
4. CString -> BSTR
BSTR bstr = str.AllocSysString(); sysFreeString(bstr);
8. VC7 스트링
String: .Net에서 새로 정의한 스트링 클래스
String* s1 = S"hello hi";
CString s2(s1);

9. ETC
1. BSTR --> LPCSTR
USES_CONVERSION;
LPCSTR lpaszTemp = OLE2CA(bstrValue);
2. LPCSTR --> BSTR
USES_CONVERSION;
BSTR bstrTemp = ::SysAllocString(A2COLE(lpaszValue));
3. CString --> LPCSTR
1) ANSI 버전
LPCSTR lpaszTemp = (LPCSTR) strValue;
2) UNICODE 버전
USES_CONVERSION;
LPCSTR lpaszTemp = T2CA((LPCTSTR) strValue);
4. LPCSTR --> CString
1) ANSI 버전
CString strTemp = lpaszValue;
2) UNICODE 버전
USES_CONVERSION;
CString strTemp = A2CT(lpaszValue);

windows 8 소식 software

Windows 7이 MS 역사상 가장 많이 팔리고 있는 가운데, Microsoft 가 개발 중인 코드 네임 Windows 8 에 대한 몇가지 정보가 MS 저널 블로그를 통해 공개되었습니다.

(Windows 8은 2011년 하반기 출시될 거라는 루머가 있습니다.)


공개된 정보에 의하면, "Windows 8 이 설치된 PC는 빠르게 켤 수 있고, 긴 로딩이나 딜레이 없이 작업할 준비가 되어 있다. e-메일 체크, 스포츠 스코어 확인, 미디어 플레이와 같은 작업들을 빠르게 수행할 수 있을 것"이라고 합니다.

또한, PC가 종료된 상태에서의 POST 퍼포먼스 향상, S3 대기모드 퍼포먼스 향상, 일반적인 성능 최적화에 포커스를 맞추었으며, 이러한 기능 향상들은 정지된 시스템를 곧바로 사용할 수 있도록 도와 줍니다.


그리고 Windows 8 이 블루투스 3.0, USB 3.0 툴을 도입하여 더욱 빠른 컴퓨팅이 가능할 것이고, 스마트 폰 하드웨어 센서에 대한 인식을 향상시켰으며, 변화하는 주위 밝기에 대한 인식 기술(ambient light)을 채택하여 어떠한 환경에서라도 디스플레이를 보기 쉽게 도와줄 것이라 합니다.


그밖에, 얼굴 인식을 통한 로그인이 가능할 것이고, 3D-디스플레이 Ready 버전의 DirectX 를 탑재할 예정이라고 합니다.



//아직 xp쓰는사람도 많을텐데 ...

PCI-Express 3.0 스펙 올 하반기 공개



 

 

다음 세대의 PCI-Express 개정은 하위 호환성을 지니지 않을 것이고, 최대 대역폭은 8GT/s에 달할 것이라고 합니다.

(PCIe 2.0은 5GT/s) 또한 Signaling과 데이타 무결성 신호 전달을 향상시킬 것이라고 합니다.

 

2010년 6월, PCI-SIG의 개발자 컨퍼런스가 열리는 산타 클라라에서 자세한 정보를 얻을 수 있을 것입니다.

최종 스펙이 이번 년도에 확정되면, 2011년에는 PCIe 3.0의 그래픽 카드와 이를 지원하는 메인보드가 출시 될 전망입니다.




언제나 느끼는거지만...pc는 대략 30~50만원대로 맞추는게 제일 현명하다.

대신 비교적 빨리 중고가로 치고 빼는게 중요...

저렇게 하면 어느정도의 고사양을 계속해서 유지할수 있는데

귀찮은게 문제...


1 2 3 4 5 6 7 8 9