현재 위치

홈 ›› Forums ›› 재미 ›› 자유 게시판

64Bit CPU에 대해..

ezit의 이미지
글쓴이: ezit / 작성시간: 화, 2005/08/09 - 5:56오후

아... 64Bit CPU 있다는 사실을 오늘 알았다는게 아니고;

64비트 시피유란게

64비트의 크기의 레지스터를 갖고 있다는 거.. 맞죠?

그래서 __int64로 정수형 선언하면 2의 64승... 1800경까지의 정수를 나타낼 수 있게 되는 거잖아요..

근데 어디서 들은 예긴데

64비트 CPU에서는 기존의 32비트에선 램을 4GB까지 지원했던걸

16EB까지 지원한다고 들었었는데..

레지스터 크기랑 램 지원이랑 무슨 관련이 있는거죠??

그리고 또 질문이... 전 32비트 시피유인데 __int 64형을 써도 아무 문제가 없던데... 레지스터 크기가 32비트라 그 이상을 표현할 수 없어야 되는 거 아닌가요??

Forums: 
자유 게시판
chadr의 이미지

글쓴이: chadr / 작성시간: 화, 2005/08/09 - 6:05오후

우선 레지스터 크기랑 램 지원과의 관계를 간단히 말씀드리자면..

현재 만들어지고 있는 CPU는 PC(Program Counter)라는 레지스터를 이용하여
메모리에서 다음 실행할 명령어의 위치를 알아내도록 되어있는 구조입니다.
(PC는 CPU마다 다른 용어로 사용될수도 있습니다...)

즉.. 32비트 CPU는 이런 PC의 크기도 32비트이며.. 다른 여러가지 레지스터도 32비트입니다..(일반적으로 그렇습니다만 인텔 CPU에서는 특수한 용도의 레지스터로 64비트가 있다고 들었습니다.)

따라서 32비트의 PC를 가진 32비트 CPU에 최대로 접근 할 수 있는 메모리의 크기는 2^32바이트 만큼이 됩니다..

그리고 32비트 시피유에서 64비트 자료형을 써도 잘 되는 이유는..
32비트 시피유에서는 하드웨어적으로 64비트를 지원하지는 않습니다..

따라서 64비트 자료형은 컴파일러에 의해서 소프트웨어적으로 처리가 됩니다.. 그러므로 32비트 CPU에서 64비트 자료형을 처리 할려면 느립니다..

좀 더 자세한 사항은 마이크로프로세서 아키텍쳐나 CPU아키텍쳐에 관한 책을
읽어보시면 자세히 나와있을 것입니다. :)

-------------------------------------------------------------------------------
It's better to appear stupid and ask question than to be silent and remain stupid.

정태영의 이미지

글쓴이: 정태영 / 작성시간: 화, 2005/08/09 - 6:13오후

sucnzpa wrote:
레지스터 크기랑 램 지원이랑 무슨 관련이 있는거죠??

레지스터가 32개라면... 2^32 개만큼의 숫자밖에 표시할 수 없고... 표시할 수 있는 숫자만큼의 메모리 address 밖에 접근을 못하겠죠 ;)

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

bus710의 이미지

글쓴이: bus710 / 작성시간: 화, 2005/08/09 - 6:54오후

64bit CPU 가 전기를 덜 먹을까요?

특별히 전력 소모를 염두에 두고 어셈블리 명령 하나하나 신경써서 만들어진 arm 코어 같은 경우가 아니라

기존 32bit 와 64bit 간에 기능과 명령어 셋이 동일한 경우에 주변 장치에 접근하는 횟수가 줄어들긴 할텐데...

다만 인에이블과 인터럽트 시그널은 50%로 줄어들 가망성이 높겠지만... 버스로 데이터를 날리는 횟수는 줄어도 폭이 두배로 늘어서...

제 생각에는 5~10% 가량은 절전이 되지 않을까...하는 황당한 생각을 해봤습니다.

life is only one time

다크슈테펜의 이미지

글쓴이: 다크슈테펜 / 작성시간: 화, 2005/08/09 - 6:57오후

akudoku wrote:
64bit CPU 가 전기를 덜 먹을까요?

특별히 전력 소모를 염두에 두고 어셈블리 명령 하나하나 신경써서 만들어진 arm 코어 같은 경우가 아니라

