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

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

Страницы: 13 4 5 6 7 8 Следующая »
#75
11:57, 26 дек. 2018

lookid
> PS3/x360 када?

Это поколение у меня уже вызывает мало интереса. Развитие технологий дошло уже до того уровня когда всё железо скрыто для разработчика за толстым толстым слоем API которое на том же ящике довольно слабо отличается от пекашечных реалий. Не вижу смысла там копаться.
Единственное, что вызывает интерес это Cell у PS3, но опять таки уверен, что там всё мощно обмазано API и по сути речь идёт об хитром виде многопоточки. Поэтому вряд ли буду их рассматривать.


#76
13:25, 26 дек. 2018

=A=L=X=
> по сути речь идёт об хитром виде многопоточки
Причем она там странная. Как таковой многопоточки между cell-ядрами вроде как и нет...

#77
(Правка: 13:43) 13:28, 26 дек. 2018

=A=L=X=
> Развитие технологий дошло уже до того уровня когда всё железо скрыто для
> разработчика за толстым толстым слоем API которое на том же ящике довольно
> слабо отличается от пекашечных реалий

Да ну ... x86 сильно отличный от PowerPC

сколько шума было только про load store hit

#78
13:47, 26 дек. 2018

Pathetic Mike
> Как таковой многопоточки между cell-ядрами вроде как и нет...

Я давно уже пытался что-то читать на эту тему и у меня сложилось ощущение, что вся основная идея cell крутится вокруг того, что там несколько микроядер с урезанной системой команд (по сравнению с ведущим ЦП) которые тупо имеют собственные небольшие куски локальной памяти (порядка 64Кб), и гибко настраиваемую шину переброски эти данных между этими ядрами. То ли по кругу, то ли типа того, но главная мощь тут тупо в том, что они не пересекаясь по памяти не блокируют параллельную работу друг друга, а шина устроена так чтобы минимум было помех при, допустим, линейной проброске данных от ядра 0 до 4. Т.е., грубо говоря, речь идёт просто о снятии memory-bandwidth-limit-ов. Ну и типа предполагалось, что всякие cloth-simulation там взлетят выше неба, ибо процу остаётся только выстраивать поток данных в ряд, загружать микрокод в конвеер и дожидаться результатов от последнего ядра.
Вроде бы так там дела обстоят, поэтому, опять таки, хорошо показывает себя на всяких вычислениях с однородными, но большими данными.

innuendo
> сколько шума было только про load hit store

Ну это больше тянет на обзорные статьи по популярным процам, чем по консолям. Но не знаю, пока не тянет, я галопом-по-европам уже давно про большинство известных прочитал и они как то наоборот уже стали все серой массой, где атипичным выглядит уже i386, причём эта атипичность снизилась на 64 битах.

#79
13:11, 7 янв. 2019

Запустить видео по клику - Как делать игрыЗапустить видео по клику - Как делать игры
#80
14:03, 7 янв. 2019

0iStalker
ностальджи, прям как мой первый комп) на материнке с SIMM32-пямятью(8планок по 4мб), VLB-шиной для видяхи, и Socket3 486DX2-66 проц разогнанный до 106МГц.

#81
8:42, 8 янв. 2019

0iStalker

Судя по быстрому гуглу по сравнению с ядром 6x86 из него выкинули типичное для поколения пентиумов внеочередное исполнение (instruction reordering), ну и, скорее всего, часть кеша.

#82
1:10, 26 янв. 2019

=A=L=X=
> Ну это больше тянет на обзорные статьи по популярным процам, чем по консолям.

помню было столько шума из-за этого

#83
(Правка: 17 апр. 2019, 10:13) 14:02, 16 апр. 2019

Обзор архитектуры Sega Saturn

Изображение

Довольно забавная штучка первого поколения 3D и так же как и 3DO базовым элементом сделавшая не треугольник, а четырёхугольник.
Терминология тоже в силу молодости индустрии весьма непривычная, так эти четырёхугольники даже с 3Д и освещением по Гуро они продолжают называть спрайтами. Вышла консоль в конце 1994 года то есть за два года до выхода на пользовательский рынок ПК продукции 3Dfx Interactive — графических ускорителей Voodoo, но примерно в то же время когда появилась на свет Sony Playstation.

