LINUX.ORG.RU

Ответ на: комментарий от anonymous

Это называется типа "для чего писали уникс"... сервер (твой комп для игр :) + терминалы (несколько старых компов, желательно с мегом встроеной памяти и встроеным процессором :), короче i80386 - сама то. Винт не нужен)

anonymous
()
Ответ на: комментарий от anonymous

Да нет, насколько я понял имеется поключение к ОДНОМУ компу (без локалки, т.е. не Х-терминалы), я тоже слышал про такое, типа подобное делали в ребята в физтехе, правда на UNIX. Я понимаю так: 2 видюхи (одна встроенная+внешняя), 2клавы (Ps/2+USB), 2 мыши (аналогично клаве), но если более - то как я думаю, только через расширитель USB, включая доп.мониторы) - Linux сам разберется с подобным зоопарком. А Х-терминалы - довольно простая штука, монтируешь NFS на сервере, аналогично на терминале загрузка по сети и, действительно, даже винта не нужно, а вот чтобы на старом железе погонять WarCraft III все-таки оперативки и видео поставить получше, остальное не критично.

Dynah
()
Ответ на: комментарий от Dynah

Вот интересно, а как на X-терминале, запустить что либо серьезнее xterm, xlogo, etc.? Ведь даже для того чтобы запустить glxgears, нужны GLX расширения. Хотя с коллегами ради интереса запускали вывод mplayer -vo x11 на удаленном x-терминале (486, X on xfbdev), а вот квака 2 с драйвером softx вываливалась при загрузке уровня :) хотя в обратном направлении работала (запущенная на 486, с выводом на более современный комп)

Хотя еще интереснее, если например на 486 поставить навороченную pci видюху (хотя бы radeon 7200/9200, или gf4 mx400), поставить соответствующий X сервер (соответственно получить аппаратный GLX, если конечно не будет того, что дрова используют sse,mmx,etc), понятно, что если на ней локально запустить скажем, хотя бы Quake 3, будут дикие тормоза. А вот если на нее удаленно вывести тот-же Q3 запущенный на каком-нть навороченном компе? Кто-нибудь пробовал?

anonymous
()
Ответ на: комментарий от anonymous

Хотя вот говорят, сей процесс (аппаратный OpenGL рендеринг удаленно) так и будет называться - indirect rendering, и особенно эта вещь не развивается, так как даже для direc renderinga узким местом является pci шина (почему и возникло agp), то при indirect rendering'e даже 100Мбитной сети мало... А на слабом X-терминале (тот-же 486) гигабитную сеть все равно нет смысла устраивать, так как узким местом будет абсолютно все :)

anonymous
()
Ответ на: комментарий от anonymous

Так что вряд ли в WarCraft III можно играть удаленно на слабой машине =) Независимо от количества памяти, и навороченности видюхи

А если юзать гигабитку, то и смысла вовсе нет, так как тот комп который способен не захлебнутся от такой скорости (гигабитки обычно юзаются на pci64, pci-express, или встроены прямо в чипсет, pci32 реже), запросто сможет запустить WarCraft III самостоятельно =)

anonymous
()
Ответ на: комментарий от anonymous

Неверно. Чтобы юзать WarCraft III на Х-терминале нужна такая же видюха как и для обычного варианта, естесвенно, комп должен тоже быть более бодрым, винт вообще можно не использовать, Gigabit-карта не нужна, достаточно обычной 100-ки, а вот сервер должен с большой и быстрой памятью, да и другие показатели оного должны впечатлять. Так что от Х-терминалов в игровом зале выигрыш только в отсутствии винтов, да (а это уже буржуйские шалости) в стоимости программного обеспечения. У меня на работе стоят без дела 2 мэйнфрейма, настоящих IBM S/390, вот если их в LINUX-кластер замутить (впрочем достаточно и одного,но так прикольнее), хочу на них WarCraft III + Х-терминалы (псевдо) на обычных компах замутить, если получиться скажу :)))

Dynah
()
Ответ на: комментарий от Dynah

Да не получится на чем-то меньшем гигабитной сети играть в W3. Люди пробовали Quake3 на 100Мбит - ~10fps, при том, что на той-же машине локально фпс было в 10 раз больше.. При удаленном opengl - по сети идет весь glx трафик, а это не хухры мухры...

anonymous
()
Ответ на: комментарий от Dynah

А чего, гадать, запустим bc, и посчитаем =)

Допустим хотим удаленно поиграть в W3, по сетке 100Мбит (которой по вашему мнению должно хватить). Возьмем даже самый скромный расклад - разрешение 640x480x16бит. Далее еще более скромно - допустим что нас устроит 25 кадров в секунду. Итого получится, что при пропихивании этой графики в чистом виде, потребуется 640x480x16x25/8/1024=15000 Кб = 14 Мб

Так, а 100Мбит - это 1024^2 x 100 / 8 / 1024^2 = 12Мб

и все это не считая управляющих бит, всяких хедеров, и тп, полезной нагрузки...

Возможно что благодаря indirect renedring графика будет не совсем грубо (в чистом виде) передаваться, а используя всякие хитрые алгоритмы, в виде glx данных например, я не думаю что это особенно снизит нагрузку...