기존 32bit 와 64bit 간에 기능과 명령어 셋이 동일한 경우에 주변 장치에 접근하는 횟수가 줄어들긴 할텐데...

다만 인에이블과 인터럽트 시그널은 50%로 줄어들 가망성이 높겠지만... 버스로 데이터를 날리는 횟수는 줄어도 폭이 두배로 늘어서...

제 생각에는 5~10% 가량은 절전이 되지 않을까...하는 황당한 생각을 해봤습니다.


어짜피 그때쯤 되면 다른 곳이 더 전기 먹지 않을 까요...?
우선 그래픽카드..지금은 한장짜리 두장연결한다고 엔비디아나 ATI경쟁하고 있죠..하드도 더 빨라질것이고 램도 용량이 늘어 날것이고 결론은 CPU는 전기세 덜 나갈지 모르겠지만 전체적인 전기세는 늘어 나겠지요..후다닥~~

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

lifthrasiir의 이미지

글쓴이: lifthrasiir / 작성시간: 화, 2005/08/09 - 9:35오후

chadr wrote:
따라서 64비트 자료형은 컴파일러에 의해서 소프트웨어적으로 처리가 됩니다.. 그러므로 32비트 CPU에서 64비트 자료형을 처리 할려면 느립니다..

항상 그렇지는 않습니다. 매우 대표적인 예로 최근(이라고 말하기도 좀 뻘쭘)의 x86 호환 프로세서들은 8개의 64비트짜리 mmx 레지스터를 가지고 있으며 mmx 명령을 통해서 이들을 빠르게 연산할 방법을 갖추고 있습니다. 3D 게임이 부드럽게 돌아 가는 게 그냥 그런 건 아니지요 :)

- 토끼군

bus710의 이미지

글쓴이: bus710 / 작성시간: 화, 2005/08/09 - 10:11오후

tokigun wrote:
항상 그렇지는 않습니다. 매우 대표적인 예로 최근(이라고 말하기도 좀 뻘쭘)의 x86 호환 프로세서들은 8개의 64비트짜리 mmx 레지스터를 가지고 있으며 mmx 명령을 통해서 이들을 빠르게 연산할 방법을 갖추고 있습니다. 3D 게임이 부드럽게 돌아 가는 게 그냥 그런 건 아니지요 :)

- 토끼군

오....!!

그렇군요. 어쩐지 빠르다했어~

life is only one time

Necromancer의 이미지

글쓴이: Necromancer / 작성시간: 화, 2005/08/09 - 10:47오후

x86의 경우는
범용레지스터 32bit
FPU레지스터(MMX겸용) - 80비트(MMX는 64비트까지만 사용)
SSE레지스터 - 128bit

- 이외에도 특수목적용 레지스터가 있는데 이것들은 크기가
여러가지입니다. 일례로 보호모드 프로그래밍에서
중요하게 이용되는 GDTR은 48비트입니다.

이렇게 됩니다.
x86 64비트는 여기에다 기존 범용레지스터가 64비트로 또
확대되고 여기에다 64비트 레지스터가 8개 새로
추가되죠. 범용레지스터가 8개에서 16개로 늘어나는
이점이 또 있습니다.

--

메모리 주소 제한은 주소 지정방식을 좀만 바꾸면
해결할 수도 있습니다. 32비트라고 해도 꼭 4G
제한만 있다고 볼 수는 없죠. 성능 저하를 좀
감수한다면 구조를 변경해서 4G 이상을 어드레스하는거 가능합니다.

과거 16비트 시절에는 레지스터 2개를 조합해서
20비트 주소공간을 썼었죠. 32비트 머신에서도
구조를 조금만 손보면 32비트 이상의 주소를 어드레스
하는거 얼마든지 가능합니다. 특히나 x86은 세그먼트라는
프로그램 블럭을 지정하기 위한 전용 레지스터들이
이미 여러개 구비되어 있기 때문에 더 쉽습니다.
하지만 32비트 범위를 초과하는 크기의 데이터(4G이상)는
한번에 다룰 수가 없기 때문에 여기에서 발생하는 오버헤드와 속도
저하는 피할 수가 없죠. 여기에서 64비트의 이점이 나오는거죠.

Written By the Black Knight of Destruction

chadr의 이미지

