Войти
ФлеймФорумЖелезо

Блеск и нищета 32/64-битных консолей и ПК (3 стр)

Страницы: 1 2 3 4 58 Следующая »
#30
12:43, 3 ноя. 2017

typedef enum PrimitiveType {
            kPrimitiveTypeNone = 0x00000000,
            kPrimitiveTypePointList = 0x00000001,
            kPrimitiveTypeLineList = 0x00000002,
            kPrimitiveTypeLineStrip = 0x00000003,
            kPrimitiveTypeTriList = 0x00000004,
            kPrimitiveTypeTriFan = 0x00000005,
            kPrimitiveTypeTriStrip = 0x00000006,
            kPrimitiveTypePatch = 0x00000009,
            kPrimitiveTypeLineListAdjacency = 0x0000000a,
            kPrimitiveTypeLineStripAdjacency = 0x0000000b,
            kPrimitiveTypeTriListAdjacency = 0x0000000c,
            kPrimitiveTypeTriStripAdjacency = 0x0000000d,
            kPrimitiveTypeRectList = 0x00000011,
            kPrimitiveTypeLineLoop = 0x00000012,
            kPrimitiveTypeQuadList = 0x00000013,
            kPrimitiveTypeQuadStrip = 0x00000014,
            kPrimitiveTypePolygon = 0x00000015
        } PrimitiveType;

а говорили что quad вырезали


#31
7:53, 5 ноя. 2017

Nintendo 64

Nintendo 64 вышел в 1996-ом году и стал конкурентом вышедшей двумя годами ранее Playstation 1.
Центральным процессором в системе был тоже MIPS, но уже на базе 64-битного R4300i на 94МГц. Шина адреса, впрочем была урезана до 32 бит, что логично, ибо 64-битные целочисленные операнды вообще практически не использовались. Повышенная битность тут была больше маркетинговой, чем реальной небходимостью.
В качестве первого сопроцессора у него стоял так же как и в PS1 контроллер виртуальной памяти, а вот вторым был сопроцессор с плавающей точкой (которого у PS1 просто не было).
Встроенной в консоль основной RAM было 4Мб причём она могла расширяться до 8Мб посредством слота расширения. Отличительной особенностью было то, что байт в этой памяти был 9-битным, правда это мог увидеть и использовать только чип растеризации (RDP), который использовал эти биты для стенсиля (см. ниже). Остальные компоненты системы читали и писали байты только как 8-битовые значения. Еще одна особенность - встроенные 4Мб памяти физически находились на двух разных микросхемах по 2Мб каждая и тот же растеризатор мог работать с ними в параллельном режиме, поэтому, к примеру, официально рекомендовалось располагать фреймбуфер в нижних 2Мб, а Z-буфер - в верхних.
Так что в целом и по битности ЦП и по его частоте и по наличию плавающей точки Nintendo 64 была посовременнее PS1, временная фора свою роль сыграла.
Как мы знаем в N64 Nintendo сделала тогда уже непопулярный шаг и в качестве накопителя информации выбрала не оптические диски, а картриджи.
Неожиданным лично для меня оказался тот факт, что в глубоком отличии от консолей предыдущих поколений ROM картриджа больше не мапилось в основное адресное пространство процессора вообще никак.
ROM картриджа стало в N64 ничем иным, как внешним хранилищем к которому обращение идёт через DMA-каналы. Причина этого кроется видимо в крутом повышении частот доступа к основной RAM при которых дешевая ROM картриджей стала сильно отставать - до сотни раз (5 Мб/сек чтения типичного медленного ROM против ~500 у RAM).
В итоге картридж из полноценного ROM стал не более чем внешним накопителем - с быстрым случайным доступом, конечно (и в целом быстрым), но всё же просто внешним накопителем. Так, при старте консоли в RAM копируется первый мегабайт картриджа и в него передаётся управление.

RCP