Нафаршировали систему с каким то даже остервенением.
Два 32–битных RISC–процессора Hitachi SH–2 делят общие 1,5 Мб рабочей памяти.
Предполагается что второй из них выполняет всякие вспомогательные штуки типа трансформации вершин, но при этом узким местом является доступ к рабочей памяти. Поэтому у процессоров по 4Кб кеша которые во втором переведены в режим 2Кб кеша + 2Кб сверхбыстрой памяти.
Но кроме основных процессоров программированию так же поддавался SCU (System Control Unit) — этот модуль разводил данные по шинам системы, содержал DMA–контроллер и DSP гарвардской архитектуры с модулями умножения, в который можно было загружать небольшие программы которые могли опять таки решать задачу умножения на матрицы с одновременной перегонкой данных из рабочей памяти в видеочипы по DMA. Sega в официальном SDK предоставляла несколько полезных микропрограмм для этого модуля.
Еще был 4–битный микроконтроллер Hitachi сидящий на таймере, задачах генерации прерываний и опроса данных от периферии (например геймпадов). Он работает всегда и питается от батареи когда системы выключена, видимо через него консоль включается/выключается.
Подсистема CD–ROM–а содержит собственный процессор Hitachi SH–1 и 0,5 Мб памяти под буфера ввода. Программировать его нельзя, общение происходит посредством заранее обозначенных команд. Например можно было заставить его закешировать какой либо файл для быстрой подкачки.
Звуковая система содержала 32–канальный генератор PCM или FM–звуков, которые подают свой сигнал в особый DSP на 128 инструкций, которые могут делать массу преобразований с этими звуками и в довесок еще работает всё это под управлением опять таки программируемого микроконтроллера 68EC000 (упрощенная версия m68k) который по умолчанию был запрограммирован Sega как midi–секвенсер, но при необходимости его тоже можно было перепрограммировать.

Видеосистема состоит из двух видеочипов — VDP–1 и VDP–2. Каждый имеет выделенные 512Кб VRAM.
VDP–1 делит свои пополам на два фреймбуфера по 256Кб. Пока рендерим в один буфер другой отображается на экране.
Базовые разрешения — 320x224 и 352x240 пикселей. В них пиксели во фреймбуферах 16–битные.
Есть режим повышающий разрешение по горизонтали вдвое, однако при нём отваливается 16–битная цветность и видеорежим становится 8–битным с 256–цветной палитрой. Кроме этого есть режим (interlace) повышающий разрешение по вертикали тоже вдвое, тут уже отваливаются два фреймбуфера и буферизация, так что видимо рисовать надо успевать во время обратного хода луча ЭЛТ, ибо явно написано, что нельзя рендерить во фреймбуфер отображающийся на экране. Скорее всего этот режим пригоден только для вывода статичной графики.

Отрисовка происходит скармливанием видеочипу связного списка команд к отрисовке. Геометрические примитивы называются «parts» и делятся на оттекстуренные (четырёхугольные «спрайты» произвольного искажения и ротации) и неоттекстуренные (одноцветные четырёхугольники или линии). К любым из них может быть применено сглаженное затенение по Гуро, затенение делением компонент RGB на 2 или полупрозрачность арифметическим средним.
Как и у 3DO природа отрисовки спрайтов/полигонов позволяет сделать трюк с так называемыми end codes — это специальные значения цветов которые позволяют оптимизировать отрисовку спрайтов с большими регионами прозрачности методом полного пропуска сканлайна при встрече специального значения пикселя означающего end code. Причём т.к. спрайты можно зеркалировать по горизонтали, то пропуск происходит после встречи двух end codes так, чтобы отбрасываться могли ненужные куски в конце растров как при отрисовке справа–налево так и слева–направо.
Пиксели 16–битные, но цвета выставляются довольно забавно. RGB–компоненты все по 5 бит и самый старший неиспользуемый бит отведён под признак палитры.
Если спрайт пишется во фреймбуфер в RGB–цвете, то в верхнем бите у него выставляется 1 и он уходит потом на телевизор как есть.
Но если в верхнем бите содержится 0, то включается режим палетризации — и нижние биты уже означают номер слота в палитре и через этот механизм можно даже управлять порядком отрисовки с VDP–2.
Дело в том, что финальное изображение формирует VDP–2 извлекая картинку из фреймбуфера VDP–1 и накладывая на неё до 4 задних фонов и уже итог и выводится на телевизор. Эти задние фоны могут быть битмапами, а могут быть сделаны по полным лекалам 16–битных видеочипов — квадратные сетки замощёных тайлов 8x8 которые можно легко скроллить и даже вращать, причём цвета тайлов могут быть тоже как в RGB–формате так и вхождениями в палитре. Максимальный размер палитры — 2048 вхождений.
Так вот — настройками VDP–2 можно управлять порядком наложения слоёв и фреймбуфера вплоть до того, что палетризированные пиксели фреймбуфера будут иметь разный порядок отрисовки, нежели непалетризированные. Таким образом можно генерировать всякие SFX похожие на стенсильный буфер по эффектам.
Причём задние фоны могут быть двух типов — обычные и вращаемые. Обычные на самом деле тоже можно вращать, но только по оси Z. А вот вращаемые можно вращать сразу по двух осям, что видимо помогает делать SFX типа уходящих вдаль горизонтов как в Mario Cart на SNES.