글쓴이: chadr / 작성시간: 수, 2005/08/10 - 12:29오후

tokigun wrote:
chadr wrote:
따라서 64비트 자료형은 컴파일러에 의해서 소프트웨어적으로 처리가 됩니다.. 그러므로 32비트 CPU에서 64비트 자료형을 처리 할려면 느립니다..

항상 그렇지는 않습니다. 매우 대표적인 예로 최근(이라고 말하기도 좀 뻘쭘)의 x86 호환 프로세서들은 8개의 64비트짜리 mmx 레지스터를 가지고 있으며 mmx 명령을 통해서 이들을 빠르게 연산할 방법을 갖추고 있습니다. 3D 게임이 부드럽게 돌아 가는 게 그냥 그런 건 아니지요 :)

- 토끼군

음.. 딴지는 아니고.. 3D게임이 부드럽게 돌아가는것과 64비트 레지스터와 무슨 관계가있나요?? 제가 3D 게임을 개발하고 있습니다만 64비트 자료형을 쓸일이 없었던것 같은데요..

ps. 그래픽 라이브러리 (DX or GL에서 내부적으로 사용하면 모르겠습니다..

-------------------------------------------------------------------------------
It's better to appear stupid and ask question than to be silent and remain stupid.

rainbird의 이미지

글쓴이: rainbird / 작성시간: 수, 2005/08/10 - 12:32오후

3D게임에 자주 사용되는 연산등에 특화되어있으면서 다룰 수 있는 자료형의 크기도 커지니까 당연히 조금더 빠른 속도를 보장 할 수 있겠죠.
특히, 멀티미디어 분야나 3D게임에서요.
하지만, 일반적인 C언어등으로 개발하면 MMX나 특정 레지스터를 사용하게 할 수 없지 않나요? 인라인 어셈등을 효율적으로 쓰시면 좀더 하드웨어 자원을 활용 할 수 있을텐데요 ^^

/ / / // // / /// / / / // // / // // // / / / ////// // /
/ / // // / /// / / / // // / // // // / / / /// // // / /
/ / // // / /// / / / // // / // // // / // //...rainbird

gongchoo의 이미지

글쓴이: gongchoo / 작성시간: 수, 2005/08/10 - 1:06오후

chadr wrote:
tokigun wrote:
chadr wrote:
따라서 64비트 자료형은 컴파일러에 의해서 소프트웨어적으로 처리가 됩니다.. 그러므로 32비트 CPU에서 64비트 자료형을 처리 할려면 느립니다..

항상 그렇지는 않습니다. 매우 대표적인 예로 최근(이라고 말하기도 좀 뻘쭘)의 x86 호환 프로세서들은 8개의 64비트짜리 mmx 레지스터를 가지고 있으며 mmx 명령을 통해서 이들을 빠르게 연산할 방법을 갖추고 있습니다. 3D 게임이 부드럽게 돌아 가는 게 그냥 그런 건 아니지요 :)

- 토끼군

음.. 딴지는 아니고.. 3D게임이 부드럽게 돌아가는것과 64비트 레지스터와 무슨 관계가있나요?? 제가 3D 게임을 개발하고 있습니다만 64비트 자료형을 쓸일이 없었던것 같은데요..