Интересно, что в Nintendo 64 центральную роль в системе играет видеочип - причём сам он по себе является многокомпонентной величиной.
Для того чтобы сделать унифицированную RAM и не разделять банки графической и основной ОЗУ в итоге было сделано так, что ЦП обращался к RAM через видеочип.
И вообще все пути-дорожки сходились именно на видеочипе - как общение с периферией, так и общение хоть с памятью хоть с картриджем как видео, как геймпада, как и звука - всё шло через видеочип.
Он получается становился каким то южным мостом в одном флаконе и точкой, где встречались все компоненты системы.
Весь видеочип в целом назывался RCP (Reality CoProcessor), при этом его можно было поделить на несколько больших и слабо зависимых компонент:
- VI (Video Interface) - просто выводит какой либо прямоугольный блок пикселей из любого места в RAM на видеовыход системы, допустимые битности цвета - 16 бит (1:5:5:5) и 32 бита (RGBA).
- RDP (Reality Display Processor) - растеризатор от SGI. Рисовал графические примитивы вполне в духе трёхмерных видеокарт своего времени (без T&L) в целочисленных координатах screenspace выполняя некий буфер команд. Для текстурирования у этого чипа было выделено 4Кб специализированный памяти под текстуры (TMEM), которые во многом были узким местом всей консоли - даже на фоне PS1 кадры из лучших игр N64 выглядят мыльновато.
- RSP (Reality Signal Processor) - еще один базированный на MIPS R4200 процессор на 62МГц, уже без сопроцессора с плавающей запятой, зато с неким SIMD-сопроцессором опять таки для решения задач T&L с регистрами с фиксированной точкой, формат и состав дополнительных команд которого, однако нигде я так и не смог нарыть толком.
RSP тоже обладал двумя собственными специализированными банками памяти - IMEM и DMEM - каждый опять же по 4Кб. В первом хранились инструкции для RSP, а во втором - данные. Что-то там было такое опять таки в сопроцессоре RSP, что это было два разных банка памяти.
Важно, что с основной RAM RSP мог общаться только посредством своего DMA-канала, всю обработку он должен был проводить внутри этих крошечных 2x4Кб памяти. Заниматься он должен был задачами T&L и процессинга звука. Судя по всему - во втором качестве очень редко, т.к. с этим мог справится и ЦП.
А вот с графикой всё и так было в притык. Nintendo со старта консоли выпустила несколько "прошивок" (массивов "микрокодов"), которые ЦП должен был загружать в IMEM, чтобы использовать мощь RSP.
Первая из прошивок называлась Fast3D - это основная к использованию вещь, с большей частью и как правило точных функций. Но надо заметить, что координаты все тут были в screen-space и либо целочисленные, либо с фиксированной точкой после запятой. Так, например, ни координаты треугольника ни их разности по модулю не должны были превышать 32767, такое могло бы привести к глюкам обработки точки.
Вторая прошивка называлась Turbo3D - в ней была снижена точность обработки вершин и вырезаны многие фичи: обрезка по фруструму, освещение, перспективная коррекция текстур, стек матриц.
Третий микрокод - Line3D умел почти всё то же что и Fast3D, но рисовал не треугольники, а линии для wireframe.
Кроме того каждый микрокод был представлен еще в трёх вариантах того как он выдавал результирующие команды в растеризатор RDP. Первый - через собственный крохотный FIFO-буфер в собственной DMEM. Второй - через FIFO-буфер в RAM (имеет смысл размер от 1Кб). Третий вариант заливает все команды в один большой буфер в RAM не передавая его в RDP, чтобы это мог сделать ЦП по своему усмотрению.

