>> маленькие специализированные граф.процессоры с небольшим и ортогональненьким набором команд

спасибо, посмеялся. специализированные и ортогональненьким - это да, а вот архитектура у них очень, очень complex. мегабайты кода драйверов и общая их нестабильность это косвенно подтверждают :)

где-то были статьи по реверсингу эволюций архитектур видеокарточек, не помню уже кто писал, правда((

но статьи хорошо подтверждались личными наблюдениями, и, вообщем, количество *специализированности* там зашкаливает. именно поэтому и выезжают. но это и усложняет, т.к. надо разбивать относительно вменяемый glsl/hlsl на совершенно разные наборы примитивов.

Complex там в первую очередь обвязка. На радеонах по 800 конвееров, и будь добр, обеспечь каждому данные из памяти. И обвязка у Larabee будет как минимум не проще. А сами конвееры скорее всего очень простые. Хотя бы из соображений максимальной экономии транзисторов. Так что мерять придётся чисто ядро, а у risc'ов здесь фора на простой декодер команд.

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

В общем, либо intel выпусти не x86, либо они будут сосать. А в свете openCL вопрос стоимости гигафлопс за бакс и ватт становится весьма животрепещущим.

Обвязка у лараби будет проще, потому что лараби одна штука (пока что). А так в общем да, х86 они зря поддерживают.

Согласно читанному - лараби есть multicore cpu|gpu hybrid. Т.е. обвязка вокруг ядер - нужна.

Я имею в виду, что у нвидии и ати драйвер поддерживает *семейство* чипов с разными архитектурами.

А. Ну, это да, согласен. Но по железкам...

Драйвера там такие, потому что API дюже кривой плюс один драйвер поддерживает 117 разных железяк. Архитектура же простая и незамысловатая, весь RSX от PS3 проще, чем i386 1985 г. выпуска, новых железок я не видел, но думаю они еще проще чем RSX.

Я согласен, что complexity вынесено в драйвера, и пост носит несколько провокативный характер, но такой вопрос - у RSX простой command buffer interface или обработчик всего этого тоже простой?

У RSX простой команд буффер и никаких обработчиков - что напишешь в буфер то и получишь.

Ясно, спасибо за разьяснения. Хотя все равно непонятно, как оно при этом параллелизуется (у RSX вроде отдельные pixel/vertex units, а в последних поколениях всё shared, там должен быть memory controller и instruction set сложнее)

Мемори контроллер везде есть, шареные/нешареные юниты - какая разница, у них есть пины на входе, есть пины на выходе, будут им вертексы пихать во входные - будут вертексы на выходе, будут пиксели - будут пиксели на выходе. Вообще шейдер там самая простая часть, обвязка егойная, которая треугольники растеризирует, всякие условия проверяет и прочая - самая сложная. Но вместе все равно с 386 с его ММЮ, тремя режимами, тучей управляющих регистров и таблиц и ацкой системой комманд не сравнить.

ну типа да... впрочем, обвязка растеризатора ж тоже часть архитектуры %)

Самая сложная при чем. АЛУ, которое считает шейдер - тупое как полено, там никаких декодеров и бранчей - наливай да пей.

(не флейма ради) Ее можно считать сравнимой по сложности с x86 mmu/pipeline? Или все равно проще? :)

Проще, конечно - там, как выше заметили, ничего сложного навернуть нельзя, этож все работает с сотнями АЛУ одновременно. Поэтому, скажем, такие тривиальные и полезные вещи, как программируемые текстурные юниты или программируемые буферы до сих пор не могут асилить. Внутри АЛУ хоть интегралы считай, а вот с результатом практически ничего не сделаешь, только то, что битиками можно поставить в растеризаторе.

Понятно...

в обычном пентиуме чуть ли не 80% площади занимает разбор команд-опкодов и приведение их к удобному для вычисления виду.

Да, я рассматриваю собственно ядра ( по ошибке обозвав их процессорами), без учёта кэша и без учета того, что в "видеопроцессоре" ядер порядка тыщщи, а в новых интелях на порядок-два меньше. В видеокарточке "процессоры-ядра" реально маленькие, но их много.