ps. 그래픽 라이브러리 (DX or GL에서 내부적으로 사용하면 모르겠습니다..

대표적으로 MMX 명령셋이나 SSE,SSE2,SSE3 명령셋은 행렬 연산에 많은 도움이 됩니다. 기타 구형 GPU가 지원해주지 않는 기능들을 구현하는데 많이 사용됩니다.

그리고... double형도 64bit 자료형입니...쿨럭...

-----------------------
좋은거 함 만들어보자...^^

codebank의 이미지

글쓴이: codebank / 작성시간: 수, 2005/08/10 - 1:17오후

chadr wrote:
ps. 그래픽 라이브러리 (DX or GL에서 내부적으로 사용하면 모르겠습니다..

제가 알기론 GL이나 DX내부에서 사용하기 때문이라고 알고 있습니다.
OpenGL이나 DirectX가 버젼업을하고 그래픽카드들이 ...지원 이라는것을
내세우는 이유가 그런 이유겠죠.

------------------------------
좋은 하루 되세요.

lifthrasiir의 이미지

글쓴이: lifthrasiir / 작성시간: 수, 2005/08/10 - 2:31오후

chadr wrote:
tokigun wrote:
chadr wrote:
따라서 64비트 자료형은 컴파일러에 의해서 소프트웨어적으로 처리가 됩니다.. 그러므로 32비트 CPU에서 64비트 자료형을 처리 할려면 느립니다..

항상 그렇지는 않습니다. 매우 대표적인 예로 최근(이라고 말하기도 좀 뻘쭘)의 x86 호환 프로세서들은 8개의 64비트짜리 mmx 레지스터를 가지고 있으며 mmx 명령을 통해서 이들을 빠르게 연산할 방법을 갖추고 있습니다. 3D 게임이 부드럽게 돌아 가는 게 그냥 그런 건 아니지요 :)

- 토끼군

음.. 딴지는 아니고.. 3D게임이 부드럽게 돌아가는것과 64비트 레지스터와 무슨 관계가있나요?? 제가 3D 게임을 개발하고 있습니다만 64비트 자료형을 쓸일이 없었던것 같은데요..

ps. 그래픽 라이브러리 (DX or GL에서 내부적으로 사용하면 모르겠습니다..

3D 게임 같은 경우 MMX 명령어 등등이 행렬 연산에 상당한 도움이 됩니다. 보통 이런 것들은 라이브러리 수준이라서 잘 눈에 띄이는 건 아닌데, 외부적으로도 퍼포먼스를 높이기 위해서 쓰는 경우도 있습니다. 그나저나 FPU도 80비트 레지스터를 쓰죠. 에구 그 생각을 못 했네 -,.-

- 토끼군

s4bz의 이미지

글쓴이: s4bz / 작성시간: 수, 2005/08/10 - 4:59오후

sucnzpa wrote:
아... 64Bit CPU 있다는 사실을 오늘 알았다는게 아니고;

64비트 시피유란게

64비트의 크기의 레지스터를 갖고 있다는 거.. 맞죠?


정확하게 말하면 64bit 크기의 레지스터를 가지고 있다는것 보단

한번에 처리할수 있는 데이터가 64bit라는게 맞겠죠??^^

sucnzpa wrote:
그래서 __int64로 정수형 선언하면 2의 64승... 1800경까지의 정수를 나타낼 수 있게 되는 거잖아요..

근데 어디서 들은 예긴데

64비트 CPU에서는 기존의 32비트에선 램을 4GB까지 지원했던걸

16EB까지 지원한다고 들었었는데..

레지스터 크기랑 램 지원이랑 무슨 관련이 있는거죠??

메모리 주소도 일종의 데이터입니다..

32bit의 메모리 주소밖에 처리를 못하는 cpu는

2의 32승인 4G 밖에 사용하지 못하는것 입니다.

sucnzpa wrote:

그리고 또 질문이... 전 32비트 시피유인데 __int 64형을 써도 아무 문제가 없던데... 레지스터 크기가 32비트라 그 이상을 표현할 수 없어야 되는 거 아닌가요??

이건 확실하지는 않지만..

제가 알기로는 느리지만 소프트웨어적으로 해결을 하는것으로 알고있습니다...

이상으로 허접 답변이었습니다..^^;

아~~

s4bz의 이미지

글쓴이: s4bz / 작성시간: 수, 2005/08/10 - 5:03오후

chadr wrote:
tokigun wrote:
chadr wrote:
따라서 64비트 자료형은 컴파일러에 의해서 소프트웨어적으로 처리가 됩니다.. 그러므로 32비트 CPU에서 64비트 자료형을 처리 할려면 느립니다..

항상 그렇지는 않습니다. 매우 대표적인 예로 최근(이라고 말하기도 좀 뻘쭘)의 x86 호환 프로세서들은 8개의 64비트짜리 mmx 레지스터를 가지고 있으며 mmx 명령을 통해서 이들을 빠르게 연산할 방법을 갖추고 있습니다. 3D 게임이 부드럽게 돌아 가는 게 그냥 그런 건 아니지요 :)

- 토끼군

음.. 딴지는 아니고.. 3D게임이 부드럽게 돌아가는것과 64비트 레지스터와 무슨 관계가있나요?? 제가 3D 게임을 개발하고 있습니다만 64비트 자료형을 쓸일이 없었던것 같은데요..

ps. 그래픽 라이브러리 (DX or GL에서 내부적으로 사용하면 모르겠습니다..

3D에 대해서 잘은 모르지만..

소수점에서 3d계산시 64bit가 필요하지 않나요??

딴지는 아닙니다..보통 3D개발하시는 분들이 정수는 32bit로도 충분하지만,

정밀하게 표현하고자 할때 소수점에서 어느정도 한계가 있다고들 하셔서..^^;;

아~~

죠커의 이미지

글쓴이: 죠커 / 작성시간: 수, 2005/08/10 - 6:51오후

펜티엄 4만 해도 4GB 제한은 CPU 탓으로 보긴 힘듭니다. (인텔 펜티엄 4 메뉴얼을 참고하십시요.)

CPU가 제공하는 어드레스 라인은 더 이상의 메모리를 지원하기 충분하고 데이터 형이 32비트라고 하더라도 그 이상의 메모리를 사용하는 것은 가능합니다.

- 죠커's blog / HanIRC:#CN

lifthrasiir의 이미지

글쓴이: lifthrasiir / 작성시간: 수, 2005/08/10 - 7:34오후

s4bz wrote:
sucnzpa wrote:

그리고 또 질문이... 전 32비트 시피유인데 __int 64형을 써도 아무 문제가 없던데... 레지스터 크기가 32비트라 그 이상을 표현할 수 없어야 되는 거 아닌가요??

이건 확실하지는 않지만..

제가 알기로는 느리지만 소프트웨어적으로 해결을 하는것으로 알고있습니다...

위에서 얘기가 많이 나왔듯이, 현재의 cpu들은 64비트 자료형도 별 무리 없이 처리합니다. 옛날 286 시절에는 컴파일러에서 부동 소숫점 연산을 emulation하는 옵션을 제공했지만(80387 쓸 거냐 에뮬레이션 할 거냐 이렇게...) 지금은 FPU가 다 해 먹는 거랑 마찬가지입니다.

- 토끼군

purewell의 이미지

글쓴이: purewell / 작성시간: 수, 2005/08/10 - 8:19오후

s4bz wrote:
chadr wrote:
tokigun wrote:
chadr wrote:
따라서 64비트 자료형은 컴파일러에 의해서 소프트웨어적으로 처리가 됩니다.. 그러므로 32비트 CPU에서 64비트 자료형을 처리 할려면 느립니다..

항상 그렇지는 않습니다. 매우 대표적인 예로 최근(이라고 말하기도 좀 뻘쭘)의 x86 호환 프로세서들은 8개의 64비트짜리 mmx 레지스터를 가지고 있으며 mmx 명령을 통해서 이들을 빠르게 연산할 방법을 갖추고 있습니다. 3D 게임이 부드럽게 돌아 가는 게 그냥 그런 건 아니지요 :)

- 토끼군

음.. 딴지는 아니고.. 3D게임이 부드럽게 돌아가는것과 64비트 레지스터와 무슨 관계가있나요?? 제가 3D 게임을 개발하고 있습니다만 64비트 자료형을 쓸일이 없었던것 같은데요..

ps. 그래픽 라이브러리 (DX or GL에서 내부적으로 사용하면 모르겠습니다..

3D에 대해서 잘은 모르지만..

소수점에서 3d계산시 64bit가 필요하지 않나요??

딴지는 아닙니다..보통 3D개발하시는 분들이 정수는 32bit로도 충분하지만,

정밀하게 표현하고자 할때 소수점에서 어느정도 한계가 있다고들 하셔서..^^;;

게임은 ㅡ_-)b 눈속임입니다.
64비트 정밀도 계산을 할 수는 있습니다.
그러나 안 그러죠.

비트와는 조금 다른 얘기지만
3D게임에서 cos/sin/tan 값을 각각 함수로 계산해서 쓰는게 아니라,
미리 약 5-10도 정도로 배열을 이용해 계산이 완료된 참조 테이블을
만들어놓고 씁니다.

정밀도를 위해서는 ㅡ_-) 그때그때마다 실수값 넣어서 때려야겠지만
일반적인 3D 게임은 그럴 필요가 없거든요.