Использовать RSP предполагалось по следующей схеме:
а) ЦП создаёт в памяти списки команд - это потенциально древовидные последовательности инструкций для RSP (до 10 уровней вложенности, т.к. одна из инструкций переходит к другому списку инструкций, а по его завершению возвращается обратно, стек возвратов при этом имеет глубину 10).
б) ЦП загружает в RSP микрокод под формат списка и передаёт указатель на первую инструкцию какого либо списка в RSP для начала обработки. В сущности списки команд содержат команды специфичные для того или иного микрокода - он их парсит и обрабатывает по заданному в IMEM алгоритму.
в) RSP начинает обрабатывать список команд - выполнять T&L, обрезку выпавших за камеру полигонов и т.п., формируя в итоге список команд для RDP и передаёт его собственно в RDP через порты ввода-вывода или DMA.
В силу ограниченности размеров IMEM/DMEM следует упомянуть как осуществлялась обработка и отрисовка вершин. Стандартные микрокоды размещали в DMEM массив из 16 вершин с рассчитаными атрибутами - команды в RSP рисующие треугольники содержали лишь индексы этих обработанных вершин (0-15). Загрузка в этот массив вершин осуществлялась отдельной командой загрузки из RAM вершин, которая тут же и рассчитывала трансформации им и освещение. Таким образом не могло идти подряд много команд отрисовки треугольников, если у всех них было больше 16 разных вершин - нужно было чередовать команды загрузки вершин и рисования треугольников порциями по не более чем 16 вершин между загрузками.

Таким образом в N64 мы можем говорить уже не только о полноценном, вынесенном из основного ЦП блока рассчёта T&L, но и о его изначальной полноценной программируемости - банк данных IMEM заполнялся в полной концептуальной аналогии с вершинными шейдерами.
Однако тут происходит нечто странное для меня - в первые годы после выхода консоли Nintendo никому не раскрывало формата команд RSP и его внутреннего устройства - предполагалось, что разработчики будут пользоваться только предложенными производителем банками IMEM распространяемыми с SDK в виде массивов байтов.
Ни инструментария, ни описания - ничего не было, поэтому разработчики так и поступали. При этом 4Кб под IMEM и 4Кб под DMEM действительно наступали на горло - так, например, банки Fast3D и Turbo3D не умели рисовать линии, отчего банк Line3D распространялся рядом с ними же.
Так что долгое время всё ограничивалось только тем, что Nintendo выпускало патчи к имеющемуся микрокоду и дополняло набор из трёх микрокодов какими то новыми - например был выпущен микрокод S2DEX для отрисовки двумерной графики/спрайтов.
И только под закат уже консоли Nintendo поспособствовала и несколько разработчиков внедрили свои коды в RSP, заточенные под их движки и форматы вершин - и это (по их словам) действительно сыграло в жирный плюс.

Списки команд подаваемые в RSP формировались в официальном API как правило как просто массив из макро-определений. Они были очень похожи на команды отдаваемые в RDP уже под растеризацию, собственно нередко просто повторяли их для простоты системы. Это были как правило 8-байтовые (64-битные) блоки байт, первый хранил код инструкции, а остальные - параметры (если они были, бывало и без параметров). Если параметров было много, блок мог увеличиваться с гранулярностью в те же 8 байт.

#32
7:54, 5 ноя. 2017
+ Для справки можно рассмотреть что же скармливалось в конце концов собственно растеризатору - RDP...

Забавным еще показалось отношение RDP к текстурированию - одним из глобальных стейтов RDP является "режим рендера". Режимы заливки и копирования предназначены для 2D-графики (при этом всё-равно в качестве источника битмапов выступает TMEM), а вот полноценные 3D-треугольники требуют уже режимов или 1-cycle или 2-cycle. В 1-cycle обрабатывается 1 тексель на пиксель - в качестве источника цвета может быть только одна текстурная выборка. В режиме 2-cycle же может производится до двух текстурных выборок на пиксель. Забавно, что билинейная фильтрация текстур тоже абсолютно попадает под это определение - выборка из двух слоёв разных мипмапов требует режима 2-cycle. Соответственно режим мультитекстурирования (точнее - битекстурирования) уже несовмпестим с мипмапами, структурно это в N64 одна и та же фича двойной текстурной выборки.

