Linuxdoc Sgml/3 Dfx-HOWTO
<!doctype linuxdoc system>
<article>
<title>3Dfx-HOWTO
<author>The Linux Bernd Kreimeier (<url url="mailto:bk@gamers.org" name="bk@gamers.org">)
<date>Version 1.18i of 28. February 1998
<trans>번역한 이: 김병인 (<url url="mailto:itchingbrain@hotmail.com" name="itchingbrain@hotmail.com">)
<abstract>
이 문서는 리눅스에서의 3Dfx그래픽 액셀러레이터 칩 지원을설명합니다.
지원되는 하드웨어 리스트와 (전부 나와있지는 않음) 드라이버를 어떻게
설정하는가, 그리고 FAQ가 들어 있습니다.
(역자주: 번역한 이가 리눅스 환경에 생소하기 때문에 간혹 실수나 잘못
번역된 부분이 있을 수도 있겠습니다. 그런 부분이 있으면 저에게 연락 해
주시면 감사하겠습니다.)
</abstract>
<toc>
<sect>들어가기
<P> 지금 보시는 이 글은 리눅스 3Dfx HOWTO 문서입니다. 이 문서의 목적은
리눅스에서 3Dfx 를 어떻게 설치하고 설정하는지에 도움이 되기위해 볼수
있는 작은 참고서 역할을 하는데 있습니다. 그리고, 3Dfx지원에 대해 많이
물어오는 질문들에 대한 설명이 들어있으며, 3D 컴퓨터/하드웨어
액셀러레이션에 관련된 여러가지 참고사항도 나와 있습니다.
이 문서의 사용은 인텔CPU 용 리눅스에만 해당됩니다. 특정부분은 다른
CPU에서도 참고를 할 수 있겠지만, 저자는 다른 CPU를 쓰는 컴퓨터에서
직접 테스트를 해 보지 못했습니다. 그리고, 이 문서는 3Dfx테크놀로지를
쓰는 그래픽카드에 대해서만 나와있고, 다른 칩셋에 관해서는 해당 문서를
참고하시기 바랍니다.
</p>
<sect1>이 글을 쓰는데 도와주신분과, 그분들 연락처
<p>
많은 분들이 이문서를 만드는데 커다란 도움을 주셨습니다. 특히 리눅스
글라이드 포트와 베타테스팅 작업, 메사와 메사 부두 드라이버 개발작업,
그리고 3Dfx와 Quantum3D를 참고해서 문서를 고치는데 많은 분들이 참여해
주셨습니다.
다음은 이 문서를 쓰는데 도와주신 분들입니다.
Daryll Strauss 씨 (이메일: <url url="mailto:daryll@harlot.rb.ca.us" name="itchingbrain@hotmail.com">)가 포트를
해주셨고, Paul J. Metzger (이메일: <url url="mailto:pjm@rbd.com" name="pjm@rbd.com">) 가 리눅스용 메사 부두>
드라이버(원래 프로그래머:David Bucciarelli tech.<url url="mailto:hmw@plus.it" name="hmw@plus.it">) 를
디버깅을 해주셨으며, Brian Paul씨 (이메일: <url url="mailto:brianp@RA.AVID.COM" name="brianp@RA.AVID.COM">)가
이 드라이버를 그 유명한 메사 라이브러리에 포함시켜 주셨습니다. Henri
Fousse, Gary McTaggart 는 부두 그래픽스(tm) 메사 프로그램에 기여를
해 주셨으며, DOS용 3Dfx 메사는 Charlie Wallace씨 (이메일:
Charlie.<url url="mailto:Wallace@unistudios.com" name="Wallace@unistudios.com">) 가 관리를 해 주셨습니다.
3Dfx에서 일하시는 분들, 특히 Gary Sanders, Rod Hughes, 그리고 Marty
Franz, 께서 이모저모로 중요한 조언을 해주셨습니다. Quantum3D는 Ross
Q.Smith 께서 많은 도움을 주셨습니다. 부두 익스트림, 그리고 오퍼레이션
3Dfx 홈페이지에는 자료가 좋은 참고가 되었으며, 3Dfx 로컬 뉴스그룹
에서도 도와주셨습니다.
리눅스 리눅스 글라이드와 메사를 사용하는 glQuake2포트는 Dave Kirsch
<url url="mailto:zoid@idsoftware.com" name="zoid@idsoftware.com">께서 관리를 하고 있습니다. 그리고, 이메일로
정정사항과 업데이트를 알려주신 분들께 감사드리며, 듀얼 케이블 셋업에
대해 일러주신 Mark Atkinson 께 특히 감사드립니다.
SGML 툴 팩키지(원래는 Linuxdoc-SGML이라 불렸음)를 사용해서 이 HOWTO
문서는 한 소스파일에서 만들어진 다양한 포맷으로 볼 수 있습니다. SGML
툴의 홈페이지는 <url url="http://www.pobox.com/~cg/sgmltools"> 입니다.
</P>
<sect1>OEM제품의 지원
<p>
작지만 점점 커가는 시장점유율을 보유하고 있음에도 불구하고 리눅스는
아직까지는 전문플랫폼으로서 널리 인정되지 않고 있습니다. 일반적인
하드웨어 3D액셀러레이션에 관해서는, OEM들이 자신들의 제품을 리눅스
환경에서 지원하는지 안하는지 구체적으로 설명하는 섹션을 포함하기로
했습니다.
아시다시피 3Dfx 리눅스 글라이드 포트를 지원하기위해 회사자원
(인원)을 투입하기로 했습니다. 그렇더라도 3Dfx에서는 아직 리눅스환경
만 다루는 서비스 요원이 없기 때문에 리눅스에서 3Dfx칩셋지원을 하는
공식적인 지원이 있다는 뜻은 아닙니다. 3Dfx는 특정 그래픽카드나
OEM제품지원에 대해서도 책임을 갖지 아니합니다.
Quantum3D는 공식적으로 리눅스를 지원한다고 발표했고, 이 회사는 이미
자회사 제품을 위한 리눅스용 소프트웨어를 개발하고 있는 중입니다.
다음은 부두 그래픽스(tm)용 글라이드 프로그램 제작, 그리고 베타
테스트를 위해 물심양면으로 여러 도움을 주신 OEM과 혹은 제품 보급원들
입니다.
Quantum3D와 Datapath (Quantum3D 제품), Micronics (Orchid 제품).
Hercules 는 부두 러쉬(tm)용 글라이드 프로그램 제작을 위해 도움을
주셨습니다.
다음은 구체적으로 어떠한 형태의 도움도 주지않기로 밝혔던 회사
입니다. - 다이아몬드 멀티미디아, 인터그래프
리눅스 환경에서 쓸 수 있는 부두2(tm)의 새 기능을 쓸 수 있게 할 수
있는 글라이드 프로그램, 혹은 메사 프로그램을 업그레이드/테스트 하고
있는 OEM은 아직까지는 없습니다.
</P>
<sect1>Acknowledgments
<p>
3Dfx, the 3Dfx Interactive logo, Voodoo Graphics (tm), 그리고
Voodoo Rush (tm) 는 3Dfx Interactive, Inc.의 등록상표입니다. Glide,
TexUS, Pixelfx 그리고 Texelfx 3Dfx Interactive, Inc.의 등록상표
입니다. OpenGL는 Silicon Graphics의 등록상표입니다. Obsidian은
Quantum3D의 등록상표입니다. 다른 제품이름은 소유권자의 등록상표이며,
여기에 이렇게 acknowledge 되었습니다.
</P>
<sect1>지금까지의 개정사항
<p>
버전 1.03
맨 처음 배포판 1997년 12월 7일 (on 12.07.1997.)
버전 1.16
두번째 배포판 1998년 6월 2일 (on 6.2.1998.)
버전 1.18i
현재버전 1998년 2월 28일 (28. February 1998.)
</p>
<sect2>지금까지의 문서개정판은 저자를 위한것이므로 번역을 하지
않았습니다.
<p>
Version 0.1i
First version; used for proof-reading purposes only.
Version 0.2i
Added Flash3D, added Orchid R3D to list of boards
known to work, minor fixes.
FAQ regarding grSstWinOpen() added, FAQ regarding
Glide demos with ATB. Trademark acknowdlegments.
Version 0.3i
Added Quantum3D statements about Linux support,
chipset definitions, Obsidian board. Added a
bit on Voodoo architecture.
Version 0.4i
Official Obsidian taxonomy from Ross Q. Smith.
Explanation on setuid from Daryll Strauss.
Comments on Voodoo GLUT by David Bucciarelli.
Version 0.5i
Upgraded to 2.3.1, added Intergraph Intense.
Version 1.0i
Fixed news.3dfx hierarchy, added bug report
group pointer, ready for release.
Version 1.01i
Corrections from Daryll, SST_DUALSCREEN, snapping
vertices, removed setuid/device/XAA discussion.
Version 1.02i
P5 added to requirements. Removed Banshee. No
Intergraph support. FAQ section overiew.
Version 1.03
Corrected typos, added Macintosh. Changed wording
on grSstOpen error - might be removed entirely.
Added a Mesa compilation problems section. More
trademarks from the Glide docs. TexUS. ATB doc
mentioned. Upp'ed to pending 2.4 release.
Version 1.10i
Internal revision, for long overdue update.
Removed some general accelerated 3D graphics
explanations. Stripped some vendor references,
as I am not going to keep track of that in
all detail. Added some Pixelfx, Texelfx,
SLI, AGP, and other 3Dfx specific technical
backgrounder. Removed the outdated commercial
Linux OpenGL details. Added some more URL's
of 3Dfx web and FTP site, ATB info, miniport
info. Added some details to the Rush support
issue (DirectDraw, SSST96). Added Mesa window
hack. Removed the deprecated mdw LDP URL.
LDP license link, copyright changed. Link to
Stingray FAQ. Added info@quantum3d. Added a
memory/board(s) configuration formula.
A few GGI changes, resolved SVGA duplicate.
Corrected GLUT version number.
Version 1.11i
Internal revision. Added www.opengl.org,
emphasized pointer to Gateway. Added Mark
Kilgard to beta mail alias. Added OpenGL
GameDev list and ListServ archive reference.
Hercules FAQ maintained by Kertis Henderson
(<url url="mailto:kertis@frozenwave.com" name="kertis@frozenwave.com">) confirmed. Added TMU
alias to Texelfx entry. FAQ on support for
multi TMU in current release. Added mention
of seperate VR/VG distributions to current
version FAQ. No mention of any upcoming Glide
revisions. Added Mesa/Glide combo portability,
and Charlie Wallace' DOS port. Moved X vs. AT3D
into the X11 section, added technical details
on problem to pacify those bitching, mentioned
XFree86 3.3.3.2. Added Dirk Hohndel to beta mail
alias. Added assembly remark to Alpha
port question. Added texture size entry.
Replaced max res. 1280x960 for SLI with 1024x768.
Added overclocking/cooling comments. Removed
outdated Mesa-2.3.x and Glide 2.3 specifics
like grSstWinOpen/grSstOpen. Added glQuake in
window remark. Removed outdated VoodooGLUT in
Mesa remark.
Installed SGML-Tools v1.0.3. Added some minimal
indexing for RedHat LDP compilation. Switched to
Linuxdoc96 for release, as the nidx element has
not been added to strict DTD, while idx has.
Invisible indices cannot be created prior to
ToC - bugger.
Formatting: run into the familiar problem with
LaTeX styles not updated properly, and a duplicate
url.sty in a different location. Manual removal
and copy. Run texconfig rehash, fixed read permit
on style files. Formatting runs.
The url attribute rendering screws up underscores
and tilde character. OPP (other people's problem).
Strange, a misspelled &3Dfx; entity slips through
validation?
Version 1.12i
Rephrased multitexture in Mesa remark. Clarified
the 1024x768 issue, ruled out 1280x960. Reworked
info file for linux-<url url="mailto:3dfx@gamers.org proposal" name="3dfx@gamers.org proposal">,
rephrased entry. Fixed Glide version 2.4.
ATB source hint, whatever it's worth. Fixed 3Dfx/
Quantum corporate entry. Added Linux Quake setuid,
an GL related bugs/workarounds from Dave Kirsch's
plan. Added LinuxQuake sites.
Version 1.13i
Added "Internal" marked section, moved revision
history out of comment. Have to take out <nidx>
indexing after submission to RedHat, because it
breaks HTML output. Added "Indexing" marked
section, might actually scatter some more indices
throughout the document that way. Memory speed
mentioned as overclocking issue, lot of typos
fixed there. Fixed outdated SGML-Tools URL. Mesa
2.6b5 (current) and 3.0 (upcoming) mentioned.
Made separate Mesa multitexturing entry. Also made
LinuxQuake multitexturing entry.
Version 1.14i
Added blatant plug to "supported hardware" section,
for Voodoo2 board loans and DEC Alpha. Reworded
Glide multitexture section a bit, added Mesa
single pass trilinear filtering. Added "as of 2.6b5"
to Mesa statements.
Version 1.15i
Upped Mesa to 2.6b6. Feedback from Daryll, Paul, and
Brian so far. Created a Contributors and Contacts
section following Paul's suggestion, included all
e-mails of those publicly visible (no 3Dfx/Quantum3D
mailto). Added single screen dual cable as proposed
by Mark Atkinson. Typos. Slightly reworded Quantum3D
entry added to How do boards differ. Added two cross
references to Mesa window hack. Added single board
Obsidian SB SLI, added resetting dual and single
board SLI reset problem. Glide 3.0 is publicly talked
about, thus added a remark to current version. Keep
linux-3dfx mailing list entry. Disclaimer with Mark
Kilgards SGI address, GLUT mailing list.
Version 1.16
Switched Internal to IGNORE, upped current version,
notified LDP.
Version 1.16r
Indexing added for Red Hat compilation, kindly
provided by "Edward C. Bailey" <<url url="mailto:ed@redhat.com" name="ed@redhat.com">>.
Version 1.17i
Renamed to 3Dfx-HOWTO to match LDP name, incorporated
indexing in my own source. Added dates of previous
releases. Some additions to LinuxQuake, made some
distinctions between Quake1 and Quake2. Added
qkHack Library pointer. Added John Carmack multiTMU
statement (omitted misleading memory controller part).
Mesa-3.0 and multitexture/trilinear. Remark on trilinear
vs. multitexture mutually exclusive with 2 TMU.
Added verbose Company and OEM support acknowledgement.
Also added "Which board should I buy?" statement.
Update on GLX section (ftp.sigkill.org). Added
clarifications to supported color depth section.
Performance with PPro/PII (MTRR). Linux and AGP,
AGP and V2. MMX and non-Intel CPU. Fixed the
invisible index tag rendering in SGML-Tools v-1.0.3
locally for HTML and GROFF. Edited Makefile.
Version 1.18i
Mailing list.
</P>
<sect1>이 문서의 업데이트
<p>
이 문서의 최신판은 다음 주소에서 찾을 수 있습니다.
<url url="http://www.gamers.org/dEngine/xf3D/"> 이 문서의 최신판은 정기적으로
comp.os.linux.answers newsgroup 에 개재될 것입니다. 최신판은 여기저기
anonymous ftp사이트에 업로드가 될 것이며,
<url url="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/"> 에도 개재가 될 것입니다.
CD-ROM 배포판에는 HOWTO 문서가 포함되어 있으며, 보통은 /usr/doc/
디렉토리에서 HOWTO문서를 찾아 볼 수 있습니다. HOWTO문서를 책으로
출판해 놓은것이 있는데, 프린트하기가 불편하면 이것을 구입해도 됩니다.
그리고, 이 문서를 번역해서 저에게 알려주시면 사이트 주소가 이 문서에
포함이 될 것입니다.
</P>
<sect1>문의사항과 제안<p>
지금 이 글을 읽고 계시는 독자께서 이 문서를 어떻게 사용하느냐에
따라 이 문서를 좀 더 가치있게 할 수 있습니다. 제안/정정/기타 코멘트가
있으면 <url url="mailto:bk@gamers.org" name="bk@gamers.org">에게로 이메일을 써주기 바랍니다. 이런 저런 제안
사항은 다음 개정판을 만들때 커다란 도움이 될겁니다. 이메일을 쓸때
제목란에 "HOWTO 3Dfx" 를 넣어서 내 procmail 이 알아서 정리 할 수
있게 해 주시면 감사하겠습니다. 버그를 찾아서 보고를 한다거나 질문이
있을때에는, 먼저 이 HOWTO문서를 처음부터 끝까지 읽은 다음에 발견한
문제에 대해 자세히 알려주시면 감사하겠습니다. 만약 이 문서를 CD-ROM
으로 출판하거나 상업용으로 출판을 할때에는 저에게도 한부 보내주셨으면
합니다. 저에게 이메일을 주시면 제 우편용 주소를 보내드리겠습니다.
그리고, 수익금의 일부를 리눅스 문서 프로젝트에게도 기증을 해 주시면
정말 고맙겠습니다. 문의사항은 리눅스 HOWTO 관리인 Greg Hankins
(이메일: <url url="mailto:gregh@sunsite.unc.edu" name="gregh@sunsite.unc.edu">)씨를 연락해 주십시오.
</P>
<sect1>이 문서의 배포에 관하여...
<p>
이 문서의 저작권은 Bernd Kreimeier에게 속합니다. Copyright (c)
1997, 1998 by Bernd Kreimeier. 이 문서는 <url url="http://sunsite.unc.edu/LDP/
COPYRIGHT.html" name="sunsite.unc.edu/LDP/COPYRIGHT.html"> 에 나와있는 LDP라이센스 규칙에 따라 배포가 될 수
있습니다. 이 HOWTO 문서는 무료이며, LDP라이센스 규칙이 따라 재 배포를
하거나 수정을 할 수 있습니다. 이 문서는 유익하게 사용되기를 바라면서
배포가 되었지만 상업적, 혹은 어떠한 목적으로도 사용될 수 있다는
"보장"은 없습니다. 자세한 사항은 LDP라이센스를 참조하시면 됩니다.
</P>
<sect>그래픽 액셀러레이터 테크놀로지
<sect1>기본사항
<p>
이 섹션에서는, 나중에 나오는 개념들을 이해하기 위해 컴퓨터 그래픽
액셀러레이터 테크놀로지의 개요를 간략하게 설명하겠습니다. 더 알고
싶거나 궁금한 점은 OpenGL에 관한 책을 참조해도 됩니다.
</P>
<sect1>하드웨어 설정
<p>
그래픽 액셀러레이터는 여러가지 형태가 있습니다. 기존의 2D혹은
비디오 액셀러레이션기능이 있는 VGA카드와 비디오 입출력을 주고 받을 수
있는 별도의 PCI카드 일 수도 있으며, VGA와 3D 가속을 한꺼번에 하는
하나의 카드 일 수도 있습니다. (그래픽 카드 하드웨어가 두장이 아닌
한장으로 통합이 되어있기 때문에 이게 좀 더 신형이지요.)
3Dfx 그래픽 카드중 부두 그래픽(tm)카드가 전자의 통합되지않은 구형
모델이라 할 수 있습니다. 여기에 관해서는 이 문서의 후반부에서
다루기로 하겠습니다. 어드레스 충돌이 없으면 3D액셀러레이터 하드웨어는
별 문제없이 본체에 꽂혀있을 수 있지만, 실제로 사용하기위해서는
드라이버가 필요합니다. 하지만 예외적으로 2D/3D액셀러레이터 통합카드
를 구동하기 위해서는 다른 방법을 사용해야 할 수도 있습니다.
</P>
<sect1>부두 그래픽(tm) 구조에 대하여...
<p>
보통, 그래픽카드의 속도는 텍스쳐 메모리와 프레임/색깊이 버퍼 액세스
속도때문에 저하가 될 때가 많습니다. 스크린의 한 픽셀을 나타내기 위해,
최소한 하나(가장 가까운것), 넷(bi-linear, 선이 두개라고 밖에
못하겠네...), 혹은 여덟개(tri-linear mipmapped, 선이 세개... 참고로,
linear는 보통 "직선의"를 뜻합니다.)의 텍스쳐메모리로 가는 읽기용
액세스와, 거기에 읽기/쓰기용 색깊이 버퍼에다가, 읽기/쓰기용 프레임
버퍼메모리가 필요합니다.
부두 그래픽(tm) 아키텍쳐는 두 렌더링 단계를 거치는 과정으로
텍스쳐메모리를 프레임/색깊이 버퍼메모리로부터 분리를 시킵니다. 이
과정에서 각각의 픽셀 유닛(Pixelfx)과 텍셀 유닛(텍스쳐 + 픽셀..?)은
별도의 전용 메모리를 할당받게됩니다. 이 방법은 제한적인 메모리
관리방법을 사용함으로써 양질의 fill rate 를 구현할 수 있게 해 줍니다.
제한적인 메모리 관리방법을 사용함으로써 사용되지 않은 버퍼메모리는
텍스쳐 캐쉬용으로 사용 할 수 없게 되는 결과를 낳습니다. 게다가, 부두
그래픽(tm) 은 두가지 텍스쳐 관리 유닛 (Texture Management or Texelfx
Units. TMU로 약자를 쓰겠습니다.) 를 사용 할 수 있으며, 부두 그래픽
(tm)카드를 두장을 스캔라인 인터리-빙(Scan-Line Interleaving, SLI)
이라는 메카니즘을 통해 동시에 사용 될 수도 있습니다. SLI는 각각의
Pixelfx 유닛이 번갈아가면서 스캔라인을 하나씩 스캔하는 방법입니다.
이 방법을 쓰면 각각의 Pixelfx 프레임 버퍼 메모리에 가는 밴드폭에
영향을 많이 미치지 않습니다.
<sect>3Dfx카드의 설치
<p>
3Dfx 액셀러레이터를 리눅스에서 사용하기 위한 셋업 단계는 다음과
같습니다.
<verb>
1. 액셀러레이터 카드를 설치한다.
2. 글라이드 배포판을 설치한다.
3. 컴파일과 애플리케이션을 링크 및 실행한다.
</verb>
이 섹션 3 은 이 3Dfx카드를 리눅스에서 설치하는 과정에 대해 자세히
풀어 쓴 것입니다.
</P>
<sect1>3Dfx 액셀러레이터 카드 설치하기
<p>
우선, 액셀러레이터 카드와 같이 따라온 매뉴얼을 참조하십시오.
매뉴얼이 별 도움이 안된다면 컴퓨터를 구입한 곳에서 설치를 해달라고
해도 됩니다. IRQ나 DMA 채널셋팅은 Plug&Pray (tm)이나 공장 기본
설치값으로 하는 것까지는 필요가 없겠다. 여기에 나와있는 애드온 보드는
메모리 매핑을 쓰는 디바이스이므로 IRQ를 쓰지 않는다. 이런 보드에서
생길 수 있는 문제라고는 다른 디바이스들과 같은 메모리영역을 사용하려
하는 충돌밖에 없다. 3Dfx는 칩만 제조를 할뿐 다른 그래픽 카드의
디자인/개발/판매와 전혀 관계가 없기때문에 3Dfx는 연락을 하더라도
뾰족한 도움을 얻을 수가 없겠습니다.
</P>
<sect2>하드웨어 설치시 문제가 일어나면...
<p>
하드웨어 설치와 메모리 매핑을 체크해 보십시다. 다음은 다이아몬드
스텔스-64와 다이아몬드 몬스터 3D를 설치해서 cat /proc/pci 라고 친
다음의 결과입니다.
<code>
Bus 0, device 12, function 0: VGA compatible controller: S3 Inc.
Vision 968 (rev 0). Medium devsel. IRQ 11. Non-prefetchable 32 bit
memory at 0xf4000000.
Bus 0, device 9, function 0: Multimedia video controller: Unknown
vendor Unknown device (rev 2). Vendor id=121a. Device id=1. Fast
devsel. Fast back-to-back capable. Prefetchable 32 bit memory at
0xfb000000.
</code>
cat /proc/cpuinfo /proc/meminfo 를 실행하면 있을지도 모르는
충돌원인을 발견하거나 버그 리포트를 하는데 도움이 되겠습니다.
최신 커널을 사용한다면 다음과 같은 부팅 메세지가 뜰 수 있습니다.
<code>
Jun 12 12:31:52 hal kernel: Warning : Unknown PCI device (121a:1).
Please read include/linux/pci.h
</code>
이 메세지는 무시를 해도 됩니다.
만약 설치된 비디오 카드가 남들이 안가지고 있는 특이한 모델이던지,
사용자가 스스로 내용을 고쳤다던지 하면 /usr/include/linux/pci.h 을
참고해서 <url url="mailto:inux-pcisupport@cao-vlsi.ibp.fr" name="inux-pcisupport@cao-vlsi.ibp.fr"> 에 필요하다고 생각되는
사항을 이메일로 보내면 되겠습니다. 리눅스 환경에서 그래픽카드를
사용하면서 문제가 생기면 DOS/Win9x, NT 지원서비스를 받아봅시다.
리눅스를 사용한다고 하면 별 도움이 되는 반응을 얻기가 힘듭니다.
개인적으로 다이아몬드社의 A/S 이메일 시스템을 사용해 본후 생각하건데,
DOS/Win9x, NT 이외의 운영체제를 사용하면서 서비스를 받기는 무리인 것
같습니다.
</P>
<sect2>커널 설정하기
<p>
PCI 지원이 된다면 별도의 커널설정은 필요가 없습니다. 커널에 관한
사항은 <url url="http://sunsite.unc.edu/mdw/HOWTO/Kernel-HOWTO.html" name="http://sunsite.unc.edu/mdw/HOWTO/Kernel-HOWTO.html">을 참조
하시기 바랍니다.
</P>
<sect2>디바이스 설정
<p>
아직까지는 사운드카드같은 드라이버와는 달리 (/dev/dsp 와 /dev/audio
를 참조해 주세요.) 그래픽 액셀러레이터 드라이버를 사용하기위해 별도로
디바이스를 설정할 필요는 없습니다. 왜냐! 액셀러레이터 드라이버는
시스템에 이미 있는 /dev/mem 를 사용하기 때문입니다. 이에 대한 단점은,
액셀러레이터 카드를 사용하려면 setuid 를 사용하거나 root 의 권한을
사용해야 한다는 것입니다.
</P>
<sect1>디스플레이 셋업
<p>
3Dfx카드를 모니터에 연결하는 것은 두가지 방법이 있습니다. 원래 쓰던
VGA카드에서 나오는 비디오 시그널을 액셀러레이터 카드에 보내서 그걸
모니터에 보내는 방법이 있고, 모니터를 두개를 동시에 쓰는 방법이
있습니다. 대충 도표를 그리자면,
<enum>
<item>싱글스크린 셋업.: VGA출력 -> 3Dfx카드 -> 모니터
<item>싱글스크린 듀얼케이블 셋업: VGA카드 -> 모니터 #1, 3Dfx 카드 ->
모니터 #1
<item>듀얼스크린 셋업: VGA카드 -> 모니터 #1, 3Dfx 카드 -> 모니터 #2
자세한 내용은 구입한 보드의 매뉴얼을 참조하시기 바랍니다. 위의
두가지 설정방법은 다이아몬드 몬스터 3D에서 테스트된 방법입니다.
</enum>
</P>
<sect2>싱글 스크린 셋업<p>: VGA출력 -> 3Dfx카드 -> 모니터
모니터 하나로 액셀러레이터 카드를 쓰면 액셀러레이터 카드가 잘
돌아가고 있는지 확인 할 수 있습니다. 비디오 시그널이 모니터로 가지
않는다면 액셀러레이터에 고장이 있는지 알아 볼수 있기 대문입니다.
염두해 둘것은, VGA의 비디오출력정보가 액셀러레이터 카드를 통해서
모니터로 어느정도의 화질저하는 감수해야 할 것입니다. 여러 군데서 한
리뷰를 보면 카드와 원래 따라온 케이블의 성능이 뒤떨어지기 때문에
화질저하가 일어날수도 있다고 합니다. 다이아몬드社의 몬스터3D가 바로
이런 경우입니다.
싱글스크린셋업에서 또 한가지 주의해야 할 사항이 있습니다.
예를들어, X11에서 640x480 해상도(3D가속을 사용하고 있을때 풀스크린이
이 해상도를 씀)를 쓰고있는 경우라도, 원래 쓰고있던 VGA모드에서
액셀러레이션 모드로 전환할때 모니터의 해상도와 refresh rate (초당
몇번씩 다시 그림을 모니터에 그려주나 하는 비율.)가 바뀐다는
것입니다.
게다가 X11에서는 실행되고있는 애플리케이션이 모든 키보드와 마우스
이벤트를 관리하는데, 액셀러레이션 모드로 바뀌면 해상도의 변화로
스크린 한 부분에 콘트롤(마우스 움직임이랄지 키보드랄지..)이 묶여버릴
수도 있습니다. 이 현상은 액셀러레이션 모드를 쓸때 더 자주 일어납니다.
이문제의 X11대신에 SVGA 콘솔을 사용하는 것으로 간단히 해결 될 수
있습니다. 싱글스크린셋업에서 VGA모드와 액셀러레이션 모드로 전환을 할
때에 이런식으로 하드웨어에서 문제가 발생 할 수 있습니다.
</P>
<sect2>싱글스크린 듀얼케이블 셋업
<p>: VGA카드 -> 모니터 #1, 3Dfx 카드
-> 모니터 #1
고급모니터중 몇 기종은 (예를들어 EIZO F-784-T) RGB, HSync, VSync용
5 BNC 커넥터와, 보통 사용되는 VGA 혹은 13W3 Sub-D VGA용 커넥터같은
커넥터를 하나씩 연결하게 해 줍니다. 대부분의 경우, 커넥터가 두개가
있는 모니터는 비디오신호 입력단자 선택이 모니터 앞면에 붙어있는
콘트롤을 사용해서 가능합니다. 그러므로 이런 종류의 모니터에서는
VGA-to-BNC케이블은 원래 있던 비디오 카드에 연결하고, VGA-to-13W3
Sub-D 케이블은 3Dfx에 연결하는 식으로 연결해서 사용하는 방법이 가능
합니다.
</P>
<sect2>듀얼스크린 셋업
<p>: 모니터 #1, 3Dfx 카드 -> 모니터 #2
정상적인 작동을 위해 액셀러레이터 카드는 VGA 카드로 부터의 입력이
필요하지 않습니다. VGA 출력정보를 액셀러레이터 카드로 보내서 모니터
출력이 나오게 하는 대신에 모니터 한대를 컴퓨터에 달아서 동시에 사용
하는 것도 가능합니다. 앞에 나온 방법들보다 투자를 더 해야 하기는
하지만, 이 방법을 사용하면 위에서도 언급했던 싱글스크린 셋업에서
일어나는 화질저하가 일어나지 않기 때문에 때문에 최상의 화질을 즐길 수
있습니다. 이 방법을 쓰면 X11화면과 액셀러레이터 화면을 동시에 보면서
개발작업과 디버깅 및 게임을 할 수 있습니다. 하지만 유저가
액셀러레이터 카드를 사용하고 있지 않을 때에는 액셀러레이터카드의
출력이 전혀 나오지 않기때문에 어떤 설정상황에서는 그래픽 어플리케이션
을 끝낼 때 마다 하드웨어에서 구동되는 스크린세이버가 실행 될 수
있습니다. 하지만 비디오출력 설정에서 다음의 코드를 집어넣어서 비디오
출력이 항상 켜 있도록 하면 이 문제는 해결이 됩니다.
<code>
setenv SST_DUALSCREEN 1
</code>
</P>
<sect1>글라이드(Glide) 설치하기
<p>
글라이드 드라이버와 라이브러리는 압축된 파일 하나로 배포됩니다.
tar와 gzip 을 사용해서 압축을 풀고 들어있는 README와 INSTALL 화일을
참조해서 설치를 합니다. 인스톨 스크립트를 읽어보고 그 스크립트를
실행합니다. 인스톨 스크립트는 모든 화일을 /usr/local/glide
/include,lib,bin 에 복사해 넣고 ld.conf 라는 화일에 글라이드가 설치된
디렉토리의 위치를 담습니다.
글라이드가 설치되는 위치와, ld.conf 세팅은 따로 떨어질 수 있는 사항
입니다. 만약 ld.conf 셋팅을 하지 않는다면 LD_LIBRARY_PATH 를 이용
할 수 있습니다. 만약 유저가 어플리케이션을 개발해서 컴파일하려면
컴파일을 할 때에 사용 할 수 있는 디렉토리에 헤더 화일을을 설치해야
합니다. 만약 위에나와있는 설치방법대신 다른 디렉토리에 설치를
원한다면, 모든 애플리케이션이 공유로 설정된 라이브러리를 런타임에
액세스 할 수 있도록 체크해 주십시오. 애플리케이션이 런타임에 이 공유
라이브러리를 액세스를 못한다면 다음과 같은 에러메세지가 뜰 것입니다.
<code>
can't load library 'libglide.so'
</code>
</P>
<sect2>디텍트 프로그램 쓰는 방법
<p>
글라이드 배포판에는 하드웨어를 자동으로 디텍트를 하는 바이너리
프로그램이 포함되어있습니다. 소스코드는 배포되지 않았습니다.
root로서 이 프로그램을 실행하면 다음과 같은 메세지를 볼 수 있습니다.
<code>
slot vendorId devId baseAddr0 command description
---- -------- ------ ---------- ------- -----------
00 0x8086 0x122d 0x00000000 0x0006 Intel:430FX (Triton)
07 0x8086 0x122e 0x00000000 0x0007 Intel:ISA bridge
09 0x121a 0x0001 0xfb000008 0x0002 3Dfx:video multimedia
adapter
10 0x1000 0x0001 0x0000e401 0x0007 ???:SCSI bus
controller
11 0x9004 0x8178 0x0000e001 0x0017 Adaptec:SCSI bus
controller
12 0x5333 0x88f0 0xf4000000 0x0083 S3:VGA-compatible
</code> display co
root의 권한이 없으면 다음과 같은 메세지가 뜨면서 프로그램이
멈춥니다. 이 메세지는 버그 리포트를 할 때에 요긴하게 쓰일 수
있습니다.
<code>
Permission denied: Failed to change I/O privilege. Are you root?
</code>
</P>
<sect2>테스트 프로그램 쓰는 방법
<p>
글라이드 배포판 안에는 테스트 프로그램들이 들어있는 디렉토리가
있습니다. 3Dfx가 이프로그램들의 저작권을 소유하고 있으며 유저는
3Dfx 칩셋이 있는 보드를 구입했을때만 이 프로그램을 사용할 수 있는
법적 권한을 가집니다. 배포판 안에 있는 LICENSE 화일과 <url url="http://www.3dfx.com" name="www.3dfx.com">
을 읽어 보십시오. 바이너리 화일들이 있더라도 테스트 프로그램들은
컴파일을 하고 링크를 하는게 좋습니다. 몇 프로그램들은 실행하기
위해서 배포판에 따라온 alpha.3df 같은 화일들이 같은 디렉토리에 있어야
합니다.
테스트 프로그램들은 모두 640x480 해상도를 사용합니다. 어느
프로그램은 단순 문자입력을 필요로 하며, 어느 프로그램은 Press A Key
To Begin Test (테스트를 시작하기위해 아무 키나 누르세요.) 와같은
메세지를 출력합니다. 싱글스크린 셋업에서 X11을 사용할 경우 마우스
/키보드의 입력 범위가 줄어드는 것을 알아 두십시오. 프로그램 리스트와
다른 내용을 참조하려면 README.test 를 보십시오.
</P>
<sect>무엇이든 물어보세요: 이럴땐 어떻게 해야 하지요?
<p>
다음 부분은 많은 분들이 뉴스 그룹과 메일링 리스트를 통해 던져
주셨던 질문에 대한 답변들입니다. "FAQ" 는 다음과 같이 나누어져
있습니다.
<itemize>
<item>시스템 요구사항은 무엇입니까?
<item>부두 그래픽(tm) 과 3Dfx는 무엇입니까?
<item>글라이드
<item>글라이드와 SVGA
<item>글라이드와 XFree86
<item>글라이드와 OpenGL, 그리고 메사
<item>퀘이크
<item>문제해결방법
</itemize>
이 FAQ는 질문과 답변으로 섹션이 구성되어 있습니다. 이것으로 웬만한
문제는 거의 해결 할 수 있습니다.
</P>
<sect>무엇이든 물어보세요: 시스템 기본사항
<sect1>시스템 기본 사항은 무엇입니까?
<p>
리눅스 PC이며 PCI 2.1 호환이 되어야 합니다. 모니터는 640x480의
해상도를 지원해야 하며, 3D 액셀러레이터는 부두 그래픽 (tm)의 3Dfx
칩셋을 기반으로 해야 합니다. P5와 P6 CPU에서 MMX의 유무는 문제가
되지 않습니다. 현재의 글라이드 배포판은 MMX 기능을 사용하지 않고
있지만 P6 CPU를 사용한다면 최적화된 전용코드가 가 성능을 향상시켜줄
것입니다.
프로그램 사용중 3Dfx의 메세지는 리눅스 글라이드를 사용하기 위해서는
레드햇 리눅스를 사용해야 한다는 인상을 줄 수 있습니다. 유저가 숙지
해야 할 사항은, 글라이드는 원래 레드햇 4.1 환경에서 포팅이 되었지만,
글라이드는 homebrew(역자주: 뭐야 이건?), 슬랙웨어와 데비안 1.3.1을
포함한 다른 리눅스 버전에서도 사용되고 테스트가 되었다는 것입니다.
</P>
<sect1>IRQ 요구사항은 어떻게 됩니까?
<p>
IRQ 와 포트는 사용되지 않으므로 이와 관련된 문제는 일어나지 않을
것입니다.
</P>
<sect1>글라이드에서 MMX의 역할은 무엇입니까?
<p>
글라이드 소스 베이스에는 MMX전용의 코드는 없습니다. MMX는 반복해서
쓰이는 오퍼레이션(SIMD)에서 굉장한 성능을 보이지만, SIMD는 글라이드
에서는 사용되지 않습니다. 이런 이유로, 새로 나올 글라이드 버젼에서도
MMX를 위한 코드는 쓰이지 않을 것이며, 리눅스 글라이드 포트도 마찬가지
일 것으로 보입니다.
</P>
<sect1>非 인텔 CPU에 관하여
<p>
글라이드에서는 K6나 다른 CPU전용으로 최적화된 코드가 쓰여지지
않았습니다.
</P>
<sect1>펜티움 프로와 펜티움 II 에서의 성능
<p>
바이오스에서 설정하는 메모리 타입 레인지 레지스터 (Memory Type
Range Registers, MTRR)와 FX 칩셋 버그때문에 리눅스 글라이드와 다른
글라이드 보트들과는 성능차이가 있습니다. 리눅스 커널이 이런 문제까지
해결하기를 바라기는 조금 무리이기는 하지만 개정작업이 이루어 주고
있는 중입니다.
</P>
<sect1>알파CPU를 사용하는 리눅스에서의 글라이드 설치
<p>
인텔 586 CPU 이외에는 리눅스용 글라이드는 다른 CPU와 호환이 되지
않습니다. 글라이드 소스는 공개가 되지 않았기 때문에 프로그램이
나올때까지 기다리는 수 밖에는 없습니다. 퀀텀 3D 2H97용 DEC 알파
지원을 발표했습니다. 자세한 사항은 Daryll Strauss씨를 연락하면
되겠습니다.
알파CPU 에 어셈블리 모듈을 포팅하는 데에도 문제가 있습니다. 같은
기능을 하는 C path가 소스에 있기는 하지만 사용되는 펜티움 CPU에 따라
글라이드(결국은 삼각형그리기이다.) 에 있는 어셈블리 모듈은 성능을
상당히 향상시켜 줍니다.
</P>
<sect1>어느 3Dfx 칩셋이 지원됩니까?
<p>
현재로서는 리눅스 환경에서는 3Dfx 부두 그래픽(tm)칩셋이 지원됩니다.
그리고, 부두 2(tm)은 아직은 지원이 안됩니다.
</P>
<sect1>부두 러쉬(tm)도 지원이 됩니까?
<p>
리눅스에 포팅이 된 글라이드는 아직까지는 부두 러쉬(tm)를 지원하지
않지만 다음 업데이트에서는 지원이 가능하도록 현재 작업중에 있습니다.
부두 러쉬(tm)에서의 문제는, 부두 러쉬(tm) 용 글라이드의 드라이버 코드
가 다이렉트 드로우에 의존했다는 것에 있습니다. 2D/다이렉트 드로우/D3D
콤보 드라이버가 교체되었기 때문에, 이론적으로 리눅스용으로 사용될 수
있었던 SST96을 기반으로 한 DOS 부분이 있었습니다. 이런 이유로, 부두
러쉬(tm)칩셋을 기반으로 한 액셀러레이터 카드들(허큘레스 스팅레이
128/3D, 혹은 인터그래프 인텐스 러쉬 같은 카드)는 아직은 지원되지 않고
있습니다.
</P>
<sect1>부두 2(tm) 카드는 지원이 됩니까?
<p>
현재 리눅스에 포팅이 된 글라이드는 부두 2(tm)를 지원하지 않습니다.
</P>
<sect1>리눅스 환경에서의 3Dx 지원은 어디서 하는 것입니까?
<p>
칩제조업체인 3Dfx 에서 리눅스용 글라이드를 내부적으로 지원/관리하고
있습니다. 3Dfx칩을 사용하는 액셀러레이터카드의 제조업체 자원이 제한
되어 있기 때문에 현재 이루어 지고 있는 이상의 지원이나 3Dfx요원에
의한 공식적인 지원이 불가능합니다. 하지만, 퀀텀3D에서는 자사제품
옵시디안 카드 시리즈의 공식적인 리눅스지원을 발표했으며 현재 리눅스용
프로그램을 포팅하고 있는 과정에 있습니다.
부두 그래픽(tm)용 글라이드의 리눅스 포팅을 하는 베타 테스트과정에서
퀀텀3D의 유럽지부 배포자인 데이터패스(有)와 오키드의 배포자인
마이크로닉스에서는 하드웨어를 빌려주려 하였습니다. 인터그래프와
다이아몬드에서는 어떠한 형태의 지원도 하지 않을것이라고 구체적으로
밝혔으며, 허큘레스에서는 응답도 하지 않았습니다. 현재 리눅스에서의
부두 2 (tm)지원을 준비하는 과정에서, 몇번의 신청에도 불구하고 아무
OEM도 도와주지 않고 있습니다. OEM 지원 acknowledgement에 좀 더
자세한 내용이 있습니다.
</P>
<sect1>어느 액셀러레이터 카드가 지원이 됩니까?
<p>
3Dfx가 보드를 판매하지 않기 때문에 공식적으로 지원되는 카드는
없습니다. 이 섹션에서 보드이름을 모두 나열하지는 않겠지만, 문제를
일으키는 카드의 리스트와, 호환되는 대강의 리스트를 열거 해
놓았습니다.
리눅스에서 액셀러레이터 카드를 지원하기 위해서는 3D 액셀러레이터
부분의 드라이버만 있어서는 안됩니다. 그래픽카드에 고유의 VGA 코어가
있으면 리눅스 SVGA, 혹은 XFree86이 필요합니다. (부두 러쉬(tm)섹션을
참조해 주세요.) 현재로서는 보통 쓰이는 그래픽 카드를 안정적으로 지원
하는 애드온 솔루션(뭔지 잘 모르겠네요.)을 사용하는게 바람직합니다.
다른 여러가지 고려할 사항은 밑에서 다루겠습니다.
퀀텀 3D 옵시디안 보드는 모두 텍스쳐 메모리, 프레임 버퍼 메모리,
Pixelfx, Telexfx 유닛으로 부터 독립이 되어있으므로 SLI를 사용하면
무난하겠습니다. 오키드 라이쳐스 3D, 카노푸스 퓨어 3D, 플래쉬 3D,
그리고 다이아몬드 몬스터 3D 등 처럼, 부두 그래픽(tm)을 기반으로 한
비디오 카드들에게도 위의 방법이 적용됩니다. 부두 러쉬(tm)를 사용하는
비디오 카드는 아직은 지원이 되지 않습니다.
3Dfx 칩셋을 사용하지 않는 비디오 카드들 (S3, 매트록스, 3DLabs,
비디오로직을 기반으로 하는 비디오카드들)은 3Dfx 드라이버가 실행되지
않기 때문에 이 카드들은 이 문서의 내용범위를 벗어납니다.
</P>
<sect1>3Dfx칩셋을 사용하는 비디오 카드들의 차이점은 무엇인가요?
<p>
3Dfx칩셋을 사용 하는 카드들의 차이점은 하드웨어 디자인의 차이에서
오는 결과라 할 수 있겠습니다. 예를 들자면, VGA 와 액셀러레이터 카드
사이의 비디오 신호 케이블과 커넥터의 품질이랄지 (이점에선 오키드社의
제품이 다이아몬드社의 제품보다 후한 점수를 받아야 합니다.)
TV출력단자의 유무사항(카노푸스 퓨어 3D 카드), 그리고 가장 중요한
비디오 램 사이즈가 되겠습니다.
대부분의 게임용 보드들은 2메가바이트의 텍스쳐 캐쉬와 2메가바이트의
프레임버퍼 메모리를 제공합니다. 주의할 사항은 텍스쳐를 빠르게 전환
시키거나 일루미네이션 텍스쳐 (잔잔한 빛이 나오는 텍스쳐, 퀘이크가
좋은 예이다.)를 사용하는 게임에서 성능을 발휘하는 텍스쳐 캐쉬메모리를
카노푸스 퓨어 3D는 최고 4메가바이트까지 제공합니다. 전형적인 부두
그래픽 (tm) 의 메모리 아키텍쳐는 밑에 별도의 섹션에 설명되어있습니다.
퀀텀 3D는 가장 많은 종류의 3Dfx 기반의 비디오 카드를 제공하고 있으며,
고성능의 부두 그래픽 (tm) 을 원한다면 이 회사의 제품을 선택하는게
좋습니다. 소비자위주의 PC게임 시장을 주요 관심사에 두고있는 기존의
회사들과는 달리, 퀀텀 3D는 비쥬얼 시뮬레이션 부분에 대한 영업도 하고
있습니다.
</P>
<sect1>AGP의 사용에 관해
<p>
부두 그래픽(tm)이나 부두 러쉬(tm) 중에 저자가 알고 있는 AGP보드는
없습니다. (역자주: 글쓴 시점이 1998년 2월이므로 지금은 아마도 다를
겁니다...필요하신 분은 알아보시는게.) 리눅스에서는 AGP가 지원이
안되는 걸로 알고 있으며, 차후에 발표될 AGP를 사용하는 3Dfx 카드가
리눅스에서 지원이 될는지도 확실하지가 않습니다.
부두 2 (tm)은 단순히 PCI버스의 속도만 높인 방식으로 AGP를 인식해서
지원하며, 아무런 AGP고유의 기능(예를 들면 칩셋의 DIME메모리 관리 방법
등)은 사용하지 않습니다. 부두 2(tm)에서는 전용버스가 있다는 것과, 더
빨라진 버스속도가 있다는 성능향상만 눈에 띕니다.
리눅스 커널은 부두2 (tm)을 세컨더리 PCI버스에 있는 것 처럼 인식할
것입니다. 밑에 나온게 리바-128 AGP 카드(RIVA0128 AGP)의 예입니다.
/proc/pci 에서의 sniplet. ):
<code>
Bus 1, device 0, function 0:
VGA compatible controller: Unknown vendor Unknown device (rev 16).
Vendor id=12d2. Device id=18.
Medium devsel. Fast back-to-back capable. IRQ 9.
Master Capable. Latency=64.
Min Gnt=3.Max Lat=1.
Non-prefetchable 32 bit memory at 0xfd000000.
Prefetchable 32 bit memory at 0xf6000000.
</code>
하지만 아무 제품개발자들도 부두2(tm) AGP 보드개발에 나서지 않고
부두2(tm) 도 보통의 PCI버스에서 지원이 안되고 있는 관계로 AGP는 전혀
지원이 되지 않고 있습니다. 이 분야에 관심이 있으면 OEM들을 연락해서
지원연구에 필요한 하드웨어를 요청해 보는것도 한 방법이겠습니다.
</P>
<sect1>어느 보드를 구입하면 좋을까요?
<p>
이건 유저 스스로 결정해야 할 사항입니다. 필요한 사항을 먼저 결정한
다음(풀스크린, 윈도우, 게임, OpenGL, 응용 소프트웨어, 개발작업, fill
rate, 텍스쳐 메모리, 예상되는 사용기간, SLI의 스케일 가변성 (역자주:
원문에는 "scalability by SLI" 라고 나와있음..) 윈벤치 같은 잡지사
에서 하는 평가는 무시를 해도 좋습니다. 테크니컬 스펙을 보는게 가장
현명한 방법이라 하겠습니다.
만약 유저에게 알맞는 보드가 여러개 있다면, 이 문서에 있는 OEM지원
사항을 참조해 주십시오. 이 문서를 쓰는데에 도움을 주었던 판매업체에서
알아보는 것도 좋습니다. 확신이 서지 않는 부분이 있다면 제조업체들에게
직접 질문을 하거나, 리눅스의 지원사항에 대해 바로 물어보십시오.
</P>
<sect>무엇이든 물어보세요: 부두 그래픽(tm)과 3Dfx는 무엇입니까?
<sect1>3Dfx는 어떤 회사입니까?
<p>
3Dfx는 산호제 (역자주: San Jose, 캘리포이아의 실리콘 밸리입니다.)에
있는 아케이드 게임용 3D 그래픽 액셀러레이터 하드웨어, 게임 콘솔,
그리고 PC 보드를 제조하는 회사입니다. 공식 웹페이지는 <url url="http://www.3dfx.com" name="www.3dfx.com">
입니다. 퀀텀3D같은 다른 회사들과는 달리 3Dfx는 아무 보드도 판매하고
있지 않습니다.
</P>
<sect1>퀀텀3D는 어떤 회사입니까?
<p>
소비자와 비즈니스 업체를 주요대상으로 하는 고성능 3Dfx 칩셋
액셀러레이터 보드제조와 아케이드 게임 기술공급을 하다가 3Dfx에서 따로
떨어져 나온 회사가 퀀텀3D 입니다. 이에대한 내용은 회사 홈페이지
<url url="http://www.quantum3d.com" name="www.quantum3d.com"> 을 참조해 주십시오. 퀀텀 3D에 대한 일반적인 내용의
질문은 <url url="mailto:info@quantum3d.com" name="info@quantum3d.com"> 으로 이메일을 보내주시면 되겠습니다.
</P>
<sect1>부두 그래픽(tm)은 무엇입니까?
<p>
부두 그래픽(tm)은 3Dfx 社에서 만든 칩셋입니다. 부두 그래픽(tm)은
PC용 하드웨어 액셀러레이션 보드에 쓰입니다. HOWTO섹션에 지원이 되는
하드웨어의 리스트가 나와있습니다.
</P>
<sect1>부두 러쉬(tm)는 무엇입니까?
<p>
부두 러쉬(tm)는 원래의 부두 그래픽(tm)에 2D VGA액셀러레이터와의
인터페이스를 첨가한 후 마이크로소프트 윈도즈에서의 가속된 비디오를
지원하게 한 부두그래픽(tm)의 변경된 모델입니다. 아쉽게도 현재로서
이것은 리눅스에서는 작동하지 않습니다.
</P>
<sect1>부두 2(tm)는 무엇입니까?
<p>
부두그래픽(tm) 칩셋을 여러모로 개선한 차기 모델이 부두2(tm)입니다.
부두 2(tm)를 기반으로 하는 보드들(퀀텀 3D, 크리에이티브 랩스, 오키드
테크놀로지, 다이아몬드 멀티미디아)에 관한 사항은 1998년 3월 후반에
발표가 되었습니다. (역자주: 이거 뭔가 이상하다... 글이 쓰여진 시점은
1998년 2월 말이건만...) 부두2(tm)은 구 버전과도 호환이 되게끔
되어있습니다. 하지만 글라이드의 새 버전이 리눅스에 포팅이 되어야
하겠습니다.
</P>
<sect1>VGA pass-though (VGA 패스스루)는 무엇입니까?
<p>
부두 러쉬(tm)을 제외한 모든 부두 그래픽(tm) 카드들은 애드온
보드로서, 기존의 2D VGA카드에 덫붙여서 사용하게 되어있습니다. VGA
카드에서 나오는 출력이 부두 그래픽(tm)을 통한 다음, 모니터로 통과되는
것을 VGA Pass-Through라고 합니다.
부두 그래픽(tm) 이 게임 애플리케이션에 의해 사용 되는 경우에는 원래
쓰이고 있던 VGA 입력이 단절되고 640x480 풀스크린 모드로 전환된 다음,
SST변수값과 실행되고있는 애플리케이션/드라이버에 따라 리프레쉬 레이트
(refresh rate)가 결정됩니다. 이때, 부두 그래픽(tm)은 스스로 비디오
신호를 계산, 출력합니다. VGA 카드는 이 과정에서 관여할 필요가 없으며,
앞으로도 이 과정에 VGA를 개입시킬 가능성은 희박합니다.
이 셋업에는 몇가지 장점이 있습니다. VGA 카드에 상관없이 3D
액셀러레이터가 작동을 하기 때문에, 유저는, 리눅스 환경에서 골치거리만
생기게 하는 XFree86 VGA 비디오 셋업을 하지 않고, 비디오카드에서
액셀러레이터로 비디오 시그널을 보내게 됩니다.
하지만 Pass-through 방법을 쓸 때 컴퓨터 크래쉬가 생기면 부두 그래픽
(tm)이 원래의 VGA 출력을 재생시키지 못한다는 단점이 있습니다. 게다가,
원래 쓰고 있던 VGA 출력이 액셀러레이터 카드를 지나가면서 품질이
떨어진다는 것이 큰 단점입니다.
</P>
<sect1>Texelfx와 TMU는 무엇입니까?
<p>
부두 그래픽(tm) 칩셋은 두가지 유닛으로 구성되어 있습니다. 첫째는
액셀러레이터에 있는 텍스쳐 메모리를 외부와 정보교환을 할 수 있게
해주며, (인터페이스) 텍스쳐 매핑, 그리고 프레임 버퍼와 정보교환을
하게 해주는 두번째 유닛으로 들어가는 출력을 만드는 역할을 합니다.
이 부분이 텍스쳐 관리 유닛이라 불리며 Texelfx, 혹은 TMU (Texture
Management Unit, TMU)라고도 불립니다. 퀀텀3D 옵시디안 보드에서 볼 수
있듯이, Texelfx는 한 보드에 두 유닛이 한꺼번에 설치/사용될 수 있기
때문에, 애플리케이션에 따라서는 카드의 출력이 쉽게 두배로 늘어 날 수
있습니다. Texelfx 하나는 4메가바이트의 텍스쳐 메모리를 관리 할 수
있기 때문에 두개의 Texelfx 셋업은 사용 가능한 텍스쳐 캐쉬메모리를
8메가 바이트까지 사용 할 수 있게 해 줍니다. 그리고, 컴퓨터의 다른
부분에서 요구를 한 텍스쳐정보는 각각의 Texelfx 에 할당이 될 수 있기
때문에 위와 같은 경우는 사용하는 애플리케이션이 Texelfx 를 한 유닛만
사용하는 경우에도 해당됩니다. 이 두개의 Texelfx는 glQuake에서의
경우에서 볼 수 있듯이, 트라이리니어 필터링이나 일루미네이션 텍스쳐
/라이트맵 패스와 같은 특정 작업을 한번의 패스를 사용해서 처리 할 수
있습니다. 만약 한개의 Texelfx만 있는 경우라면 두번의 패스를 사용해야
합니다. 이렇게 이론상으로만 가능한 스피드를 향상시키고 캐쉬메모리
크기를 증가시키려면 사용하는 글라이드 애플리케이션이 두개의 Texelfx를
알맞게 사용해야 합니다. 이 두개의 Texelfx는 텍스쳐로 꾸며진 삼각형을
독립적으로 하나씩 동시에 그리지는 못합니다. 언제든지 삼각형을 그리기
위해서는 두개의 Texelfx를 싱글패스로 두 텍스쳐를 합쳐서 사용하거나,
한개의 Texelfx를 한개의 텍스쳐만을 사용한다거나 하는, 그때그때의 설정
사항을 따라서 그려야 합니다. 각각의 Texelfx는 관리하도록 할당되어
있는 메모리만 접근이 가능하기 때문입니다.
</P>
<sect1>Pixelfx 유닛이란 무엇입니까?
<p>
앞에서도 언급했듯이 부두 그래픽(tm) 칩셋은 두개의 유닛으로 구성되어
있습니다. 그 중, 두번재 유닛이 프레임 버퍼의 정보교환기능을 하며,
버퍼의 깊이와 픽셀 컬러의 업테이트를 제어하는 역할을 합니다. 이
유닛이 Pixelfx 라고 불립니다. 두개의 독립적인 Pixelfx 유닛은 몇몇
퀀텀3D 옵시디안 모델에서도 볼 수 있듯이 SLI 모드에서 같이 작동을 해서
프레임 레이트를 두배로 늘릴 수 있는 기능을 가지고 있습니다.
</P>
<sect1>SLI모드란 무엇입니까?
<p>
SLI 는 "스캔라인 인터리브(ScanLine Interleave)"의 줄임말입니다.
SLI 모드에서는 두개의 Pixelfx가 연결이 되어서, 실제의 비디오 출력시
한번씩 번갈아가며 스캔라인을 렌더링합니다.
SLI모드에서 각각의 Pixelfx는, 이미지의 정보중 절반과, 색깊이
버퍼정보의 절반을 해당Pixelfx의 로컬 프레임 버퍼에 저장을해서
픽셀숫자를 두배로 늘립니다. 이때, 사용되는 Pixelfx는 하나, 혹은 잘
연결된 두개의 보드에 따로 존재 할 수 있습니다. 퀀텀 3D 옵시디안
보드중 몇 모델은 부두 그래픽(tm)의 SLI모드를 지원합니다. 두개의
카드에서는 동일한 PCI 주소를 디코드하고 동일한 입력자료를 받을 수
있기 때문에, SLI를 사용하는것은 별도의 버스폭을 차지하지 않습니다.
하지만 텍스쳐 데이터의 양이 변함이 없게 하기 위해, 텍스쳐의 정보가
두개의 보드위에 하나씩 복사되어 있어야 합니다.
</P>
<sect1>PCI 슬롯을 하나만 할당하고도 SLI를 사용 할 수 있나요?
<p>
현재로서는 퀀텀3D SLI보드는 두가지 종류가 있습니다. 초창기의
카드셋업은 퀀텀 3D옵시디인 100-4440처럼 서로 연결된 PCI 카드를 두개
사용했었습니다. 퀀텀 3D 옵시디안 100-4440SB처럼 후반에 나온 카드들은
같은 원래 배포된 카드와 같은 방식으로 작동하지만 PCI슬롯을 하나만
차지합니다. 그러므로 카드를 하나만 쓰면서도 SLI환경에서 작업을 하는게
가능합니다.
</P>
<sect1>메모리와 버퍼는 얼마나 필요합니까?
<p>
부두그래픽(tm)칩셋을 사용하는 카드들의 차이점은 보드에서 메모리를
어떻게 다루느냐와 비디오램의 양이 얼마나 되느냐에 따라 결정됩니다.
퀀텀 3D는 세자리 숫자를 사용하는 방법으로 보드에 대해 설명합니다.
밑의 내용은 부두 2(tm)에서 사용되리라고 생각되는 약간 변형된
내용입니다 (역자주: 네자리 숫자. 밑에 나와있습니다). 하나이상의
Texelfx를 사용하면 유저는 같은 양의 텍스쳐 캐쉬 메모리를 하나씩
할당해야하고, 두개의 Pixelfx와 합치면 이것도 같은 양의 프레임 버퍼
메모리를 필요로 합니다.
<code>
"SLI / Pixelfx / Texelfx1 / Texelfx2 "
</code>
다시 말하자면, 보통 쓰이는 2메가바이트 + 2메가바이트 보드는 이
4메가 바이트가 되는 메모리를 1/2/2/0 의 방법을 통해 사용한다는
것입니다. 카노푸스 퓨어3D는 1/2/4/0 의 방법으로 6메가바이트의
메모리를 사용합니다. Texelfx를 두개 사용하는 옵시디안 2220 보드는
1/2/2/2일 것이며, 옵시디안 SLI 2440은 2/2/4/4 입니다. 부두 그래픽
(tm)에서 지원하는 모든 기능을 사용하는 비디오 카드라면 2개의
Pixelfx을 사용하며, 각각의 Pixelfx에는 두개의 Texelfx와 4메가바이트의
프레임 버퍼, 그리고 각각의 Texelfx에게 4메가바이트의 텍스쳐 캐쉬를
제공할 것입니다. 이것은 2/4/4/4와 같이 나타내 질 수 있으며, 여기에
필요한 메모리의 양은 SLI*(Pixelfx+Texelfx1+Texelfx2) 이므로 24메가
바이트가 되겠습니다.
</P>
<sect1>부두 그래픽(tm)에서 24비트나 32비트칼라를 사용할 수
있습니까?
<p>
24비트 RGB와 32비트 RGBA등의 어떠한 포맷을 사용해도 텍스쳐와
비디오정보를 다룰 수 있습니다. 하지만 부두 그래픽(tm) 아키텍쳐에서
프레임버퍼는 16비트칼라를 사용한다는 것에 주의해 주십시오. 부두
그래픽(tm)과 부두 러쉬(tm)그리고 부두2(tm)에서 이것은 모두 같이
적용됩니다. 무슨 뜻이냐 하면, 픽셀처리는 천연색으로(24비트, 혹은
32비트로) 되겠지만 결과적인 매핑은 16비트로 된다는 것입니다. 퀀텀
3D社에서는 자체 카드의 구조와 글라이드 인터페이스를 통해, 16비트컬러
프레임버퍼를 이용한 22비트칼라를 지원한다고는 하지만 실제로 사용되는
애플리케이션은 몇 없는 듯 합니다.
</P>
<sect1>부두그래픽(tm)에서는 픽셀을 한 24비트/32비트 Z-버퍼를 사용해
저장합니까?
<p>
아닙니다. 부두 그래픽(tm)는 내부적으로 색상깊이 버퍼에서 16비트
칼라를 사용하도록 설계되었습니다. 이것도 부두 그래픽(tm), 부두
러쉬(tm), 그리고 부두2(tm)에 모두 해당하는 사항입니다. 퀀텀 3D社
에서는 픽셀당 16비트 부동소수를 사용하여 Z-버퍼에서의 색상깊이가
픽셀당 22비트가 되게끔 한다고 합니다.
</P>
<sect1>부두 그래픽(tm)에서는 해상도를 어디까지 지원합니까?
<p>
부두그래픽(tm) 칩셋에서는 최고 4메가바이트까지의 프레임버퍼
메모리를 지원합니다. 더블버퍼링과 색상깊이버퍼까지 사용한다면
2메가의 프레임버퍼는 640x480의 해상도를 지원 할 것입니다. 4메가의
프레임 버퍼로는 800x600 의 해상도까지 사용 할 수 있습니다.
아직까지 960x720의 해상도는 지원되지 않고 있습니다. 부두 그래픽(tm)
칩셋에서 특정 해상도를 사용하기 위해서는 세로/가로의 해상도가 둘다
32로 나누어서 정수의 몫이 나오는 숫자여야 한다는 조건을 가지고 있기
때문에 일부의 해상도는 지원이 안됩니다. (역자주: 720을 32로 나누면
22.5가 됩니다.)
비디오 리프레쉬 콘트롤러에서는 어떠한 해상도도 지원하지만, 메모리
풋프린트용 '가상 해상도'의 가로/세로의 픽셀 숫자도 32로 나누어서
정수의 몫이 나와야 하는 숫자여야 합니다. 그러므로, 960x720는 사실상
960x736의 해상도를 지원할 수 있는 메모리가 필요하며, 960x736x2x3 =
4.04메가바이트 입니다.
한가지 알아야 할 사항은, 보드를 두 개 사용하여 SLI를 사용하거나 이
듀얼보드 모드를 지원하는 보드를 사용할 때에는 각각의 프레임버퍼에서
이미지정보의 절반씩만 저장을 해도 된다는 것입니다. 그러므로 2개의
4메가 바이트보드는 SLI모드에서 하드웨어에서 사용가능한 최대수치인
1024 x 768의 해상도를 지원할 수 있습니다. 유저는 Z트리플 버퍼로
1024x768의 해상도를 사용 할 수 있지만, 1280x960의 해상도는 더블버퍼링
으로 버퍼링 율을 내려야만 사용 할 수 있습니다.
또 트리플 버퍼링(VSync 동기화를 사용하지 않는 애플리케이션),
스테레오 버퍼링(LCV 셔터와의 인터페이스 사용), 그리고 다른 시스템에
무리를 주는 설정을 사용하면 사용가능한 최대 해상도의 크기가 매우
작아집니다.
</P>
<sect1>텍스쳐사이즈는 어디까지 지원이 됩니까?
<p>
부두그래픽(tm)에서 지원되는 최대 텍스쳐사이즈는 256x256이며, 이
사이즈는 언제나 2의 지수(2^x의 형태)의 꼴입니다. 16x16처럼 아주 작은
텍스쳐를 사용 할 때에는 이 작은 텍스쳐를 커다란 텍스쳐로 합치고
생성된 텍스쳐 블록에 있는 각각의 텍스쳐의 위치를 알맞게 맞춰주는 것이
효과적입니다.
</P>
<sect1>부두 그래픽(tm)에서는 팔레트 텍스쳐가 지원이 됩니까?
<p>
부두 그래픽(tm)하드웨어와 글라이드에서는 OpenGL의 팔레트 확장을
지원합니다. 메사의 최신버전에서는 GL_EXT_palette_texture와
GL_EXT_shared_texture_palette 익스텐션을 지원합니다.
</P>
<sect1>부두 그래픽(tm)에서의 오버클러킹 사용은 어떻게 됩니까?
<p>
A/S와 칩셋의 과열현상을 무시 할 수 있다면 오버클러킹에 도전해 보는
것도 좋은 생각입니다. 오버클러킹으로 성능을 향상 시키는 방법은
인터넷 웹사이트에 떠 있습니다. (*역자주: 한국어 사이트는 찾아 볼
수가 없었습니다. 외국어 사이트에 가 보십시오.) 부두 카드의
오버클러킹은, 글라이드 환경변수를 바꾸어서 클럭사이클을 바꾸는 것으로
할 수 있습니다.
부두그래픽(tm)에서 실제의 클럭사이클은 보드에 따라 다릅니다. 부두
그래픽(tm)칩셋의 기본 클럭스피드는 50Mhz이지만, 다이아몬드3D의 환경
변수 조정은 클럭스피드를 57Mhz까지 올리도록 해 줍니다. 클럭스피드를
근본적으로 결정할 수 있는 요인은 사용하고 있는 보드의 디자인에 따라
결정이 됩니다. 부두 그래픽(tm) 칩셋과 더불어 사용되는 부품들,
램스피드와 같은 것이 오버클러킹스피드의 최대속도를 결정하는 요인이
되겠습니다.
(*역자주: 다음 부분은 무슨 소리인지 모르겠습니다. 독일어를 하시는
분이 읽고 이해가 가시면 저에게 연락을 주십시오. 개정을 하겠습니다.
김병인: <url url="mailto:itchingbrain@hotmail.com" name="itchingbrain@hotmail.com">) ( If you exceed the limits of your
hardware, rendering artifacts will occur to say the least. )
지금까지 관찰된 바에 의하면 57Mhz로의 오버클러킹은 잘 작동을
하지만, 60Mhz까지 사용하는것은 조금 무리입니다. 또, 클럭 프리퀀시를
증가시키면 클럭속도 증가율 이상으로 액셀러레이터 보드에 있는 칩의
온도가 전체적으로 올라갑니다. 예를 들자면, 10%의 클럭스피드 증가는
10%이상의 온도증가를 야기시킵니다. 그리고, 오버클러킹을 한 상태로
계속해서 컴퓨터를 사용하려면 쿨링팬을 사용해서 부두그래픽(tm) 보드의
온도를 낮추어서 제품보증에 영향을 미치지 않는 방법에 대해서도 알아
보아야 합니다. 추천할 만한 웹사이트는 Eric van Ballegoie가 쓴 "3Dfx
Voodoo Heat Report"입니다. (역자 첨가: 이 웹사이트의 주소는
<url url="http://www.fastgraphics.com/" name="www.fastgraphics.com/"> 입니다.)
</P>
<sect1>부두 그래픽 (tm)에 관한 다른 정보는 어디에서 얻을 수 있나요?
<p>
3Dfx에서 내놓은 FAQ는 3Dfx의 웹사이트에서 찾아 볼 수 있습니다.
소매점에 관한 정보는 <url url="http://www.3dfx.com" name="www.3dfx.com"> 과 <url url="http://www.quantum3d.com" name="www.quantum3d.com"> 에서 찾아 볼
수 있겠습니다. 3Dfx에 관해 좋은 정보를 가지고 있는 비공식 웹 사이트는
"Voodoo Extreme" 과 "Operation 3Dfx" (둘다<url url="http://www.ve3d.com" name="www.ve3d.com"> 입니다.)에서
찾아 볼 수 있습니다.
</P>
<sect>무엇이든 물어보세요: 글라이드와 TexUS
<sect1>7.1. 글라이드란?
<p>
글라이드는 3Dfx의 칩셋을 사용하는 3D 그래픽 액셀러레이터 카드를
제어하기위한 전용 API와 드라이버입니다. 글라이드는 원래 DOS, 윈도즈
와 매킨토시용으로 개발이 되었으며 Daryll Strauss씨가 리눅스용으로
포트를 해 주셨습니다.
</P>
<sect1>TexUS는 무엇입니까?
<p>
글라이드 배포판에는 libtexus.so라는 3Dfx의 인터액티브 텍스쳐
유틸리티가 있습니다. 이 배포판에는 이미지 처리 라이브러리와 3Dfx
인터액티브 글라이드 라이브러리에서 사용될 이미지를 준비하는
유틸리티도 있습니다. TexUS의 기능을 들자면, 화일포맷변환, MIPmap
만들기, 3Dfx 인터액티브 좁은채널 압축텍스쳐의 지원이 있겠습니다.
texus라는 유틸리티는 TGA, PPM, RGT와 같이 자주 쓰이는 이미지 포맷
으로 된 화일을 읽어서 MIPmaps를 생성 시킨 다음 이 이미지를 alpha,
3df, 와 같은 3Dfx 인터액티브 텍스쳐 화일이나 검사용 이미지 화일로
저장을 합니다. 자세한 내용은 texus의 변수, 그리고 3Dfx의 API, 그리고
TexUS 문서를 참조하시기 바랍니다.
</P>
<sect1>글라이드는 무료 소프트웨어입니까?
<p>
글라이드는 무료 소프트웨어가 아닙니다. 글라이드는 GPL 혹은 다른
공중 라이센스를 사용해서 배포되지 않았습니다. 자세한 내용은 포함되어
있는 LICENSE 화일을 참조하시기 바랍니다. 글라이드 소프트웨어를
다운로드해서 사용하는 것은 3Dfx 웹사이트에 나와있는 EULA (End User
License Agreement)에 동의했다는 것을 의미합니다. 글라이드는 바이너리
화일만 제공이 되며, NDA에 사인을 하지 않은 이상 3Dfx에서 원래 나누어
주는 화일그대로 사용/배포를 해야합니다. 테스트 프로그램들을 포함한
글라이드 배포판은 3Dfx가 저작권을 갖습니다. 이것은 글라이드 배포판에
있는 소스코드에도 해당이 됩니다. 3Dfx에 따르면 글라이드는 공중
도메인이 아니지만 3Dfx의 제품을 소유하고 있는 이들에게는 자유로이
배포가 될 수 있습니다. 한마디로 말해, 3Dfx칩을 사용하는 카드가
없으면 글라이드를 사용 할 수 없습니다.
</P>
<sect1>글라이드는 어디에서 얻을 수 있습니까?
<p>
3Dfx의 SDK 는 모두 다음의 웹사이트에서 다운로드 할 수 있습니다.
<url url="http://www.3dfx.com/software/download_glide.html" name="www.3dfx.com/software/download_glide.html">. 3Dfx에서 제공하는
소프트웨어도 <url url="http://www.3dfx.com">에서 구할 수 있습니다. 그리고, 3Dfx에서는
FTP사이트 서비스도 제공합니다. (주소 <url url="ftp://ftp.3dfx.com" name="ftp.3dfx.com">) 이 FTP 사이트는
타임아웃시간도 길게 해 주며, 큰 화일들은 보통 작은 사이즈의 파일로
나누어져 있습니다. (보통 3MB씩해서 자릅니다.)
</P>
<sect1>글라이드의 소스코드도 배포가 됩니까?
<p>
아니오. 글라이드의 소스코드를 얻는것은 3Dfx와의 특별 계약과 NDA를
통해서만 가능합니다.
</P>
<sect1>리눅스버전 글라이드 지원
<p>
3Dfx에서 아직까지는 리눅스 글라이드에 대한 사용자지원을 하지
않습니다. 그리고, 글라이드는 3Dfx GL DLL이 배포조건과 같은 조건으로
배포가 됩니다. (밑을 참조하세요.) 계약이 이렇게 나와있기는 하지만
3Dfx에서는 최선을 다해서 지원을 하고 있으며, 현재로서는 리눅스
글라이드를 지원하기 위한 법적 준비를 하고 있는 상태에 있습니다.
지금으로서는 3Dfx 뉴스그룹에 의존하는 수 밖에 없습니다.
퀀텀3D 의 홈페이지에서는 인텔과 2H97에서의 AXP 아키텍쳐용 리눅스
에서의 옵시디안 사용자지원에 대한 계획을 갖고 있습니다.
</P>
<sect1>리눅스버전 글라이드 뉴스그룹
<p>
3Dfx社에서 운영하는 NNTP 서버, <url url="http://news.3dfx.com" name="news.3dfx.com">가 유일한 글라이드
뉴스그룹입니다. 다른 곳에서 운영하는 리눅스용 글라이드 유즈넷
그룹같은건 아직 없습니다. 하지만 다음의 리스트는 주로 DOS, Win9x,
그리고 NT 사용 환경에서 3Dfx 와 글라이드사용에 관한 문제를 다루는
뉴스그룹입니다.
<code>
3dfx.events
3dfx.games.glquake
3dfx.glide
3dfx.glide.linux
3dfx.products
3dfx.test
</code>
3dfx.oem.products.quantum3d.obsidian와 같이, 3dfx.oem.product.*
에는 각각의 보드에 관한 토론이 실립니다. 리눅스 글라이드에 관한
질문은 <url url="http://news.3dfx.com/3dfx.glide.linux" name="news.3dfx.com/3dfx.glide.linux"> 에서 해 주십시오.
뉴스그룹대신 메일링 리스트를 사용 하는 것도 한가지 방법이겠습니다.
</P>
<sect1>리눅스버전 글라이드를 다루는 메일링리스트
<p>
리눅스 글라이드와 리눅스에서 3Dfx 칩셋사용방법을 전용으로 다루는
메일링 리스트가 나와 있습니다. <url url="mailto:majordomo@gamers.org" name="majordomo@gamers.org">에게 주제란은
비워놓고 이메일 내용란에 info linux-3dfx and help 라고 해서 이메일을
보내주십시오. 이메일리스트에 기고하는 방법과 하이퍼메일 아카이브,
그리고 메일링리스트 구독에 관한 안내문이 보내질 것입니다. 질문이
메사, 혹은 메사/글라이드 인터페이스에 관한 것이라면 해당되는 메일링
리스트에 질문을 해 주시기 바랍니다.
</P>
<sect1>프로그램버그는 어떻게 보고합니까?
<p>
현재로서는 위의 뉴스그룹에 프로그램의 버그 보고를 해 주십시오.
(주소: <url url="http://news.3dfx.com/3dfx.glide.linux" name="news.3dfx.com/3dfx.glide.linux">) 리눅스용 글라이드에 관한
지원 이메일계정이 아직은 존재하지 않습니다. 리눅스용 글라이드에 관한
질문이 아니라면 다른 뉴스그룹에 질문을 해 주시기 바랍니다.
</P>
<sect1>리눅스용 글라이드는 누가 관리하고 있습니까?
<p>
3Dfx에서 곧 공식 관리인을 지정할 것입니다. 현재로서는 Daryll
Strauss씨께서 비공식적으로 리눅스용 글라이드 포트를 관리하고
있습니다. 버그는 위에 나온 뉴스그룹에 보고를 해 주시고, 버그가 새로
찾아진 것이라고 확신이 서는 경우에는 <url url="mailto:daryll@harlot.rb.ca.us" name="daryll@harlot.rb.ca.us">로
이메일을 써 주시기 바랍니다.
</P>
<sect1>리눅스버전 글라이드에 기여하는 방법
<p>
버그를 보고하실 때 정확하게 써서 보내 주시는 것과, 직접 프로그램을
만들어서 배포판에 포함되게 하는 것으로 기여를 하실 수 있습니다. 또
글라이드를 기반으로 하는 메사 부두 드라이버 소스코드를 쓰는것은 아주
커다란 도움이 되겠습니다. 밑에 있는 메사 부두 섹션을 참조하시기
바랍니다.
</P>
<sect1>글라이드 이외의 다른 프로그램을 사용 할 수 없습니까?
<p>
현재로서는 부두그래픽(tm) 드라이버는 글라이드 밖에는 없습니다.
그리고 글라이드는 하드웨어를 직접제어하는 유일한 인터페이스입니다.
하지만 글라이드 드라이버의 한계와 버그에대해 주의를 하시는게
좋겠습니다. OpenGL코드는 글라이드에 에 관한 아무런 지식이 없이도
프로그래밍을 할 수 있습니다. 글라이드를 기반으로 하는 메사 부두
드라이버용으로는 메사를 사용 할 수 있겠습니다.
</P>
<sect1>글라이드 API로만 프로그래밍이 가능합니까?
<p>
글라이드는 3Dfx에서 제조한 3Dfx칩을 사용하는 하드웨어전용
API입니다. 글라이드 API를 사용하는 여부는 개발하고자 하는
애플리케이션이 수행하고자 하는 작업에 달려있습니다. 글라이드는 다른
API에서는 찾을 수 없는 독자적으로 존재하는 기능들과 더불어 OpenGL과
메사에 있는 몇몇 기능을 포함하고있습니다.
만약 OpenGL API를 사용하고 싶다면 메사를 사용할 것을 권장합니다.
(밑을 참조하세요.) 메사 부두드라이버인 메사는 문서화가 매우 잘되어
있고 널리 사용되는 OpenGL API와 비슷한 API를 제공합니다. 하지만 메사
부두드라이버는 초기개발단계에 있는 관계로 사용시의 기능저하와 몇몇
기능에서의 지원이 되지 않는다는것을 감안해야 합니다.
결론을 말하자면, 글라이드API를 사용하고 안하고는 프로그래머가
결정해야 할 사항이라는 것입니다. 3Dfx이외의 3D 가속기 하드웨어에로
포팅할때 생길 수 있는 문제에 대해 상관치 않는다면 최고의 성능을 얻을
수 있는 글라이드를 선택하는것도 나쁜 결정은 아닙니다. 하지만 프로그램
의 관리에 더 신경을 쓸거라면 OpenGL이 장기적인 안목에서 좋은 선택일
것입니다.
</P>
<sect1>글라이드의 최신버전은 무엇입니까?
<p>
현재의 리눅스용 글라이드 버전은 2.4 입니다. 차기 버전은 지금
나와있는 DOS/Windows의 버전을 따라서 2.4.3이 될 것입니다.
2.4.3버전은 두가지로, 부두러쉬(tm)용, 부두그래픽(tm)용인지에 따라
다른 배포판이 제공됩니다. 리눅스에서도 부두러쉬(tm)用,
부두그래픽(tm)用으로 글라이드가 제공이 될 것입니다. 차후에 발표될
부두2 (tm)보드에서도 별도로 추가된 코드가 있을것이며 추가된 코드
에따른 별도의 바이너리배포판이 있을 것입니다.
현재 삼각형 fan과 삼각형 strips, 그리고 상태변형기능을 향상한
글라이드 API 3.0이 준비되고 있습니다. fan 과strips의 지원은 삼각형
하나당 필요한 입력자료의 양을 경우에 따라서는 크게 줄이는 것도
가능합니다. OpenGL API는 이것을 위해 별도의 모드를 사용하기때문에
메사 드라이버의 기능도 향상시킬 것입니다. 자세한 내용은 OpenGL문서를
참조하시기 바랍니다.
</P>
<sect1>글라이드에서 복수Texelfx를 지원합니까?
<p>
복수의 Texelfx/TMU 는 컴퓨터의 성능에 영향을 미치지 않고 이미지의
상태를 크게 향상시키는 싱글패스 trilinear mipmapping는 리눅스용
글라이드에 벌써 사용이 되고 있습니다. 두개의 Texelfx를 사용하는
보드(퀀텀3D옵시디안 보드중에서 찾아보세요.)를 사용하면 이 기능을 사용
할 수 있습니다. Texelfx를 두 개 사용하는 것은 자동적으로 설정이 되지
않기 때문에 애플리케이션에서 명시되어야 하는 사항입니다. 보통
나와있는 애플리케이션에서 사용하는 보드가 Texelfx를 하나만 사용한다는
가정하에 쓰여졌기때문에 보통은 두번째의 Texelfx가 있는지 물어보지도
않는 경우가 있겠습니다. 두개의 Texelfx를 사용할 수 있는 여건이
하드웨어에서 지원이 되더라도 사용하는 애플리케이션이서 이를 이용할 수
없다면, 이건 글라이드의 버그가 아니라 애플리케이션에서 아직 Texelfx를
두개 사용하는것을 지원하지 않기때문입니다.
</P>
<sect1>리눅스용 글라이드와 DOS/Windows용 글라이드는 똑같습니까?
<p>
현재 공개된 리눅스용 글라이드는 도스/윈도즈용의 글라이드와
같습니다. 하지만 리눅스용의 글라이드의 배포는 도스/윈도즈용 글라이드
보다 늦을 수도 있습니다.
</P>
<sect1>글라이드에 관한 기타 정보는 어디에서 얻을 수 있습니까?
<p>
3Dfx에서 "모든" 정보를 얻을 수 있습니다.
<url url="http://www.3dfx.com/software/download_glide.html" name="www.3dfx.com/software/download_glide.html"> 에서 유저가 3Dfx를 기반으로
한 보드를 소유하고 있다는 조건하에 무료로 다운로드를 받을 수있습니다.
다운로드를 받기전 라이센스의 제반사항을 읽어주시기 바랍니다. 그리고
다음의 리스트를 참조하는 것도 글라이드에 관한 정보를 얻는데 도움이
되겠습니다.
<itemize>
<item>글라이드 배포 참고사항
<item>글라이드 프로그래밍 가이드
<item>글라이드 참고 매뉴얼
<item>글라이드 포팅 가이드
<item>TexUs 텍스쳐 유틸리티 소프트웨어
<item>ATB 배포 참고사항
<item>옵시디안 설치와 사용
</itemize>
이 리스트에 나온 화일들은 마이크로소프트의 워드화일로 되어있으며
이며, 윈도즈 글라이드 배포판설치시 자동으로 압축이 풀리게
되어있습니다. 포스트스크립트 버젼은 <url url="http://www.3dfx.com" name="www.3dfx.com">에서 다운로드를 받을
수 있습니다. 이 화일들의 배포버전은 해당되는 글라이드의 버젼과
동일하지 않을 수도 있습니다.
</P>
<sect1>글라이드를 사용하는 데모프로그램은 어디에서 얻을 수 있나요?
<p>
데모프로그램의 소스코드는 테스트프로그램이라는 이름으로 글라이드
배포판에 포함되어있으며, 3Dfx의 홈페이지에서도 구할 수 있습니다.
3Dfx에서 구할수있는 프로그램중 몇몇은 실행을 위해 ATB를 요구하기도
합니다. 이 데모프로그램들을 리눅스로 포팅을 하기 위해서는 소스코드
에서 이벤트핸들링부분이 다시 쓰여져야 합니다.
메사와 GLUT에는 제법 괜찮은 OpenGL 데모프로그램의 소스코드가
따라옵니다. 글라이드의 API와 OpenGL의 API는 다르기는 하지만, 둘다
같은 하드웨어 렌더링 파이프라인을 사용합니다.
</P>
<sect1>ATB란 무엇입니까?
<p>
3Dfx의 몇몇 글라이드용 데모프로그램은 글라이드와 아직은 리눅스로
포팅이 안된 3Dfx 아케이드 툴박스(ArcadeToolBox - 도스/윈32용)를 같이
필요로 합니다. ATB의 소스코드는 Total Immersion 프로그램에서 구할 수
있으므로 ATB의 리눅스포팅에 관심이 있으신 분은 참조하시기 바랍니다.
</P>
<sect>무엇이든 물어보세요: 글라이드와 XFree86?
<sect1>XFree86환경에서 글라이드의 실행이 가능합니까?
<p>
우선 알아야 할 사실은, 부두 그래픽(tm)의 하드웨어의 사용은
XFree86과 상관이 없다는 것입니다. VGA카드의 비디오입력신호가 3D가속기
를 통해서 모니터의 출력을 나타낼 경우에도 X 서버에서는 VGA카드에서
나오는 비디오입력신호가 디스플레이에 가는지 알아채지 못합니다.
애플리케이션이 X의 이러한 환경을 고려하지 않고 쓰였다면 글라이드가
그래픽모드를 바꾸는데 문제가 생길 수 있습니다. (문제해결하기 부분을
참조해주세요.) X11의 이러한 환경에 하나하나 신경쓰기 싫다면 SVGA
콘솔모드를 사용하는것으로도 간단하게 해결됩니다.
XFree86에서의 조건을 따라주면 글라이드 API를 사용한 애플리케이션의
실행이 XFree86의 환경에서 실행이 가능합니다. 메사에서의 "윈도우 해킹
-window hack"을 사용하면 풀스크린을 사용하는 것보다는 상당히
느려지지만 소프트웨어로 렌더링을 하는것보다는 훨씬 빠릅니다.
</P>
<sect1>글라이드를 사용한 애플리케이션은 풀스크린모드에서만
실행가능합니까?
<p>
바로 위 8.1을 참고해 주세요. 부두그래픽(tm)은 윈도우를 사용하는
환경을 고려하지 않고 디자인이 되었기때문에 글라이드도 이 하드웨어의
때문에 기능이 제한이 됩니다. 밑에서 다룬 메사의 "윈도우 해킹"은
아직은 초기개발단계이기는 하지만 부두그래픽(tm)에서 발생한
프레임버퍼의 내용을 X11의 윈도우로 복사하게 해 줍니다.
</P>
<sect1>AT3D와 부두 러쉬(tm) 사용문제
<p>
부두러쉬(tm)는 독자적으로 VGA카드겸 2D/3D가속기기능을 하거나
부두러쉬(tm)을 다른보드에 붙여서 사용하도록 설계가 되었기때문에
리눅스와는 근본적인 호환성문제가 있습니다. VGA보드부분은 Alliance
Semiconductor의 프로모션-AT-3D멀티미디어 가속기의 칩셋을 사용하기
때문에 부두러쉬(tm)카드를 XFree86환경에서 사용하려면 AT3D칩셋의
리눅스용 드라이버가 필요합니다. 부두러쉬(tm)카드의 사용시 일어날 수
있는 문제를 토론하는 메일링리스트가 존재하며, www.frozenwave.com
/linux-stingray128 에서는 계속해서 최신소식을 업데이트해 주며 FAQ를
개제합니다. AT3D의 드라이버는 SuSe에서 관리하고 있으며, 이
드라이버의 위치는 ftp.suse.com/suse_update/special/xat3d.tgz 입니다.
여러 유저들의 경험담을 빌면, 부두러쉬(tm)는 XFreeSVGA서버로 8, 16
그리고 32 bpp모드로 돌릴 수 있다고 합니다. 공식적인 지원은 XFree4.0
에서나 가능한 모양입니다. XFree86측에서는 부두러쉬(tm)의 사용문제가
해결이 되었다고 생각되는 XFree86 3.3.2의 테스트용 배포판을 계획하고
있습니다. 부두러쉬(tm)를 사용하려면 다음의 XF86Config세팅을 시도해
보십시오.
<code>
# device section settings
Chipset "AT24"
Videoram 4032 (역자주: 이거 오타가 아닌가요? 4096아닌가??)
# videomodes tested by Oliver Schaertel
# 25.18 28.32 for 640 x 480 (70hz)
# 61.60 for 1024 x 786 (60hz)
# 120 for 1280 x 1024 (66hz)
</code>
결국, XFree86용 드라이버가 완성이 되지 않았다는 사실을 빼면
부두러쉬(tm)을 사용못할 이유는 없습니다.
부두러쉬(tm)를 기반으로하는 그래픽카드에서는 기존의 비디오램(!)을
비디오램用, 2D/3D 가속기의 back 버퍼 및 z 버퍼用으로 같이 사용합니다.
(역자주: 다목적 비디오램이라 하면 맞을까요?) 이렇게 여러가지
목적으로 비디오램이 사용되기때문에 XFree86에서도 이것을 인식을 해
주어야 합니다. 이런 메모리할당과 메모리잠금문제는 3Dfx제품의 디자인
의 문제로 일어나는 것이 아니라 TV 캡쳐카드의 지원같은 사항에도
해당되기 때문에 XFree86팀에서도 계속적으로 이에대한 연구를 하고 있는
상황입니다. 현재 XFree86 DGA(Direct Graphic Access, 다이렉트 그래픽
액세스 - 선마이크로시스템즈와 XFree86에서 표준을 합의보지 못한 관계로
최종적으로 발표될 X11R6.1의 표준에 포함되지 않아 포팅이
불가능합니다.)의 확장으로서 사용되는 X 레벨(혹은 XAA)의 소스코드를
바꾸는 것을 의미합니다. 이 소스코드의 변경은 차후에 개발될 XFree86
GLX에 들어갈 가능성이 있습니다. 현재 배포되는 X서버는 유저가
프레임버퍼를 모두 제어하는것이라 가정하여 직접적인 비디오출력에
관련된 프레임버퍼이외에는 모두 pixmap 캐쉬(글꼴캐쉬같은거...)로
사용합니다.
</P>
<sect1>XFree86용 GLX에 관한사항
<p>
여기에는 몇가지 문제점이 있습니다. 현제 지원되는 부두그래픽(tm)
하드웨어와 리눅스용으로 포팅이 된 리눅스글라이드는 풀스크린 모드만
지원하며 프레임버퍼를 윈도우환경과 공유하도록 설계가 되어있지
않습니다. 그러므로 GLX 혹은 X11의 다른 부분과 통합환경으로 사용하는
것은 아직은 불가능합니다. 부두러쉬(tm)는 XFree86 SVGA 서버를
사용하는 방법으로 XFree86에서 사용하는것이 가능할 지도 모르지만
부두러쉬(tm)은 아직 리눅스용 글라이드에서 지원이 안되며 S3같은
XFree86서버에서도 지원을 하지 않습니다. 리눅스의 경우에 GLX는 메사에
의존합니다(보통은 OpenGL입니다.). XFree86팀은 현재는 메사를 X서버와
통합시키는데 작업을 하고 있습니다. GLX는 아직은 베타버젼인 관계로
XFree86은 GLX와 연결하는 부분만 작업이 끝났습니다. Steve Parker
(스티브 파커)씨의 <url url="http://www.cs.utah.edu/~sparker/xfree86-3d/" name="www.cs.utah.edu/~sparker/xfree86-3d/"> 와
<url url="ftp://ftp.sigkill.org/pub/XFree86/opengl/" name="ftp.sigkill.org/pub/XFree86/opengl/">를 참조해 주세요. 그리고
XFree86과 SuSe에서 같이 작업중인 GLX부분은 <url url="http://www.suse.de/~sim/" name="www.suse.de/~sim/"> 를
참조해 주세요. 현재로서 리눅스 환경에서 메사는 GLX에뮬레이션을
사용하고 있습니다.
</P>
<sect1>글라이드와 상업용 X서버
<p>
글라이드와 메사를 상업용 X 서버에서 사용하는 것에 관한 이메일을
필자는 아직 받아보지 못했습니다. 글라이드와 상업용 X서버관한 사항을
저에게 이메일을 보내주시면 감사하겠습니다. 특히 상업용 GLX를 지원하는
상업용 X서버에서의 메사와 글라이드의 사용에 관한 것이라면 더욱 환영
합니다.
</P>
<sect1>글라이드와 SVGA
<p>
글라이드를 사용하는 애플리케이션은 모니터를 하나를 사용하던 두개를
사용하던 VGA모드로만 한다면 아무런 문제가 없을것입니다. 만약 모니터를
하나만 사용한다면 SVGA모드에서 640x480해상도로 설정해서 사용하는것도
괜찮은 방법입니다.
</P>
<sect1>글라이드와 GGI
<p>
글라이드용 GGI드라이버는 Jon M. Taylor씨께서 개발을 하고 있지만
공식적으로 배포가 되지 않았으며 GGI 0.0.9의 완성때까지 배포계획은
없습니다. GGI에 관한 정보는 <url url="http://synergy.caltech.edu/~ggi/" name="synergy.caltech.edu/~ggi/"> 를 참조해
주십시오. 만약 관심이 있다면 XGGI (GGI를 기반으로하는 XFree86용
X서버) 프로젝트에 뛰어드는것도 괜찮을 것 같습니다. 가속기를 사용하지
않는 메사 환경에서 테스트가 된GGI드라이버가 존재하기는 합니다. 이
GGI드라이버는 OpenGL API를 인터페이스로 사용합니다. 알맹이만
말하자면, 이건 메사, 혹은 글라이드용해서 부두그래픽(tm) 에서 바로
X11R6를 사용한다는 겁니다.
</P>
<sect>9. 무엇이든 물어보세요: OpenGL과 메사
<sect1>9.1. OpenGL은 무엇입니까?
<p>
OpenGL은 Iris GL을 바탕으로 SGI에서 개발되어 몇년전에 산업계표준
으로 굳은 그래픽 프로그래밍 API입니다. 현재 OpenGL은 SGI, IBM, DEC,
그리고 마이크로소프트같은 회원을 포함하는 Architectural Revision
Board (ARB - 아마 설계감독위원회쯤..?)에서 정의(definition)하고
관리합니다. OpenGL은 2차원 및 3차원 그래픽제어에서 필요로 하는
기능을 모두 제공합니다. 그리고 이것은 삼각형 및 다각형의 렌더링을
구사하는 파이프라인구조의 하드웨어에서의 가속환경에서 이루어집니다.
넓은 의미에서 본다면, OpenGL은 하드웨어가속을 사용하는 컴퓨터그래픽을
위한 막강한 도구라고도 할 수 있겠습니다.
</P>
<sect1>OpenGL에 관한 추가정보는 어디서 얻을 수 있습니까?
<p>
OpenGL의 공식사이트는 ARB의 멤버들이 공식적으로 관리하며, 주소는
<url url="http://www.opengl.org" name="www.opengl.org">입니다. 가장 추천할 만한 웹사이트는 Mark Kilgard씨의
"Gateway to OpenGL Info"라는 곳으로 주소는 <url url="http://reality.sgi.com/mjk_asd/opengl-links.html" name="reality.sgi.com/mjk_asd/opengl-links.html"> 입니다. 이 사이트는 참고서적으로의 포인터, 온라인
매뉴얼 페이지, GLUT, GLE, 메사, 다른 OS로의 포팅, 그리고 많은수의
데모와 툴을 제공합니다. OpenGL을 사용한 게임프로그래밍에 관심이
있다면 <url url="mailto:Listserv@fatcity.com" name="Listserv@fatcity.com">를 통해 받아볼 수 있는 <url url="mailto:OpenGL-GameDev
-L@fatcity.com" name="OpenGL-GameDev-L@fatcity.com"> 메일리스트에 참여하시기 바랍니다. 주의할 사항은, 이
리스트에서는 상당히 많은 수의 고급기술내용 메일이 오가기 때문에
하루에 거의 100통씩 오는 이메일을 관리하기 위해 procmail을 사용하는게
좋습니다. SET OpenGL-GameDev-L DIGEST명령어를 사용해서 밴드폭을
낮추는 것도 한 방법이 되겠습니다. 이 리스트는 OpenGL을 처음 배우는데
에 사용하기에는 알맞지 않습니다. 이메일리스트에서 다루어졌던 내용은
ListServ 프로그램으로 관리가 되기 때문에 INDEX OpenGL-GameDev-L,
그리고 GET OpenGL-GameDev-L "filename" 명령어를 사용해서 구독하기
이전에 무슨내용인지 보는것도 좋습니다.
</P>
<sect1>글라이드는 OpenGL응용 소프트웨어입니까?
<p>
아닙니다. 글라이드는 부두그래픽(tm)과 부두러쉬(tm)에만 있는 기능을
사용하는 3Dfx社의 전용 API입니다. 3Dfx에서 사용할 수 있는 OpenGL은
아직 준비중에 있습니다(밑의 섹션을 참조하세요). 글라이드의 몇몇
기능은 OpenGL로의 확장이 필요하며 일부는 글라이드에 이미 도입이 되어
있습니다. ( paletted textures 같은것.) 리눅스용 OpenGL과 제일 비슷한
것은 Brian Paul의 메사와 David Bucciarelli의 메사부두드라이버가
있습니다.
</P>
<sect1>3Dfx에서 만든 OpenGL드라이버가 있습니까?
<p>
3Dfx와 퀀텀3D의 웹사이트에서는 모두 부두그래픽(tm)용 OpenGL을 97년
사사분기에는 사용할 수 있게 하겠다고 합니다. OpenGL드라이버는 아직은
베타버젼으로만 있으며, 등록된 개발자에게만 문서로 명기된 베타테스트
계약에 동의함으로써 사용허가가 나옵니다. 리눅스용으로 포팅을 하는지
에 대한 여부는 발표되지 않았습니다.
</P>
<sect1>3Dfx, 리눅스에서 사용할 수 있는 상업용 OpenGL드라이버같은게
있습니까?<p>
상업용 OpenGL에서 부두그래픽(tm)을 지원하는지에 대해서는 잘
모르겠습니다. 이전에 알아보았을 때에는 MetroX와 XInside OpenGL 둘다
3Dfx와 리눅스의 지원을 하지 않았습니다.
</P>
<sect1>메사는 무엇입니까?
<p>
메사는 Brian Paul씨가 OpenGL API를 이용해서 설계/코딩을 해주시고
다른 많은분들이 도와주셔서 만든 무료 애플리케이션입니다. 성능도 꽤
괜찮은 편이며 아직 공식적으로 인증이 되지는 않았지만 ARB에서 규정한
OpenGL의 규격과 거의 완벽하게 호환이 됩니다. 기존의 상업용 프로그램과
비교하더라도 훨씬 나은 완성도를 자랑합니다.
</P>
<sect1>메사와 3Dfx와의 호환성은 어떻게 됩니까?
<p>
메사의 최신배포판인 MesaVer는 리눅스용 글라이드 2.4에서도 작동
합니다. 글라이드의 지원은 이전의 버전에서도 포함이 되었었지만 메사는
아직도 개발단계에 있기때문에 버그가 있거나 최상의 성능이 나지
않을수도 있다는 것을 염두해 두어야 합니다. 메사는 계속해서 향상되고
있고 버그들도 빨리 고쳐지고 있습니다.
메사 라이브러리를 다음의 FTP 사이트에서 얻어야 할 것입니다. (<url url="http://iris
.ssec.wisc.edu" name="iris.ssec.wisc.edu">) 버그찾기나 하드웨어/드라이버의 제한사항에 관한 내용에
관심이 있으면 메일링리스트에 구독하시기 바랍니다. 메일리스트의 토론에
참여하기 이전에 최신 배포판을 사용하는것을 확인해 주십시오.
현재로써는 메사-3.0 이 준비중에 있습니다.
</P>
<sect1>메사와 글라이드의 포팅 유연성
<p>
메사를 기반으로 한 애플리케이션은 보통 리눅스와 윈32용으로
나와있지만 사용되는 XWindow, Windows, GLX 혹은 WGL같은 시스템마다
최적화된 코드가 있을것입니다. 만약 GLUT나 qt를 사용한다면 시스템에
따른 특정셋업에 대한 염려는 하지 않아도 됩니다. 상대적 마우스움직임
샘플링 같은 작은 문제점들이 따르기는 하겠지만 지금까지 나와있는
GUI툴킷에서는 그런 문제를 다루지 않습니다.
메사와 글라이드는 도스용으로도 나와있습니다. 32비트 도스용으로
나온 메사와 글라이드는 Charlie Wallace씨가 관리해주시며 메사의
메인베이스의 최신판과 늘 버전을 맞추어 주셔 왔습니다. 도스용 메사와
글라이드의 최신판은 <url url="http://www.geocities.com/~charlie_x/" name="www.geocities.com/~charlie_x/"> 에서 다운로드받을
수 있습니다.
</P>
<sect1>메사에 관한 정보는 어디에서 얻을 수 있습니까?
<p>
메사의 홈페이지는 <url url="http://www.ssec.wisc.edu/~brianp/Mesa.html" name="www.ssec.wisc.edu/~brianp/Mesa.html"> 입니다.
<url url="http://www.iqm.unicamp.br/mesa/" name="www.iqm.unicamp.br/mesa/"> 에서는 메사 메일링리스트에서 다루어졌던
내용을 저장하고 있습니다. 이 메일링리스트는 3Dfx와 글라이드의 문제만
다루는 곳이 아니지만, 3Dfx 하드웨어에서 메사의 사용법에 대해 알고
싶다면 여기에서 시작하는게 좋습니다.
</P>
<sect1>메사 부두에 관한 정보는 어디에서 얻을 수 있습니까?
<p>
메사부두드라이버에 관한 최신정보는 <url url="http://www.hmw.caribel.pisa.it/fxmesa/" name="www.hmw.caribel.pisa.it/fxmesa/">
에서 보실 수 있습니다. 관리자는 David Bucciarelli 씨로,
tech.<url url="mailto:hmw@plus.it" name="hmw@plus.it">가 연락처 입니다.
</P>
<sect1>메사에서 멀티 텍스쳐링을 지원합니까?
<p>
메사 2.6에서 멀티텍스쳐링은 지원이 안되지만 차후 발표될 메사
3.0에서는 지원이 될 예정입니다. 메사 3.0에서는, 디바이스 드라이버
에서 제공하는 익스텐션을 advertise 할 수 있게 할 것입니다. 하나, 혹은
두개의 TMU를 사용하는것은 부두그래픽(tm)과 부두2(tm)용 메사에서
런타임동안 테스트가 될 것입니다.
OpenGL EXT_multitexture의 사용이 가능하면 OpenGL 1.2 개정판에서
명시된 것처럼 유저는 OpenGL EXT_multitexture익스텐션을 사용해야
합니다. 메사 3.0에서는 분리된 텍스쳐좌표 세트와 현재텍스쳐환경
블렌딩 모드를 지원하는 GL_SGIS_multitexture 익스텐션을 사용합니다.
하지만 이 작업은 미완성단계에 있습니다. OEM 지원의 acknowledgement
섹션을 참조하세요.
</P>
<sect1>메사에서 싱글패스 trilinear mipmapping를 지원합니까?
<p>
single pass trilinear mipmapping용으로 복수의 TMU를 사용해야 성능을
저하시키지 않고 이미지 품질을 향상시킬 수 있습니다. 현재의 리눅스
글라이드버전에서는 벌써 이 기능이 도입되어 있습니다.
메사 2.6에서 아직 이기능은 지원하고 있지 않지만 메사 3.0에서는 이
기능을 지원하도록 준비하고 있는 단계입니다. (위의 멀티텍스쳐링을 참조
하세요.) 염두해야 할 사항은, single pass trilinear mipmapping 과
multitexturing은 서로 상호배타적 관계라는 것입니다. 유저는 두개의
텍스쳐를 싱글패스로 블렌드를 하던지, 아니면 두개의 mipmap
resolution을 사용해서 levelsfull trilinear mipmapping 해야 합니다.
이것을 모두 합쳐서 사용하려면 하나의 파이프라인에 두개 이상의 Texelfx
가 필요합니다.
</P>
<sect1>메사의 "윈도우해킹"이란 무엇입니까?
<p>
메사의 최신판은 리눅스의 XFree86에서 실험적으로 사용되는 기능으로
윈도우해킹을 구현합니다. 우선, 메사에서 사용되는 GLX 에뮬레이션은
부두그래픽(tm)보드에서 바로 사용된 프레임버퍼의 내용을 glXSwapbuffer
콜을 따라 비디오 메모리에 복사를 합니다. 이 기능은 윈도즈용 메사
에서도 사용가능합니다. 여기에서 XFree86 DGA가 비디오메모리를 제어
하는것때문이 아니라 X11 MIT SHM이 사용용됨으로써 PCI에 더욱 무리를
주게 됩니다. 이와같은 방법은 이론적으로는 SVGA와 같은 환경에서도
도입될 수 있습니다. 이렇게 함으로써 부두그래픽(tm)의 보드가 윈도우
에서 가속된 렌더링을 하는데 사용될 수 있고, 유저는 VGA패스스루(pass
through)모드를 사용하지 않아도 된다는 장점이 있습니다.
패스스루방법을 사용하면 VGA카드의 출력신호의 품질이 나빠지게 됩니다.
이것은 EIZO F784-T같은 고급모니터에서 특히 잘 보입니다.
이 윈도우해킹은 부두러쉬(tm)에서는 지원이 안됩니다. 윈도우해킹은
아직 실험단계에 있으며 부두그래픽(tm)을 기반으로 한 보드에만 지원이
되는 사항입니다. 또, 윈도우 관리 시스템과 이벤트는 드라이버가 아닌
애플리케이션이 관리하므로 유저는 이상황에 맞추어 변경된 GLUT를
사용해야 합니다.
다음의 환경변수가 사용이 되는지 확인해 주십시오.
<code>
export SST_VGA_PASS=1 # 비디오시그널 전환을 멈춤.
export SST_NOSHUTDOWN=1 # 비디오시그널 전환을 멈춤.
export MESA_GLX_FX="window" # 메사 윈도우모드의 초기화.
</code>
만약 여기의 SST 변수중 어느 하나라도 빠트린다면 VGA카드는 다운이
되고 디스플레이의 제어를 잃게 됩니다. (X는 이렇게 디스플레이가 먹통이
되더라도 아직은 제어가 가능합니다.) 화면에 아무것도 안나올 때에
원상복구를 하기란 상당히 까다롭습니다. 끝으로, libMesaGL 라이브러리
는 복수의 클라이언트 인터페이스를 포함할 수 있습니다. 예를 들자면,
GLX, OS메사, 그리고 fxMesa, SVGA메사의 인터페이스콜은 모두
libMesaGL.a 하나의 화일로 컴파일이 될 수 있습니다.
클라이언트프로그램은 이들을 자유로이 사용할 수 있으며, 주의만 한다면
이들을 동시에 사용할 수도 있습니다.
</P>
<sect1>GLUT이란 무엇입니까?
<p>
Mark Kilgard씨의 GLUT 배포판에는 샘플 애플리케이션과 함께 괜찮은
유틸리티가 여럿 포함이 되어있습니다. GLUT는 <url url="http://reality.sgi.com/mjk_asd
/glut3/" name="reality.sgi.com/mjk_asd/glut3/"> 에서 구할 수 있습니다. 최신판은 GLUT 3.6이며, GLUT 3.7
(GameGLUT로 알려져있음)에 대한 토론이 진행되고 있는 상황입니다.
최근에 Mark Kilgard씨가 SGI를 떠났으므로 GLUT을 구할 수 있는 장소의
주소가 바뀔 수도 있습니다. 하지만 아직까지는 SGI에서 다운을 받을 수
있습니다.
GLUT의 메일링리스트는 <url url="mailto:glut@perp.com" name="glut@perp.com">입니다. 다음을 이메일의 내용란
에 넣어서<url url="mailto:majordomo@perp.com" name="majordomo@perp.com">에 메일을 쓰시면 됩니다.
<code>
help
info glut
subscribe glut
end
</code>
GLUT는 더블버퍼, 윈도우, 이벤트, 그리고 하드웨어와 운영체제와
묶어진 작업을 제어하기 때문에 부두그래픽(tm)에서 GLUT를 사용하는것은
현재 메사용 GLX의 내부에서 개발이 되고있는 지원이 필요합니다. 하지만
GLUT는 웬만한 환경에서는 잘 작동합니다.
</P>
<sect>무엇이든 물어보세요: 퀘이크!!!
<sect1>퀘이크의 3Dfx GL 드라이버
<p>
미니드라이버, 또는 미니포트, 아니면 게임 GL, 아니면 3Dfx GL로
알려진 3Dfx Quake GL는 퀘이크전용 OpenGL 서브셋을 도입했습니다.
(지원되는 코드패스의 비공식 리스트는 <url url="http://www.cs.unc.edu
/~martin/3dfx.html" name="www.cs.unc.edu/~martin/3dfx.html"> 를 참조해 주십시오.) 지금 이사이트는 관리도
안되고 있으며 업데이트도 이루어지지 않고 있습니다. 퀘이크용 3Dfx
GL은 3Dfx가 배포를 한 윈32의 DLL 이었으며 (opengl32.dll), 윈도즈
전용버전만 있습니다. 이 DLL 화일은 리눅스로 포팅이 되지 않을 계획
입니다.
</P>
<sect1>리눅스용 glQuake에서 3Dfx를 지원합니까?
<p>
메사와 글라이드를 기반으로 한 리눅스용 퀘이크 v0.97의 바이너리화일
이 배포가 되었습니다. 리눅스와 부두그래픽(tm)을 지원하는 퀘이크2의
q2test 바이너리 화일도 배포가 되었습니다. 리눅스용 퀘이크2의 풀버전
은 linuxquake2-3.10을 시작으로 1998년 1월에 출시되었습니다. 현재의
linuxquake2-3.13배포판은 메사기반 OpenGL 렌더링을 합니다. Dave
Kirsch씨 (이메일주소: <url url="mailto:zoid@idsoftware.com" name="zoid@idsoftware.com">)가 새로 나온 메사용으로
포팅포팅된 퀘이크, 퀘이크월드, 그리고 퀘이크2의 공식 관리자입니다.
리눅스로 포팅이 된 퀘이크는 메사기반을 포함해 모두 id Software에서
공식지원이 안됩니다. <url url="ftp://ftp.idsoftware.com/idstuff/quake/unix/" name="ftp.idsoftware.com/idstuff/quake/unix/">를 보시면
최신 배포판을 찾을 수 있습니다.
</P>
<sect1>glQuake는 XFree86 윈도우에서 실행이 됩니까?
<p>
메사 개정판과 메사기반 리눅스glQuake2가 준비중에 있습니다. 메사는
XFree86윈도우 실행을 GLX를 사용해서 구현하고 있지만 glQuake2는 현재
로서는 GLX를 사용하지 않습니다. 리눅스퀘이크(Q1)이 윈도우에서 실행이
되도록 업데이트가 될것인지에 대해서 아직 필자가 아는 정보는 없습니다.
그리고, glQuake2를 X11/XFree86의 윈도우에서 잘 지원하도록 만들어진
라이브러리가 있습니다. 그 라이브러리의 README를 보면,
"이 라이브러리의 목적은 퀘이크에 의해 사용되는 svgalib/fxMesa
기능을 에뮬레이션 하는데 있습니다. 이 qkHack 라이브러리라고 불리는
이 에뮬레이션 라이브러리는 렌더링스크린을 셋업하고 마우스/키보드입력
을 받기위해 GLX/X11 API를 사용합니다. 유저는 풀스크린렌더링과 윈도우
렌더링을 그저 탭키를 누르는 것으로 전환할 수 있습니다. (X 서버가
16bpp 모드에서 돌아가고 있어야 이 기능을 사용할 수 있습니다.) "
이 라이브러리는 XFree86에서 사용되는 DGA를 제공함으로써 윈도우해킹
프레임버퍼복사를 가속시키고, 또 윈32스타일의 마우스사용을 지원합니다.
이 라이브러리는 David Bucciarelli 의 <url url="mailto:tech.hmw@plus.it" name="tech.hmw@plus.it">에 의해 관리가
되며 <url url="http://www.hmw.caribel.pisa.it/fxmesa/" name="www.hmw.caribel.pisa.it/fxmesa/">에서 이 라이브러리를 찾을 수
있습니다.
</P>
<sect1>glQuake가 크래쉬를 하면 비디오모드를 어떻게 리셋합니까?
<p>
글라이드배포판에 포함되어있는 프로그램 "pass"를 사용해 보십시오.
이 프로그램은 카드를 열었다가 닫는데에 목적이 있습니다. 만약 카드가
컴퓨터와 정보교환이 가능하면 리셋을 해야 합니다. 만약 크래쉬가 심하게
되어있다면 이 프로그램도 할 수 있는게 없으며, 그때에는 리부팅을
하는수 밖에 없습니다.
</P>
<sect1>지금까지 알려진 리눅스퀘이크의 문제점
<p>
1998년 1월 7일자로 옮겨온 부분입니다. 3Dfx 하드웨어와 관련되지 않은
문제는 포함시키지 않았습니다.
<itemize>
<item>SVGALib이나 GL렌더를 사용할 때에 퀘이크2는 root 아이디로 실행을
시켜야 합니다. X11에서 리프레쉬를 하기위해 root계정이 아니어도
되지만, 이때 사용하는 계정에서는 마우스와 사운드디바이스에 읽기
/쓰기가 가능해야 합니다. 그리고 전용서버의 경우에는 별도의 허가
(permission)가 필요하지 않습니다.
<item>X11에서 로딩을 할때에 화면에 잡음이 생길 것입니다.
16비트칼라모드에서 이것은 정상적인 현상입니다.
X11은 24비트에서 작동하지 않습니다. 16비트이든 24비트이든 상당히
느릴 것입니다.
<item>GL렌더러에서 크래쉬가 생기는 경우가 있습니다. 이럴때엔 퀘이크2와
따라온 libMesa를 설치했는지 꼭 확인해 주십시오! 오래된 libMesa는
제대로 작동하지 않습니다.
<item>만약 GL렌더러의 비디오에 랙(lag)이 있다면 (화면이 마우스가 움직인
다음에야 움직이는 것처럼 보일경우) "gl_finish 1"이라고 콘솔에
쳐주십시오. 이 명령어는 프레임당 기준으로 화면을 업데이트하게 해
줍니다.
<item>GL렌더러를 실행시킬때에는, selection, gpm을 죽였는지 확인해
주십시오. 이들이 살아있다면 퀘이크2가 GL모드에서 실행될때 마우스
가 먹통이 될 것입니다.
</itemize>
</P>
<sect1>지금까지 알려진 리눅스퀘이크의 보안 문제점
<p>
Dave Kirsch씨께서 1998년 1월 28일 써주신대로, "리눅스에서 퀘이크2
완벽하게 사용하기"가 출판이 되었씁니다. 퀘이크2는 공유되는 라이브러리
를 사용합니다. 현재까지 나온 퀘이크2의 README에서 별도로 명시하지는
않지만 퀘이크2는 setuid여서는 안된다는것을 유의하십시오. 만약
ref_soft와 ref_gl 렌더러를사용하고 싶다면 퀘이크2는 root계정으로 실행
해야 합니다. 바이너리 setuid는 만들지 마십시오. 이 렌더러들은 콘솔
에서만 실행시킬 수 있으며 실행하는 계정이 root인지 아닌지에는 신경을
안써도 됩니다. /dev/dsp가 root이외의 계정에서 쓰기가 가능하다면
X11렌더는 root의 허가가 필요하지 않습니다. 그리고 전용서버모드도
당연히 root의 계정으로 실행하지 않아도 됩니다. 게임에서 root를
사용해야 한다는 요구사항은 리눅스에서 해결되야할 문제로 오랫동안
남아있습니다. 이 문제는 GGI같은 곳에서 목표로 할 해결사항입니다.
ref_ggi가 머지않아 지원이 될 수도 있습니다.
</P>
<sect1>리눅스용 glQuake에서 멀티텍스쳐링을 사용합니까?
<p>
필자가 알기로는, glQuake이나 퀘이크2는 사용되는 OpenGL드라이버가
제공을 하면 멀티텍스쳐 확장을 사용할 것입니다. 현재 리눅스에서
메사와 글라이드 드라이버는 이 확장을 지원하지 않기 때문에 지금으로서
멀티텍스쳐링에 대한 답은 "아니오"입니다. 메사와 멀티텍스쳐링에 관한
섹션에 자세한 내용이 나와있습니다.
</P>
<sect1>리눅스에서 glQuake실행에서 부두러쉬(tm)이 사용가능합니까?
<p>
아직은 사용할 수 없습니다. 차후에 나올 XFree86 3.3.2배포판에서는
리눅스용 글라이드를 바탕으로 부두러쉬(tm)기반 보드를 사용하는데
필요한 사용자 설정기능을 제공할 계획입니다. gl퀘이크나 gl퀘이크2같은
게임은 부두러쉬(tm)서는 풀스크린으로만 실행되지만 프레임버퍼를
비디오메모리에 복사하는 대신 페이지플립을 이용함으로써 향상된 성능을
발휘합니다.
</P>
<sect1>리눅스용 gl퀘이크에서 부두2(tm)을 지원합니까?
<p>
위의 섹션을 참고하세요. 부두2(tm)의 특징은 멀티텍스쳐링을 사용
하는게 되겠습니다. John Carmack씨에 따르면 "멀티텍스쳐를 사용하려면
일부의 텍스쳐는 반대의 TMU이여야 합니다. 퀘이크의 경우에는 환경텍스쳐
전부가 바닥TMU에 있어야 하며 라이트맵 역시 모두 상부의 TMU에 있어야
합니다. 모델스킨은 바닥TMU쪽이던 상부TMU쪽이던 상관이 없지만 이과정
에서 최적의 결과가 나오지 않기때문에 패킹을 잃는 현상이 생길수 밖에
없습니다." 라고 합니다.
</P>
<sect1>어디에서 리눅스 gl퀘이크에대한 정보를 얻을 수 있을까요?
<p>
다음의 사이트를 방문해 보세요. "The Linux Quake Resources -
리눅스퀘이크정보"는 linuxquake.telefragged.com에서, "Linux Quake Page
- 리눅스 퀘이크 페이지"는 <url url="http://www.planetquake.com/threewave/linux/" name="www.planetquake.com/threewave/linux/">입니다.
그리고 리눅스퀘이크사이트는 "SlipgateCentral
- 슬립게이트 센트럴
"데이터베이스, <url url="http://www.slipgatecentral.com" name="www.slipgatecentral.com">에서 찾아 볼 수 있습니다.
</P>
<sect>이럴땐 어떻게 해야하지요? 문제해결!
<sect1>내 하드웨어는 테스트가 된 것들입니까?
<p>
웨의 "하드웨어요구사항"부분을 참조해 주세요. 보드에 따른 특정문제
따위가 발견되지 않은까닭에 필자는 현재 제조업체나 보드의 리스트를
해서 가지고 있지 않습니다. 현재로서는 3Dfx와 퀀텀3D만이 개발자들을
위해 보드를 테스트용으로 제공하고 있으므로 이 업체들의 보드를
사용하는것이 안전하다 할 수 있겠습니다. 부두그래픽(tm)카드라면 다
작동할 것입니다. 현재로서 필자는 Orchid Righteous 3D, Guillemot Maxi
3D Gamer, 그리고 Diamond Monster 3D 가 사용가능하다는 연락을
받았습니다.
부두그래픽(tm), 부두러쉬(tm), 그리고 부두2(tm)보드가 차기에 발표될
리눅스, XFree86, 리눅스 글라이드/메사와 호환이 되는지 확인하고 싶은
제조업체들은 필자를 연락해 주시면 시스템드라이버를 관리하는 이들에게
기꺼이 제가 연락을 해 드리도록 하겠습니다. 리눅스 글라이드를 PC이외의
플랫폼(DEC Alpha따위)에서 지원하는데에 관심이 있으시다면 리눅스
글라이드 관리자 Daryll Strauss씨를 연락해 주시면 되겠습니다. (이메일
주소: <url url="mailto:daryll@harlot.rb.ca.us" name="daryll@harlot.rb.ca.us">)
</P>
<sect1>I/O 권한을 바꿀수가 없는데요.
<p>
root 계좌에서 글라이드를 사용하는 애플리케이션을 setuid로 설정해
주시기 바랍니다. DMA에 관해서는 /dev/mem을 제어하는데 root만 쓰기가
가능합니다. (그런 이유가 있음.) 리눅스용 글라이드 배포판의 README를
참조하시기 바랍니다.
</P>
<sect1>root 의 권한이 없이도 사용 할 수 있나요?
<p>
setuid 를 필요로 하는게 심각한 문제가 되는 경우가 있습니다. 이에
대한 대책은 라이브러리 내부를 의 변경을 필요로 하는데, 현재 준비중에
있습니다.
</P>
<sect1>싱글 스크린 셋업에서 모니터의 이미지가 이상하게 보입니다.<p>
만약 패스스루(pass-through)의 비디오입력데이터가 아날로그라면
보통의 SVGA나 X11의 화질은 상당히 떨이지게 됩니다.
액셀러레이터카드와 따라온 연결케이블보다 더 나은 케이블을 구해도
되지만 트랜스미션이 보태지고 어느정도의 시그널을 잃어버리는 것은 어쩔
수 없습니다. (다이아몬드 몬스터 3D에 따라오는 케이블은 오키드
라이쳐스 3D의 케이블보다 안좋다고 합니다.) 만약 액셀러레이터보드에서
나오는 640x480 풀스크린 이미지의 화질이 안좋다면 이것은 진짜로
액셀러레이터카드 하드웨어의 문제일 수도 있습니다. 비디오출력 데이터의
질은 액셀러레이터 자체의 문제가 아니라 제조업체가 선택한 램댁과 출력
드라이버, 그리고 다른 부품에 달려 있기 때문에, 칩제조업체인 3Dfx에게
문의를 하지 마시고 가지고 있는 액셀러레이터의 제조업체를 연락하십시오
</P>
<sect1>최종프레임이 아직도 화면에 남아있습니다. (싱글/더블스크린
셋업)<p>
유저가 Ctrl-C를 눌러서 애플리케이션을 끝냈거나 정상적인 방법으로
빠져나오지 않았을 때 이런 일이 생깁니다. 끝내라는 명령이 없었던
이유로 액셀러레이터는 아직도 착실하게 프레임버퍼에 있는 현재내용을
모니터에 출력하고 있는 것입니다.
</P>
<sect1>생각치도 않았던 전력절약기능이 가동이 됩니다. (더블스크린
셋업)<p>
두개의 모니터를 사용하는 환경에서 애플리케이션이 끝날 경우
액셀러레이터 카드는 비디오 출력을 더이상 제공하지 않습니다. 그러므로
전력절약기능이 작동하는 것입니다. 이것을 피하려면 다음의 명령어를
써 보십시오.
<code>
setenv SST_DUALSCREEN 1
</code>
</P>
<sect1>(X11, 모니터 하나 사용) 컴퓨터가 아예 멈춰버립니다. <p>
글라이드 애플리케이션을 실행시작할때 X환경이었다면 마우스를 윈도우
구간 밖으로 움직여서 키보드입력이 애플리케이션에 도달하지 않는경우일
것입니다.
만약 사용중인 애플리케이션이 X11과 동시에 사용되게 되어있다면
풀스크린 윈도우를 사용하거나, XGrabPointer와 XgrabServer기능을 사용해
X서버가 화면을 제어하지 못할때에 모든 입력을 사용중인 애플리케이션
으로 돌리게 하는게 좋은 방법입니다. 들어오는 입력을 모두
XGrabPointer와 XGrabServer로 잡아채는것은 시스템전체를 멈추게 할수
있으므로, 이것은 않좋은 애플리케이션의 디자인을 뜻합니다.
이문제가 X를 실행하고 있지않았는데도 일어났다면 하드웨어충돌이
없는지 확인해 주십시오. (밑을 참조해 주세요.)
</P>
<sect1>컴퓨터가 멈춰버려요. (싱글/더블스크린 셋업)<p>
만약 시스템이 어떤 입력에도 반응을 하지 않는다면 작은 하드웨어
충돌이 일어나고 있을 가능성이 높습니다. (모니터를 두개 사용한다면
포커스유실에 대해 알아야 합니다.) 여기에 대한 내용은 설치문제 해결
섹션을 참조해 주십시오.
만약 어드레스충돌이 보이지 않는다 하더라도 다른 문제들이 아직 존재
하고 있을 가능성이 있습니다. (밑을 참조해 주세요.) 만약 유저가 직접
프로그램을 썼다면 꼭지점각을 닫지 않았을 수도 있습니다. 글라이드 문서
에서 스냅에 관한 섹션을 참조해 주세요.
</P>
<sect1>(S3 VGA카드 유저) 컴퓨터가 아예 멈춰버립니다.<p>
S3 비디오카드에서 쓰는 전용 메모리영역이 겹쳐있을 가능성이
높습니다. 이 S3의 문제에 대한 정보와 패치는 3Dfx웹사이트에 있지만
윈도즈버전만 나와있습니다. 필자가 알기로는 이 메모리 오버랩 문제는
S3보드 (다이아몬드 스텔스 S3 968의 옛 개정판)가 실제로 사용되는
것보다 더 많이 메모리를 예약해 놓기 때문에 부두그래픽(tm)이 다른
위치에 매핑이 되아 하는 현상이 생깁니다. 하지만 이것은 리눅스에서
문제가 되었다고 들은적이 없으며, 윈도즈에서만 해당되는 것일지도
모릅니다.
</P>
<sect1>어드레스 충돌은 없지만 컴퓨터가 멈춰버립니다.<p>
만약 사용하는 마더보드가 표준을 따르지 않는다거나 PCI불완전하게
지원한다면 보드의 셋업을 바꾸어 보십시오. 필자의 ASUS TP4XE보드는
비표준인 "미디어 슬롯"(PCI 슬롯4에 ASUS가 제조한 SCSI/사운드 콤포카드
의 커넥터를 연결한것. 다이아몬드 몬스터 3D를 그 슬롯에 넣고 컴퓨터를
돌리면서 심각한 문제들을 경험했습니다. 다이아몬드 몬스터 3D 를 다른
보통슬롯에 꽃고나서는 아무런 문제가 발생하지 않았습니다.)이란걸 사용
합니다.
</P>
<sect1>메사는 실행되지만 액셀러레이터 카드를 제어할 수 없습니다.<p>
툴킷과 데모프로그램들이 사용하는 라이브러리(GLUT는 부두그래픽(tm)을
아직 지원하지 않습니다!)를 포함한 모든 라이브러리를 다시 컴파일
해보십시오. 그리고는 원래있던 라이브러리를 새것으로 교채한후
ldconfig을 실행하고 LD_LIBRARY_PATH를 알맞게 설정해 설정해 주십시오.
메사는 복수의 드라이버를 병렬로 사용하는것을 지원하므로 (예를 들면,
X11 SHM, 오프 스크린 렌더링 그리고 메사부두를 동시에 사용할 수
있습니다.) 부두그래픽(tm)이 기본카드가 아니라면 유저는 MakeCurrent
함수를 이용해 상관관계를 구체적으로 설정해 주어야 합니다.
</P>
<sect1>VGA와 액셀러레이터를 따로 쓰는데, SLI리셋을 어떻게 하나요?<p>
만약 퀀텀 3D 옵시디안보드용 SLI셋업에서 갑자기 빠져나와 버리면
(애플리케이션의 크래쉬나 유저가 멈춘 경우) 액셀러레이터카드는
불분명한 상태로 남게 됩니다. 듀얼보드 세팅에서는 resetsli라는
프로그램을 사용해서 이 카드들을 리셋할 수 있습니다. resetsli를 실행
하기 이전에 유저는 사용하는 옵시디안보드를 재초기화 할 수가 없습니다.
</P>
<sect1>VGA + 액셀러레이터 통합보드를 쓰는데, SLI리셋을 어떻게
하나요<p>
위에서 말한 restsli프로그램은 아직 옵시디안 100-4440SB 와 같은
싱글보드 옵시디안 SLI에서 작동하지 않습니다. 시스템을 리부탱해서
보드를 리셋하는 수 밖에 없습니다.
</p>
</article>
|
How you look depends on where you go.    
|