대충 대충 눈에 보이기에 큰 오류(오차)가 없다면 속도를 위해
정밀도를 희생합니다.

그냥 ㅡ_-)a 3D게임에서는 64bit 실수를 쓸 만큼
정밀도가 높은 계산을 요구하는 것은 드믈다는 것입니다.

_____________________________
언제나 맑고픈 샘이가...
http://purewell.biz

lifthrasiir의 이미지

글쓴이: lifthrasiir / 작성시간: 목, 2005/08/11 - 12:37오후

purewell wrote:
s4bz wrote:
chadr wrote:
tokigun wrote:
chadr wrote:
따라서 64비트 자료형은 컴파일러에 의해서 소프트웨어적으로 처리가 됩니다.. 그러므로 32비트 CPU에서 64비트 자료형을 처리 할려면 느립니다..

항상 그렇지는 않습니다. 매우 대표적인 예로 최근(이라고 말하기도 좀 뻘쭘)의 x86 호환 프로세서들은 8개의 64비트짜리 mmx 레지스터를 가지고 있으며 mmx 명령을 통해서 이들을 빠르게 연산할 방법을 갖추고 있습니다. 3D 게임이 부드럽게 돌아 가는 게 그냥 그런 건 아니지요 :)

- 토끼군

음.. 딴지는 아니고.. 3D게임이 부드럽게 돌아가는것과 64비트 레지스터와 무슨 관계가있나요?? 제가 3D 게임을 개발하고 있습니다만 64비트 자료형을 쓸일이 없었던것 같은데요..