Операционная система

Много внимания в официальной документации Nintendo уделяется операционной системе - так что нельзя не сказать пару слов о ней.
Как они сами пишут "ОС получилась столь маленькая, что мы даже не дали ей названия". Вообще она распространяется не как обычная ОС, а как просто набор статических библиотек на C/C++ и полностью попадает на картридж.
Поэтому линкер вполне себе выкидывает неиспользуемые куски "оси" по факту компиляции. Ось даже не предоставляет менеджеров памяти - предполагается что игры работают в Kernel Mode и имеют прямой доступ в память.
Тем не менее ОС предполагает и большую ставку делает на вытесняющую многозадачность. При этом единственный механизм синхронизации - очереди сообщений, приписанные к каждому потоку в системе. Никаких семафоров или критических секций - потоки просто футболят друг другу сообщения, засыпая когда их не остаётся и просыпаясь, когда другой поток или ОС подкидывает новых.
Должен быть, к примеру, самый неприоритетный "idle thread", который дёргается когда перестают выполнятся любые другие потоки. Поэтому много вещей в API сделано в асинхронном стиле, документация прямо настаивает на том, чтобы приложение состояло из многих потоков, нагружающих друг друга сообщениями, чтобы возникало минимум простоев графического конвеера и тому подобное.
Вообще по официальной документации видно, что создатели консоли уже бережно ограждают разработчиков от необходимости лазить грязными пальцами в порты ввода-вывода - API внушительное, покрывает все аспекты и прикрывает аппаратную начинку достаточно плотно.

Итоги

Подводя итоги - судя по всему Nintendo 64 мог бы заметно обогнать Playstation 1 по перфомансу и качеству картинки, если бы не родовые недостатки с форматом накопителя (максимум 64 Мб картриджа), зажатостью документации на RSP и всего 4Кб текстурной памяти. Это всё многое смазало, в прямом и переносном смыслах. Тем не менее в своём поколении консоль была вполне себе конкурентноспособна и подарила игрокам много замечательных игр.

#33
12:20, 5 ноя. 2017

Особенным фейлом был Резидент,  с муками и болью всунутый в картридж. Без видео.

#34
16:59, 5 ноя. 2017

Pathetic Mike
> с муками и болью всунутый в картридж

Меня по сему поражает, что за долгие годы они эту технику ROM-картриджа не только не забросили, но и только оттачивали.
Если на телевизионных консолях N64 таки показал ху из ху и следующая консоль от нинтендо - GameCube вышла уже на дисках, то хендхелды продолжали выходить на картриджах.
если рассмотреть уже 32-битные, то получается вот как росли их предельные объёмы:
Game Boy Advance - 32 Мб
Nintendo DS - 512 МБ
Nintendo 3DS/2DS - 8 Гб
и вуаля, далее выходит уже Switch, который и телевизионная и портативная консоль в одном флаконе и тоже имеет картриджи, которые все начали лизать за невыносимо горький вкус. Максимально заявленный объём уже 32 Гб, а это уже больше однослойного блурея (25 Гб).

Причём в GBA картридж реально маппился в адресное пространство ЦП, а значит как минимум в режиме совместимости с GBA это происходило и в Nintendo DS. Но вот я стопудово уверен, что в Switch картридж так же как и в Nintendo 64 никуда не мапится, а просто используется как твердотельный постоянный накопитель.
Забавно всё это, забавно.

#35
17:31, 5 ноя. 2017

да грустновато всё это: создают технологии и закрывают их, просирая тем самым полимеры. С другой стороны если компании до сих пор живы, то ни о какой продаже себе в убыток или по себестоимости речи идти не может

#36
18:21, 5 ноя. 2017

clc
Я вообще не понял, что ты хотел сказать. Создали, заработали, выкинули. Как еще-то? Какие полимеры? Они же не носиляторы из совка.

#37
19:21, 5 ноя. 2017