Забавна сама архитектура переезда в 3D. Фактически они выделили то что в 16–битных консолях было слоем спрайтов в отдельный фреймбуфер чтобы в него можно было рендерить четырёхгольные спрайты произвольных трансформаций:

Изображение

Т.е. как и в 3DO здесь рендер проходил идеологически последовательные шаги по отрисовке обычных спрайтов, потом отзеркаленных спрайтов, потом отмасштабированных, потом просто повёрнутых и уже в конце всего — искаженных любыми способами и даже с интерполяцией затенения по Гуро между четырьмя вершинами. В глубоком отличии от классического (и современного) рендера который идёт по пикселям экрана и делает для них текстурные выборки здесь проход осуществляется по пикселям спрайта с переносом их на экран через трансформации. Поэтому возможен тот же трюк с end codes. Но это приводило так же и к негативным эффектам: так в документации от Sega замечается, что при сильных искажениях спрайта нельзя полагаться на полупрозрачность, потому в один и тот же пиксель экрана могут быть нарисованы несколько пикселей из спрайта, а следовательно они все дадут вклад в затенение итогового изображения.
Тем не менее из этого слоя спрайтов можно было формировать по настоящему трёхмерную графику. Стоит так же отметить, что в целях совместимости с «треугольной» графикой уже набравшей обороты система поддерживала вырожденные четырёхугольники с одной общей вершиной. Слои же задних (и передних) фонов остались как были в старых консолях и в принципе могли быть использованы для вывода задних фонов в привычных платформерах, но в полноценном 3D их применение было существенно более ограниченным — панельки с игровой информацией разве что, да пол–потолок в чём нибудь типа Wolf3D (т.е. бесконечная плоскость уходящая в закат)…
Так что в итоге подход с четырёхугольными спрайтами потом вымер, т.к. обладал рядом существенных недостатков.

Основные сведения взяты из официальной документации — обзора разработки под Sega Saturn (англ.): https://segaretro.org/images/1/16/13–APR–94.pdf

#84
18:37, 16 апр. 2019

=A=L=X=
> 256Кб
Чё-то не густо, 400x300 только влезет, и то без z-буфера. Voodo 1  умела 640x480 с z-буфером.

Кстати, что там было с этим  z-буфером? Или как там отсекалась невидимая геометрия?

#85
(Правка: 7:00) 4:37, 17 апр. 2019

Panzerschrek[CN]
> Чё-то не густо, 400x300 только влезет, и то без z-буфера.

Поглядел в полную VDP-1 reference, значит вот что осталось за кадром в быстром введении.
Базовые разрешения - 320x224 и 352x240 пикселей. Они работают как описано.
Но кроме этого во первых - есть режим повышающий разрешение по горизонтали вдвое, однако при нём отваливается 16-битная цветность и видеорежим становится 8бит с 256-цветной палитрой.
Но еще кроме этого есть режим (interlace) повышающий разрешение по вертикали тоже вдвое, тут уже отваливаются два фреймбуфера и буферизация, так что видимо рисовать надо успевать во время обратного хода луча ЭЛТ, ибо явно написано, что нельзя рендерить во фреймбуфер отображающийся на экране. Скорее всего этот режим пригоден только для вывода статичной графики.

> Voodo 1 умела 640x480 с z-буфером.

Ну, Сатурн вышел в 1994, а Voodoo в 1996. Два года форы и академические знания выходцев из Silicon Graphics сделали конечно своё дело.
Тут ведь в чём фишка то вся...

> Кстати, что там было с этим z-буфером?

Не было там z-буфера даже в зачатках. Всё рисование должно отсекать невидимости порядком отрисовки или этими вот доставшимися от 16-битных систем задними/передними фонами на масках палетризированных спрайтов (что весьма ограничено по повзможностям).
Но это даже не главное - главное то почему у Satrun базовым примитивом был четырёхугольник.
Дело в том, что как и 3DO Company эти ребята стояли в ныне вымершем уже лагере 3D через спрайтовые алгоритмы.
Они шаг за шагом приближались к 3D посредством усложнения алгоритма отрисовки спрайта. Это радикально отличается от того как рисуют полигоны современные видюхи. Буквально "шиворот-навыворот".
Если полигональный алгоритм взяв координаты треугольника идёт по его сканлайнам проходя ровно по одному пикселю за цикл вычисления цвета/текстурирования (запуск пиксельного шейдера).
То четырёхугольный алгоритм это постепенное наращивание сложности спрайта.