ps. 그래픽 라이브러리 (DX or GL에서 내부적으로 사용하면 모르겠습니다..

3D에 대해서 잘은 모르지만..

소수점에서 3d계산시 64bit가 필요하지 않나요??

딴지는 아닙니다..보통 3D개발하시는 분들이 정수는 32bit로도 충분하지만,

정밀하게 표현하고자 할때 소수점에서 어느정도 한계가 있다고들 하셔서..^^;;

게임은 ㅡ_-)b 눈속임입니다.
64비트 정밀도 계산을 할 수는 있습니다.
그러나 안 그러죠.

비트와는 조금 다른 얘기지만
3D게임에서 cos/sin/tan 값을 각각 함수로 계산해서 쓰는게 아니라,
미리 약 5-10도 정도로 배열을 이용해 계산이 완료된 참조 테이블을
만들어놓고 씁니다.

정밀도를 위해서는 ㅡ_-) 그때그때마다 실수값 넣어서 때려야겠지만
일반적인 3D 게임은 그럴 필요가 없거든요.

대충 대충 눈에 보이기에 큰 오류(오차)가 없다면 속도를 위해
정밀도를 희생합니다.

그냥 ㅡ_-)a 3D게임에서는 64bit 실수를 쓸 만큼
정밀도가 높은 계산을 요구하는 것은 드믈다는 것입니다.

네 실제로 모든 곳이 그렇게 쓰지는 않지만, 그렇게 쓸 수도 있고 쓰는 곳도 있다는 얘기였습니다 :) 어디서는 별의별 값들을 다 테이블로 만들어 놓더군요. (sqrt라던지... 물론 모든 값을 저장하는 건 아닙니다)

- 토끼군

khris의 이미지

글쓴이: khris / 작성시간: 목, 2005/08/11 - 2:44오후

옛날에 속도가 느릴땐 오버레이나 닷지등의 이펙트도 테이블 만들어놓고 썼었습니다.
지금이야 CPU속도가 빨라서 실시간 연산 하지만... :)

───────────────────────
yaourt -S gothick elegant
khris'log

cronex의 이미지

글쓴이: cronex / 작성시간: 목, 2005/08/11 - 3:34오후

purewell wrote:

게임은 ㅡ_-)b 눈속임입니다.
64비트 정밀도 계산을 할 수는 있습니다.
그러나 안 그러죠.

비트와는 조금 다른 얘기지만
3D게임에서 cos/sin/tan 값을 각각 함수로 계산해서 쓰는게 아니라,
미리 약 5-10도 정도로 배열을 이용해 계산이 완료된 참조 테이블을
만들어놓고 씁니다.

정밀도를 위해서는 ㅡ_-) 그때그때마다 실수값 넣어서 때려야겠지만
일반적인 3D 게임은 그럴 필요가 없거든요.

대충 대충 눈에 보이기에 큰 오류(오차)가 없다면 속도를 위해
정밀도를 희생합니다.