lookid
> Какие полимеры?

Ну есть в этом известная доля истины.
Консоль получилась не совсем удачной - и технические просчёты сейчас уже хорошо видны.
Так например, согласно англовики: https://en.wikipedia.org/wiki/Nintendo_64_programming_characteristics

Когда N64 подошла к концу своего жизненного цикла глава отдела по аппаратной разработке Genyo Takeda ссылался на трудности программирования используя японское слово hansei ("признание недостатков - первый шаг к исправлению"). Оглядываясь назад Такеда сказал "Когда мы делали N64 мы думали, что было логично то, что делать игры технически более навороченными должно быть технически более трудно. Но мы ошибались. Теперь мы понимаем, что главное - (стабильная) крейсерская скорость, а не мощные, но короткие рывки вперед.

Тут еще наслаивается и опоздание на 2 года по сравнению с основным конкурентом - PS1 и первые ласточки для Nintendo полетели. В этом поколении они заняли второе место на рынке. В то время как предыдущие два поколения (8-битное и 16-битное) уверенно держали пальму первенства.
И далее, как мы знаем, они сместились на третье место, правда в целом и это большое достижение, ибо сейчас и осталось всего 3 заметных консоледержателя. Гораздо больше других проиграло борьбу.
Так что в каком то смысле N64 для Nintendo действительно эдакий символ - начало конца доминирования с несмертельными, но просчётами.

#38
20:08, 5 ноя. 2017

вообще это было брюзжание о том, что корысть губит хорошие разработки

#39
20:18, 5 ноя. 2017

clc
> вообще это было брюзжание о том, что корысть губит хорошие разработки
Я так понял, что это критика решения Nintendo не публиковать информацию нужную для кастомизации RSP своим "микрокодом" длительное время. Возможно они думали, что все и так слишком сложно. Но блин, свой микрокод это же фактически программируемые вертексные шейдеры. Трюк реально работал в нескольких играх под закат консоли. Причем судя по всему чисто под личные тесные отношения с особыми разработчиками, ибо я так и не смог нагуглить конкретики никакой про внутренности RSP, т.е. эти знания до сих пор - элитны.

#40
20:35, 5 ноя. 2017

ну да, без софта любой чип кусок инновационного говна. Ну и зачем разработчикам топить за что-то новое если это им не принесёт бабла (в рамках купи-продай)? Ну и пришли к pc-подобным платформам. Плохо или хорошо, а какая разница - по другому-то никак.

#41
20:50, 5 ноя. 2017

clc
Ну так и пк впитал то по итогу эти "ноу-хау", в виде командных буферов и не только спервпециализированных чипов под T&L, но и возможность их перепрограммировать.
Это предвосхищает пк лет на 10.
Так что в том что на архитектуре пк клин сошелся нет на мой взгляд удивительного, она впитала все лучшее и дешевое.

#42
21:15, 5 ноя. 2017

вывод: жадность кратно замедляет прогресс (потому-что 10 лет) :)

#43
11:55, 6 ноя. 2017

Ну что же, накачал в обед документаций по легендарной PS2, следующей пройдусь по ней. Не уверен даже, что после неё на что либо хватит сил - уж слишком много документации получается.
Штучка не только легендарная, но и уже только по поверхностному описанию в вики выглядит интересной. Emotion Engine, my ass... Уже просто мельком, проверяя что файлы открываются и читаются, увидел, что векторный модуль VU0 мог работать под управлением ЦП как его сопроцессор, а мог "отсоединятся" и шпарить как отдельный процессор с собственной очередью команд. Уже интригует!

#44
17:34, 6 ноя. 2017

Хехехе, PS2 не разочаровала - уже с первых овервью системы и принципов заложенных в рендер она уделывает по экзотичности и PS1 и N64 вместе взятые. %) Прикольная штука, забавная...

Страницы: 1 2 3 4 58 Следующая »
ФлеймФорумЖелезо