Так что гигабитка нужна.. Но там где гигабитка, можно и напрямую пускать (если есть видюха нормальная с аппаратным opengl, а если таковой нет - то вообще нет смысла), если конечно речь не идет о не x86 архитектуре (как например S/390)...

anonymous
()
Ответ на: комментарий от Dynah

Да, и чтобы понять что об одних вещах говорим. Под удаленным запуском мы понимаем, что приложение, например W3, запущено и выполняется на компьютере1 (тоесть используется его процессор и память), а картинка выводится на компьютере2 (безотносительно, есть ли у него винт или он на nfsroot) и вот тут как раз много трудностей.

А если же просто на компьютере2 подмонтировали удаленную файловую систему и запустили W3 (используя свой проц и память) - то это уже несколько другой случай, и если действительно в компьютере2 есть нормальный проц и видюха, но нет винта, а есть nfsroot - то сложностей никаких нет, это даже скорее вполне нормальное явление.

Тоесть удаленный запуск - это в простейшем примере, когда мы перед запуском приложения, устанавливаем переменную DISPLAY равную адресу удаленного компьютера..

anonymous
()
Ответ на: комментарий от anonymous

>Допустим хотим удаленно поиграть в W3, по сетке 100Мбит (которой по вашему мнению должно хватить). Возьмем даже самый скромный расклад - разрешение 640x480x16бит. Далее еще более скромно - допустим что нас устроит 25 кадров в секунду. Итого получится, что при пропихивании этой графики в чистом виде, потребуется 640x480x16x25/8/1024=15000 Кб = 14 Мб

>Так, а 100Мбит - это 1024^2 x 100 / 8 / 1024^2 = 12Мб

>и все это не считая управляющих бит, всяких хедеров, и тп, полезной нагрузки...

Тут ты не прав, т.к. прога запущена на машине 1, Хсервер на машине 2, а по сети передаётся не изображение монитора, а команды Хсерверу (типа нарисуй окошко, подвинь окошко, тут точку замути , тут линию нарисую и т.д.). Из личного опыта: i386+10Mbit в разрешении 640х480х16цветов не катит: всё очень медленно отрисовывается и по траффику видно, что данные передаются по сети только в момент изменения изображения на мониторе (чем больше изменений, тем больше траффик).

Zak ★★
()
Ответ на: комментарий от Zak

ты забыл добавить - "imho"

Для Х сервера Warcraft III, именно поток точек. Так что неправда твоя.

А вот если речь идет о простеньком xlib клиенте - то да, там скорее всего идут лишь комманды, а не полностью все изображение передается.

Но вот тебе пример - mplayer (вывод x11) проигрывает фильм, что по твоему должен удаленный клиент отрисовывать? Явно _последовательно_ каждую точку кадра. Тоже самое с игрой, тем-более не имеющей отношения к xlib (Warcraft III).

anonymous
()
Ответ на: комментарий от anonymous

Re: Как подключить два монитора

На счёт видео не спорю. Но ведь WarcraftIII это насколько я знаю не софтовый рендеринг, так-что ИМХО по сети будут передаваться текстуры,вершины полигонов и прочая дребедень, а видяха на основании этой информации и выстроит картинку. Также имхо, поток данных не сильно будет зависеть от разрешения (если шпилить в FullScreen), т.к. рендерингом занимается видяха, а не сама программа, и по сети будет передаваться не картинка, а объяснения драйверу OpenGL как эту картинку построить.

Zak ★★
()
Ответ на: Re: Как подключить два монитора от Zak

ага так интересно - сниффим сеть - видим как удаленно кто-то в иксах работает: что вроде - rectangle и координаты вершин и тд. Наверно, можно так подглядывать. перехватывая это дело 8)

WerNA ★★★★★
()
Ответ на: Re: Как подключить два монитора от Zak

Ну выше и было сказано, что для OpenGL скорее всего не совсем грубо будет поток передаваться, но, если подумать, нагрузка то от этого меньше не станет (а то и больше!). Текстуры, вершины, полигоны, "и прочая дребедень" - и все это каждый _кадр_. А ведь речь идет о трехмерном пространстве - тоесть грубо говоря X,Y,Z для каждой вершины, полигона и далее по тексту (то что полигонов в том-же W3 мягко говоря, очень много, это и так понятно). (Это в отличие от того, если бы данные передавались аналогичну сканирующему лучу, тоесть последовательно - передавался бы лишь цвет точки). Возможно (имхо) и используются какие-либо хитрости, навроде того, что если что либо в следующем кадре не меняет своих координат, характеристик, то и соответственно инфа не отсылается, текстуры, допустим где-то кешируются у сервера (видюхи). Но во первых, в W3, все таки постоянно идет какое-то движение. А во вторых, как выше сказано, тому-же Ку3, уже не хватает пропускной способности сети. В третьих зачем тогда АГП, если бы можно было просто ввести вумные алгоритмы, и юзать 3д акселераторы на той-же pci/33мгц, или даже на isa - а все потому-что, полигоны и все остальное очень требовательно по полосе пропускания. Вот..