그냥 ㅡ_-)a 3D게임에서는 64bit 실수를 쓸 만큼
정밀도가 높은 계산을 요구하는 것은 드믈다는 것입니다.


그게 그래픽 버그가 생기는 이유....이겠군요 -0-;;

------------------------------------------------------------
이 멍청이~! 나한테 이길 수 있다고 생각했었냐~?
광란의 귀공자 데코스 와이즈멜 님이라구~!

죠커의 이미지

글쓴이: 죠커 / 작성시간: 목, 2005/08/11 - 4:12오후

cronex wrote:
purewell wrote:

게임은 ㅡ_-)b 눈속임입니다.
64비트 정밀도 계산을 할 수는 있습니다.
그러나 안 그러죠.

비트와는 조금 다른 얘기지만
3D게임에서 cos/sin/tan 값을 각각 함수로 계산해서 쓰는게 아니라,
미리 약 5-10도 정도로 배열을 이용해 계산이 완료된 참조 테이블을
만들어놓고 씁니다.

정밀도를 위해서는 ㅡ_-) 그때그때마다 실수값 넣어서 때려야겠지만
일반적인 3D 게임은 그럴 필요가 없거든요.

대충 대충 눈에 보이기에 큰 오류(오차)가 없다면 속도를 위해
정밀도를 희생합니다.

그냥 ㅡ_-)a 3D게임에서는 64bit 실수를 쓸 만큼
정밀도가 높은 계산을 요구하는 것은 드믈다는 것입니다.


그게 그래픽 버그가 생기는 이유....이겠군요 -0-;;

그것과는 상관없습니다.

위에서 눈속임이라고 말하신 것 부분들은 사실 눈속임이 아닙니다. 연산을 최적화위한 일종의 hack이라고 보는게 맞겠지요.

실제 게임들에는 근거리는 3d, 장거리는 2d 이런식으로 어느 정도 눈속임이 들어갑니다. 사람들이 잘 인식 못하는 부분에 사기(?)를 치는 행위가 눈 속임이라고 봅니다.

그리고 이 부분이 몇년이 지난 후에 보면 굉장히 유치해 보이는 이유 중의 하나입니다. 스타워즈 에피소드 1의 레이싱 게임은 당시에는 굉장히 속도감있어 보이는 그래픽이었지만 지금 보면 정지해 있어도 물흘러가듯 번져있는 그래픽에 불과하지요.

- 죠커's blog / HanIRC:#CN

Prentice의 이미지

글쓴이: Prentice / 작성시간: 목, 2005/08/11 - 4:20오후

John Carmack이 했던 말 같은데, 여러 특수 효과들을 중첩해서 사용하다보면 32bit 연산으로는 한계가 있고 그 이상의 정밀도가 필요하다는 것 같았습니다.

그러나 CPU보다는 GPU와 가까운 얘기니 별 상관이 없네요..

khris의 이미지

글쓴이: khris / 작성시간: 목, 2005/08/11 - 10:06오후

cronex wrote:
그게 그래픽 버그가 생기는 이유....이겠군요 -0-;;

버그가 생기기도 합니다.

가령 캐릭터 애니메이션을 할때, 연산오류아닌 연산오류로 인해 본(뼈대)자체가 크게 엇나가거나 뒤틀리는 일이 발생합니다.

그것 역시 이리저리해서 손봐주죠. :wink:

───────────────────────
yaourt -S gothick elegant
khris'log

chamcham의 이미지

글쓴이: chamcham / 작성시간: 화, 2005/08/16 - 6:17오후

64비트 cpu -> 레지스터도 64비트이지만, 어드레스 버스 또한 64비트 입니다. 데이터 버스 역시 64비트..

단지 레지스터 크기만으로 설명한다면..

8086 같은 경우는 16비트 레지스터지만.. 주소 범위가 1메가 지원되지 않습니까..?

주소를 계산할땐 비록 4 + 16 해서 쓰지만.. 실제 살펴보면.. 8086 칩에서 주소 비트가 20비트입니다. 즉, cpu에 주소선이 20개 입니다. a0 ~ a19 ...

즉, 사용가능한 메모리 전체 크기는 주소선으로 결정됩니다.
일반 학교에서 배우는 컴퓨터 구조론 책에 자세히 나오는군요..

둘러보기