Сперва рисуем прямоугольный спрайт прямолинейным переносом пикселей из его изображения на сюрфейс.
Потом добавляем возможность зеркалирования по вертикали/горизонтали.
Потом добавляем возможность произвольного масштабирования по горизонтали/вертикали.
Причём алгоритм всё так же идёт сперва по пикселям спрайта и переносит его на сюрфейс вставляя где надо по нескольку одинаковых пикселей при неровностях масштабирования.
Потом добавляем возможность поворота.
И в общем в конечном итоге мы имеем процедуру-монстра которая рисует четырёхугольный (разумеется) спрайт как угодно перекособочнным по вершинам:

Изображение

С помощью перекрутки любым образом и достигались чудеса 3D. Забавно, что в Saturn поддерживались "вырожденные" четырёхугольники с одной общей вершиной, что позволяло имитировать уже популярную и тогда треугольную графику. Но вот этот лагерь был уверен, что победят четырёхугольные спрайты. И не угадал.
Вот, например, что написано в референсах:

Distorted sprites are created by skewing the character pattern. At this time holes are filled to prevent the dropout of pixels. For this reason, there may be some pixels thatare written twice, and therefore the results of half-transparent processing as well as other processing in color calculation cannot be guaranteed.

Т.е. такой подход имел довольно негативные последствия - дырки при увеличении спрайта надо было закрашивать специальными ветвлениями в алгоритме отрисовки, а при уменьшении размера спрайта какие то пиксели закрашивались по нескольку раз, т.е. foreach шёл по пикселям спрайта. В результате даже с полупрозрачностью возникали проблемы, т.к. записанный дважды пиксель менял прозрачность. У 3DO вообще была гарантия, что уменьшенный в любое количество раз спрайт рисовался в точности столько же времени сколько и неискаженный спрайт, просто все его пиксели писались в один и тот же пиксель сюрфейса без оптимизаций каких либо.

#86
(Правка: 12:45) 12:44, 17 апр. 2019

Немного еще посмотрел в то как именно работают палетризированные цвета в Saturn, ибо там сразу было видно, что дела обстоят непростым образом, но за ворохом слов было не очень понятно.
Оказалось что и с палитрами там жесткач.
Во первых - при рендере спрайта во фреймбуфер данные о цвете его битмапа могут быть представлены непосредственно как 16-битные значения, а могут быть 4-битными слотами в 16-цветной палитре 16-битных же цветов. Но в любом случае во фреймбуфер попадает 16-битное данное у которого верхний бит контролирует является оно RGB или является цветом в палитре.
Так вот когда оно является цветом в палитре существует 8 глобально выставляемых форматов того какие биты в нём отвечают за:
а) номер цвета в палитре (до 10 бит)
б) порядок отрисовки между задними фонами (до 3-х бит)
в) номер расширенного вычисления цвета (до 3-х бит)
г) бит "тени"
Кроме того для 8-битного режима фрембуфера есть так же 8 форматов как эти же биты, но уже в урезанном количестве распределены по 8-битному данному о цвете в нём.
И там такая битовая мешанина из сотен регистров управляющих всякими этими битовыми комбинациями, что как говорится "без поллитры не разберешься".
Реально ловлю то же самое ощущение что было в похожем по духу эпохи 3DO - вся эта битово-палитрово-слоевая мехника переусложнена до жути.

Мегадрайв от той же фирмы был просто гимном лаконичности и простоты своей графической начинки - одна палитра, один палитровый режим и для спрайтов и для тайлов, но пасаран. Тут же прям им крышу сорвало на то как впихать в биты как можно большее число всяких палитр, режимов и цветов. Сомневаюсь что даже половина этих всех вещей была в реальности востребована.

#87
13:53, 17 апр. 2019

Уже в какой-то теме репостил

Запустить видео по клику - Как делать игрыЗапустить видео по клику - Как делать игры
#88
(Правка: 14:10) 14:09, 17 апр. 2019

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

#89
16:06, 17 апр. 2019

0iStalker
Вoт кто - кто, а я этим видео вспомнил свои потуги выжимания из P-90MHz 48Mb Voodoo-I 4Mb лет 15 назад и тестил демки те на Glide.
Смотрел, прямо что-то ёкнуло. Как это тогда было захватывающе и интересно.

Страницы: 13 4 5 6 7 8 Следующая »
ФлеймФорумЖелезо