Так что про гигабитку все верно сказано.

anonymous
()
Ответ на: комментарий от anonymous

Всё можно проверить и на отдельно взятом компе, если отключить расширение Х-сервера "MIT-SHM" (если кто умеет то скиньте сюда как это делается), т.е. прямой доступ к памяти, тогда весь траффик пойдёт через loopback интерфейс и легко посчитается. А одной из причин появления Agp является хранение текстур в оперативной памяти (в видео они не влазят) вот и при каждом кадре они считываются, что тоже создаёт нехилый поток данных.

Zak ★★
()
Ответ на: комментарий от anonymous

Насчет АГП, то что оно появилось, чтобы в ОЗУ хранить текстуры - это да, известная байка :) Даже название у этой фичи есть - AGP DiME (Direct in memory execution), только вот толку от нее практически мало. Даже наоборот, были такие АГП карточки которые были тормознее аналогичных (на том-же чипе) на PCI шине, поскольку к текстурам могли обращаться только по DiME, а шину юзали AGP 1x, и пропускной способности не хватало. Отсюда и повышение скорости AGP, так как пропускной способности всегда становилось мало на определенном этапе.

PS. Только вот сейчас AGP карточки с меньше чем 256Мб на борту за карточки не считаются, а так заглушки для офиса =)

anonymous
()
Ответ на: комментарий от anonymous

Все верно - тема ушла - лучше, знатоки, подскажите человеку как реально 2 и мониторов подключить к ОДНОМУ компу...

Dynah
()

Берёшь видеокарточку с двумя видеовыходами (т.н. "двухголовую"; Matrox
G550, например) или две "одноголовые" карточки для разных шин (AGP и
PCI), клавиатуру PS/2 + клавиатуру USB, мышь PS/2 и мышь USB.

После этого исправляешь /etc/X11/XF86Config-4, добавляешь описания для
видеокарточки(чек), клавиатур и мышей.
Делаешь 2 раздела "Screen" (на каждый монитор) и 2 раздела ServerLayout
(на каждый набор монитор/клава/мышь).

Кусок из моего конфига (2 монитора, 1 клава и 1 мышь):

Section "Screen"
	Identifier	"Left Screen"
	Device		"Matrox MGA G550 First Head"
	Monitor		"Sony F520 Left"
	DefaultDepth	24
	SubSection "Display"
		Depth		24
		Modes		"1600x1200"
	EndSubSection
EndSection

Section "Screen"
	Identifier	"Right Screen"
	Device		"Matrox MGA G550 Second Head"
	Monitor		"Sony F520 Right"
	DefaultDepth	24
	SubSection "Display"
		Depth		24
		Modes		"1600x1200"
	EndSubSection
EndSection

Section "ServerLayout"
	Identifier	"Default Layout"
	Screen		"Left Screen"
	Screen		"Right Screen" RightOf "Left Screen"
	InputDevice	"Microsoft Natural Keyboard Pro"
	InputDevice	"Microsoft IntelliMouse Explorer"
EndSection

anonymous
()
Ответ на: комментарий от anonymous

>Текстуры, вершины, полигоны, "и прочая дребедень" - и все это каждый _кадр_.

да нихуя. Смотря как прогали - если все в конвейер пихали то да, пиздец, а если дисплейными списками то массивы вершин на сервере храниться будут (их для того и придумали)

hooj ★★
()
Ответ на: комментарий от hooj

>а если дисплейными списками то массивы вершин на сервере храниться будут (их для того и придумали)

каком нахер сервере? X-сервере клиента или там, где x-клиент (w3) физически выполняется? Если первое, то смысл - они-же не статически висеть в памяти будут, ими надо _управлять_ - а это те-же самые мегабайты (а если управлять ими локально, то тогда вообще причем здесь сеть, и удаленное исполнение клиента, это уже будет локальное исполнение), если второе - то все равно их надо на клиентскую видюху передавать?

anonymous
()
Ответ на: комментарий от anonymous

Так как же подключить два монитора?

Ладно, всё это прекрасно, но все же, как подключить именно две и более видюхи, два и более монитора?

___________________________________________________________
(Игрушки - соседу в задницу, здесь очень серьёзный вопрос.)

yang_grey
()
Ответ на: Так как же подключить два монитора? от yang_grey

Как тут уже было сказано, ставишь 2 видяхи(agp+pci), 2 мыши (com+ps/2), 2клавы(ps/2+usb) Я сейчас ставлю этот эксперимент, почти всё получилось=) Только у меня нету клавы usb поэтому одна голова осталась без клавы=) Возникла единственная сложность: Я запускаю 2 Х-сервера, для каждой головы свой, и при запуске второго, он себя активирует, переключая консоль на следующую, и => гаснет первая голова.. если как то, где то подправить конфигу (ещё не знаю что), то всё будет прекрасно работать=) В теории, если добыть разветвитель усб, то можно добиться 5-6 голов, в зависимости от кол-ва слотов. Так что неплохое(дешёвое) может быть решение, для какого нибудь маленького офиса=) Или стол с писюком в центр, или удленнители=)

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.