http://www.ageia.com/
Мысли есть?

Stranger_NN
Есть мысли

Мысль первая: времена 3DFX прошли

Мысль вторая: основная проблема всех нынешних движков (игровых) — они катастрофически отстают от возможностей оборудования.
В частности, для двухядерных процессоров необходимо модернизировать движки. В том числе вынеся расчет физики на отдельный поток, для второго ядра.
Потенциально мы при этом получаем гораздо больший прирост, нежели от специализированного сопроцессора.

Почему:
1. Сопроцессор будет ограничен пропускной способностью шины PCI, на которой находится. В отличие от процессора, имеющего доступ в память.
2. Сопроцессор потребует специального программирования — в отличие от двухядерного процессора, второе ядро которого можно полностью отдать расчету физики. Причем все это будет осуществляться кодом самой игры, и программироваться на обычном языке высокого уровня.

Я бы сказал, что пару лет назад в этом, возможно, был бы смысл. А вот сейчас — уже сомнительно. Потенциал двухядерных процессоров в этом плане видится мне гораздо более востребованным.

matik, не, 3DFX тут не при чем. По-моему.
Просто законы физики, как не крути, постоянны и неизменны, и вполне, в этой связи, поддаются "зашиванию" в железо. В смысле, возможна их аппаратная реализация. Что, как показывает практика, получается очень шустро.

При этом (1) использование буферной памяти и шины PCI-E — проблемы нет. Тем более, что ЗАДЕРЖКА в потоковом видео большой роли не играет, и (2) — если ЭТО интегрировано на/в видеоадаптер — то проблемы вообще нет.

Сопроцессор требует библиотек, в которых есть реализация алгоритмов, т.е., все не так страшно. Вместо прописывания ручками инструкций для CPU — вызываем ф-цию сопроцессора.. Спрашивается, зачем делать программно то, что зафиксировано в "аппаратуре" вселенной?

Stranger_NN
Просто законы физики, как не крути, постоянны и неизменны, и вполне, в этой связи, поддаются "зашиванию" в железо
А реализация этих законов в игре тоже "одинакова"? Очень сомневаюсь, что в физических моделях игр будут одинаковые физические модели сред. Более того, сомневаюсь, что они будут похоже описываться.

То есть со временем, когда победят один, максимум два игровых движка — возможно, часть алгоритмов будет осмысленно перебросить в "железо". Пока явно рано.

Вместо прописывания ручками инструкций для CPU — вызываем ф-цию сопроцессора.. Спрашивается, зачем делать программно то, что зафиксировано в "аппаратуре" вселенной?
Логика есть. НО. Проблема в том, что реальные расчеты физики нигде в игрушках не используются. В самом деле, если гравитацию на поверхности Земли еще можно примерно однотипно рассчитывать, то вот что делать с сопротивлением среды? Какую модель выбрать? Вводить ли турбулентность? Если да, с какими параметрами тел?
А что будем делать с твердыми телами? Рассчитывать твердое тело по строгой модели — явно не риалтаймовый вариант. Считать упрощенную модель? НАСКОЛЬКО упрощенную? В каких местах?

В общем, вопросов больше чем ответов.

gdialex
фактически начальный прототип МАТРИЦЫ ?
Что-то вроде того

Stranger_NN писал(а):

---

Просто законы физики, как не крути, постоянны и неизменны,

---

Ты что имеешь в виду? Уж не законы ли Ньютона?
Кстати говоря, та 3D графика, что реализована сейчас в железе, с точки зреня физики распространения света является фуфлом.

matik
основная проблема всех нынешних движков (игровых) — они катастрофически отстают от возможностей оборудования.
Вы хотели сказать- от возможностей топового оборудования. Производителю игры хочется кушать, и вряд ли он заработает на масло сверху хлеба, если его игра пойдет только на последних моделях видеокарт. И так будет всегда
А писАть несколько рендереров- непозволительная расточительность для большинства производителей игр

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

А если по теме- специализированный сопроцессор, вставленный в PCI, будучи такой бы существовал, давно и безнадежно устарел
Касательно PCIE, опять же, 16х+8х потенциально там занята SLI, что даст гораздо больший эффект, нежели специализированный сопроцессор

расчет физики на отдельный поток, для второго ядра — да уж куда больше. Совремённый процессор о 32-х разрядах IntelPentium 3GHz, например, разбивает задачу аж на 20 «кусков»

Alex P
Вы хотели сказать- от возможностей топового оборудования
Согласен.

А еще больший прирост в этом случае мы были получили от введения вместо НТ специализированных блоков по обработки графики
Не знаю, не уверен. Тут вот в чем дело: второй процессор (точнее, второе ядро) потребует только оптимизированного для отдельного потока кода. А вот специализированные блоки (или, тем паче, специализированный сопроцессор), кроме сложности с самим кодом игры, еще и потребует небанального программирования.
И еще одно: если оптимизированный под два процессора код игры будет исполняться и на одноядерном (обычном) процессоре, то специализированный код под не менее специализированные сопроцессоры или блоки без них работать не будет. То есть придется писать те самые несколько рендеров.

Вот поэтому и не верю. В свое время 3DFX сделала прорыв в области 3D графики, за это ей и простили необходимость переписывать код под новый ускоритель. Никакого такого же рывка от применения нового ускорителя я пока не вижу.

Mister
Совремённый процессор о 32-х разрядах IntelPentium 3GHz, например, разбивает задачу аж на 20 «кусков»
Честно говоря, не понял, что Вы имеете в виду. Какие 20 кусков?

matik

Цитата:

---

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

---

Хм... есть мнение что в движках расчет физики и так идет отдельной задачей — и если это еще не засемафоренный поток то реализация не так уж не сложна.

IMXO в расчете физики нет огромадных объемов данных — так что соменния в недостаточности пропускной способности PCI неясны.

Насчет специального кода для сопроцессора и поссаж в сторону 3DFx — по большому счету уже
Stranger_NN вариант ответа создал.

Какой код ИГРЫ ? вы что ? времена 3DFx именно что прошли!

Все решается библиотеками — Ну был Glide — теперь есть DirectX и OpenGL — и что ? — специализированный код зашить в библиотеке или драйвере — для движка игры это куда менее проблемно чем можно себе представить
Ну вупустить HAVOC библиотеку с поддержкой этого процесса — и движки даже не заметять что они вдруг стали аппаратно физику считать...

Еще по поводу перимущества отдельных потоков и нескольких ядер — мнозогадачность ОС тут учитываем ? в сравнении с аппаратным исполнением ?

PS: откуда стоко скептицизма ?

Ptn
откуда стоко скептицизма ?
А я вообще скептик. В частности, в части "вот сейчас мы тут на рынок выйдем, и все ахнут". Ахнуть, может, и ахнут. Но кому, скажите, захочется переписывать код игры (Вы же не поверите, что все обойдется "просто заменой библиотек"? там, как минимум, надо будет изменить схему расчетов: вместо самого описания физики (алгоритмического) делать параметрические описания под новые библиотеки) без четких перспектив?
Какие конкретно физические модели будет предлагать чип? Например, какую модель расчета освещения? Что делать движкам, которые считают свет по другому? Переделывать игру, а затем заново отлавливать баги?
Не, не верю

matik Ну про ахнут это уже ваше IMXO Не видел такого — а если и есть то легко вспоминается "популярнейший ускоритель интернета".
А вот все остальное про код игры это вы зря ... все вами описанное на самом деле практически нормальная рабочая обстановка — всегда есть код который нужно портировать.
Рельный пример: Консоли <>PS
Смена схемы расчетов ? — девелоперы для того и нужны.
вместо самого описания физики (алгоритмического) делать параметрические описания под новые библиотеки) без четких перспектив?
при чем тут перспективы?

Насколько я понял ваши описания
ПРИЛОЖЕНИЕ(ИГРА) —>ПРЕОБРОЗОВАНИЕ ФОРМАТОВ —> Чип — типичный "Glide"

Сейчас же ситауция обстоит скорее всего следующим образом
ПРИЛОЖЕНИЕ(ИГРА) —>[АПИ БИБЛИОТЕКИ(модуля) — ПРЕОБРОЗОВАНИЕ ФОРМАТОВ- ]—>Чип

Сложная схема ? IMXO нет — SDK есть — далее вопрос техники .

Это СТАНДАРТНАЯ И РАБОЧАЯ ситуевина для девелоперов, так всегда.
Новый чип для мобил, Новый чип для DVD плееров, Новый графический ускоритель в конце концов — всего этого по идее быть тогда не должно

ЗЫ: когда появлялись GPU тоже были споры что лучше аппаратная фиговина или использование ЦПУ — результат то что имеем сейчас — и что ? где все ужасы вами описанные

matik

Цитата:

---

А я вообще скептик.

---

и ты, брут?

Ptn
Все написанное хорошо только в одном случае: если все игры, использующие этот "физический сопроцессор", используют одну и ту же физическую модель.
То есть для гравитации это еще подойдет.
Но вот расчет хода лучей каждый движок делает совершенно по разному. ЧТО Вы отправите в этот сопроцессор, если функции разные?
К примеру, одна игра учитывает многократные отражения, другая — нет.
Зато другая использует прозрачность (альфа-канал), который не использует первая.
Вопрос: какие запросы они отправят в сопроцессор? Что получат на выходе?

Единственный вариант: разработчики физического сопроцессора выдают перечень реализованных в нем функций.
Разработчики игрушек (вернее, движка) глядят на него, и думают, что им может подойти.
Меняют код игры, используя доступные функции.
Получают игру, которая будет способна работать только на... Только на... Только на чем?! на десятке образцов?

Кхм.. Господа... Читать будем?!

Цитата:

---

PhysX Processor Architecture has been designed to enable radical acceleration of:
— Rigid body dynamics
— Universal collision detection
— Finite element analysis
— Soft body dynamics
— Fluid dynamics
— Hair simulation
— Clothing simulation

---

Это, только и именно это делает означенный чип....

Stranger_NN
Fluid dynamics
Замечательно По какой модели?

Stranger_NN ну дык естественно читали ... потому и недоумеваем типа .

matik трасировка лучей к физике реализованной в чипе отношения не имеет
Вы приводите к пример физику "графическую"(оптическую) — которая IMXO и без приставок просто "физикой" называтся не может — это алгоритмы построения изображений. Тут же IMXO речь именно про ньютоновскую физику.
Ваши же примеры еще ооооочень долго не будут реализованы аппаратно.

Вариант когда разработчики чипа НЕ выдают перечень реализованных функций это нонсенс.

Получают игру, которая будет способна работать только на... Только на... Только на чем?! на десятке образцов?
Такая ситуация в "цивилизованном" мире не возможна.

Вы немного путаете последовательность — если разработчик уже решился САМОСТОЯТЕЛЬНО (смотрим выделенное "получаем") реализовавывать СВОЙ драйвер чипа в движке игры, то в первую очередь он убедиться что чип на момент выхода игры будет распространен.

Сначала железо — потом софт !.
ИГРОВЫЕ разработчики поступающие в описанной вами последовательности это не разработчики — эт "студенты" какие-то

Ptn
Ну хорошо. Много Вам сказала формулировка

Цитата:

---

Clothing simulation

---

? А как они их "симулируют"? По КАКОЙ модели?

В общем, будем считать, что это просто "старческое брюзжание" — но в особое будущее этого чипа я не верю. И не так уж много производительности отнимает современная физика, и двухядерные процессоры потенциально интересней...

matik

Цитата:

---

Замечательно По какой модели?

---

По той, которую они берутся сделать быстрее и "дешевле" чем в случае программной реализации (это их внутреннее дело). Причем, учитывая ненулевую стоимость самого процессора — выигрыш должен быть ОЧЕНЬ заметный, такой, чтобы разработчики игр начали слюной капать.. Вопрос в том, есть ли он — да, согласен. Но это отдельный вопрос.

Вот посмотри, взяли же на себя GPU заметную часть ф-ций (обрати, опять же внимание, постоянную их часть)? Взяли. И неплохо делают свое дело. Вот и этот процессор может взять на себя неизменную часть игры (физику ту же самую).

matik Модель не так важна — жестко зашивать в чип какуюто определенную модель нелогично, но даже если и так и модель устраивает девелоперов то так тому и быть.

IMXО почему не важна — физические процессы описываються формулами —> формулы имеют константы и коэффиценты которые и определяют поведение объектов-> это влияет а порой и определяет модель взаимодействий —> все эти параметры , в теории, можно изменять и получать вариации моделей
На практике же нужно скачивать SDK и рассматривать его. А уже сейчас ясно что SDK дает API — а это уже очень неплохо.

Вот одно интересное интервью на буржуйском

PS: вспомните эволюцию Видео->GPU чипсетов... жили себе поживали ... а потом бац и появились они — ШЕЙДЕРЫ!
Если дело дойдет до физических шейдеров то .... про модели можно будет не вспоминать IMXO

На русском ссылка раз ссылка два ссылка три

Что забавно — API SDK вроде как независимо от PPU — и без его присутсвия использует второе ядро CPU — matik — мы не одни во вселенной

Цитата:

---

Тут же IMXO речь именно про ньютоновскую физику.

---

А что вы подразумеваете под ньютоновской физикой? Тех же констант наберётся не один десяток, а ещё формулы. Это в как усложниться всё при таком подходе.

И ещё одно. Класс точности каков будет? ИМХО на данном этапе класс очень низкий.

[/off]

matik
А вот специализированные блоки (или, тем паче, специализированный сопроцессор), кроме сложности с самим кодом игры, еще и потребует небанального программирования.
Какое же небанальное программирование относительно, к примеру, оптимизаций программ под НТ? Вообще, можно сделать работающий "на лету" компилятор, адаптирующий потоки под возможности конкретного блока процессора, так сказать, это будет "НТ для графики", переделал ПО- будет SM3 вместо SM2 . Если ввести в сам процессор именно оптимизации физических блоков под работу с графикой, то компилятор будет несложен и достаточно легко перерабатываем, по типу программной оболочки Crusoe. Его можно ввести в дрова на чипсет

Alex P
Какое же небанальное программирование относительно, к примеру, оптимизаций программ под НТ?
Что значит какое? А представьте себе, что нужно, чтобы запрограммировать два работающих независимо потока в одной программе? Семафоры, передача данных, синхронизация — кто все это будет делать?

Вообще, можно сделать работающий "на лету" компилятор, адаптирующий потоки под возможности конкретного блока процессора, так сказать, это будет "НТ для графики", переделал ПО- будет SM3 вместо SM2
Вашими устами бы медку зачерпнуть Не все так просто. До сих пор адаптировать даже под жестко заданную архитектуру скорее искусство, чем профессия. А Вы легко и просто: бац, и компилятор "на лету".
Трансмета уже попробовала: работает, но очень медленно.

Если ввести в сам процессор именно оптимизации под работу с графикой
Какие такие "оптимизации"? И почему в процессор, а не в графический чип, который как раз с графикой и работает?

то компилятор будет несложен и достаточно легко перерабатываем, по типу программной оболочки Crusoe. Его можно ввести в дрова на чипсет
Извините, это чем-то стало напоминать победные речи Бабаяна: вот сейчас мы выйдем на рынок, и просто порвем Итаниум в клочья.
Извините, в "простое и легкое перерабатывание компилятора" я верю еще меньше, чем в физические сопроцессоры

matik, понятно, что сложности есть, но, имхо, вы их сильно преувеличиваете. Програмеры оптимизации под НТ сделали- сделали, никуда не делись. В древние времена, если помните, был такой компилятор FX32! для переработки "на лету" 16 бит приложений под 32 бита возможности процессора Альфа (кстати, до сих пор не понимаю, почему не сделали попыток адаптировать этот великолепный процессор на десктопы, ведь тогдашние пентиумы безнадежно ему проигрывали) . Инсталлируете приложение, и -бац- оно уже работает как 32 битное

Alex P
понятно, что сложности есть, но, имхо, вы их сильно преувеличиваете
Знаете, это как раз тот случай, когда я с удовольствием ошибусь Честное слово.

Програмеры оптимизации под НТ сделали- сделали, никуда не делись
Ага. Средняя величина прироста от грандиозной компании по оптимизации, куда Интел немало денег выбросила — примерно 10%. Занятно, не правда ли?

В древние времена, если помните, был такой компилятор FX32! для переработки "на лету" 16 бит приложений под 32 бита возможности процессора Альфа
Был, и правда. При средней производительности около одной трети скорости для родного кода первый запуск х86 приложения давал около 20% производительности, а уже остальные — до 40%. На ряде задач был на порядки медленее и Альфы в родном коде, и х86 систем, тогда довольно убогих.

кстати, до сих пор не понимаю, почему не сделали попыток адаптировать этот великолепный процессор на десктопы, ведь тогдашние пентиумы безнадежно ему проигрывали
Причины три:
1. Гигантская стоимость (и себестоимость) систем на процессоре Alpha: широкие шины, высокие частоты, все это не дается даром. Было шумно, сильно грелось, очень дорого стоило.
2. х86 софт стоил денег. Они уже заплачены. С чего вдруг переходить на Альфу, если там тоже надо покупать ПО, а в режиме FX!32 Альфа была медленней Пентиума? Ради чего?
3. Ну и не последнюю роль сыграло то, что Альфа полностью проприетарная система. В отличие от полностью открытой х86. Другими словами, разработчикам надо было платить за лицензию на разработку ПО под Альфу. Если для баз данных, и тому подобных программ это терпимо, то для мелких утилит неподъемно.

Вот поэтому и не победили. А спустя некоторое время х86 из гадкого утенка стал самым сильным и быстрым, и победил в конечном итоге именно он.
Се ля ви

Цитата:

---

Ага. Средняя величина прироста от грандиозной компании по оптимизации, куда Интел немало денег выбросила — примерно 10%. Занятно, не правда ли?

---

matik небольшой результат. Тоже результат. Вопрос в дргом стоила ли овчинка выделки с точки зрения производительности?

Цитата:

---

А спустя некоторое время х86 из гадкого утенка стал самым сильным и быстрым, и победил в конечном итоге именно он.

---

А пророки индустрии обещали недолгую жизнь:)

Цитата:

---

Програмеры оптимизации под НТ сделали- сделали, никуда не делись.

---

Я конечно знаю не столько, чтобы утверждать, но интуиция меня пока не подвдила- HT выйдет по-проще.
А теперь для многоядерных сами пишем ПО

matik
Средняя величина прироста от грандиозной компании по оптимизации, куда Интел немало денег выбросила — примерно 10%
Именно, что средняя! Потому что весьма сложно "соптимизировать" под "все". Графика же обладает достаточно узким набором задач, здесь и оптимизации приведут к куда большим процентам. имхо
Гигантская стоимость (и себестоимость) систем на процессоре Alpha: широкие шины, высокие частоты, все это не дается даром. Было шумно, сильно грелось, очень дорого стоило.
Опять имхо преувеличиваете, все это было верно для топовых компьютеров на альфе У меня знакомый, будучи при некоторых деньгах, купил в те времена (на какой то выставке) систему на Альфе, и единственное, что ему действительно сильно ударило по карману, это много тогда дорогущей памяти, поскольку альфа полностью показывал свой потенциал, работая на широкой шине. Он не сильно грелся (не старшая модель),
х86 софт стоил денег. Они уже заплачены. С чего вдруг переходить на Альфу, если там тоже надо покупать ПО, а в режиме FX!32 Альфа была медленней Пентиума?
на этот компьютер спокойно встала НТ и все приложения офиса и т.п. Игрушки некоторые шли. По цене это оказалось лишь около 2-х раз дороже тогдашних пентиумов. Пентиум про стоил нааамного дороже кстати, уже к тому моменту разработчики ориентировались на выпуск 32 бит программи

Alex P
здесь и оптимизации приведут к куда большим процентам
Посмотрим. Что на это возразишь? Хорошо бы. Но не верится, и все тут

Опять имхо преувеличиваете, все это было верно для топовых компьютеров на альфе
А какие системы на Альфа Вы могли купить?! Либо рабочие станции от Digital, либо серваки от них же. Да, ПОТОМ в Москве бывали распродажи, и мой один знакомый тоже прикупил недорого систему. Но это было ПОТОМ. А вот пока была Digital, Альфа была ОЧЕНЬ дорогой платформой. Практически самой дорогой в пересчете на процессор (мейнрфреймы не в счет).

Он не сильно грелся (не старшая модель
Если младшая, тогда боюсь, что никакой особой производительности он не увидел. Потому как во времена Pentium Pro Альфа была "уже не та"

на этот компьютер спокойно встала НТ и все приложения офиса и т.п. Игрушки некоторые шли. По цене это оказалось лишь около 2-х раз дороже тогдашних пентиумов. Пентиум про стоил нааамного дороже кстати, уже к тому моменту разработчики ориентировались на выпуск 32 бит программи
1. Только 3.51, если правильно помню.
2. NT 4.0 уже не поддерживалась — слишком мало версий для NT 3.5 было продано
3. Игрушки действительно шли некоторые. Медленно.
4. В два раза дороже Пентиумов?! При том, что в х86 скорость была меньше, чем у тех? За что?! Зачем?
5. ППро так и остался дорогим, а вот Pentium II, Pentium III очень быстро ушли в отрыв.
6. По сути, Альфа была лидером в тех приложениях, которые широкой публике не нужны.
7. Разработчики, конечно, "ориентировались" — но переход на 32 бита занял почти 10 лет. Вот так-то.

paska
Вопрос в дргом стоила ли овчинка выделки с точки зрения производительности?
Не знаю. С моей точки зрения, нет. Вот для рендеров — да.

Stranger_NN писал(а):

---

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

---

А я вот что-то сомневаюсь, что это вообще возможно. За счет чего, собственно? До сих пор любое физ. моделирование базировалось на быстрых FP вычислениях, поддержанных быстрым (точнее, широким) доступом к памяти. Что, PPU AGEIA обеспечит десятки-сотни гигафлопс и Гб/сек ПСП?

VLev
Единственная область, где я ее вижу — ряд сложных алгоритмов, имеющих множество тесно связанных преобразований и много действий над одними и теми же данными. Тот же расчет напряжений в твердом теле...

Но будет ли выигрыш?!
Разве что определенные алгоритмы не надо будет отлаживать в игрушках... И только.

matik писал(а):

---

во времена Pentium Pro Альфа была "уже не та"

---

А вот этого не надо...
— Год-два тому назад Альфа все еще держала рекорд в 4-way в одном из бенчмарков 8)
При том что платформа умерла еще в 1999... За пятилетку ее так и не смогли догнать — видно не было "у них" КПСС
— А уж в более ранние "те времена" Альфа была "еще та"
Если не акцентировать внимание на цене
— Наработки по проекту еще долго будут использоваться как Интел так и АМД.

Так что не катите бочку на Альфу

Читал, читал, так и не понял почему эта идя кажется вам бредовая.
имеятся плата со спец. проц и вшитый софт (бивос), производителем/разработчиком определен набор возможностей и апи вызовов и стандатизирован!!!
игра (которая не старая, а та, которую только собираются делать), но игра начинается с движка. а его всегда будут доделывать в плане оптимизации и усовершенстований. Так почему не начать разработку кода который будет вызывать спец проц, и если платы нету, то обработка обычным процем. т.е. в основном коде движка есть вызовы!!!: расчитать то-то и то-то, а вызов идет в одну из библиотек, одна из них отправляет спец. проц, а другая сама реализует, есть плата — первая библиотека, нету вторая. в чем проблема не пойму.

Black_Dragon, имхо потому что сие есть очередная попытка выжать из наших тощих и не очень карманов доп. денежку, для еще одной необходимой платы расширения, занимающей доп. место и тп.
Эти усилия надо направить, если уж так хочется, интелу на внедрение вместо сомнительного НТ блоков обработки, заточенных под графику. Скорость процесссоров уже сегодня достаточна для эффективной работы ненавороченных компиляторов (к примеру, переводящих код в удобный для процессорных блоков вид) на лету. имхо
Почему под графику- потому что процесссорное время 99% обычных пользователей используется под игры

Warrax
— Наработки по проекту еще долго будут использоваться как Интел так и АМД.
Касательно АМД, сие святая правда. Атлон- это Альфа, адаптированный для х86 про пениум, конечно, так не получится сказать

Alex P писал(а):

---

Атлон- это Альфа, адаптированный для х86

---

И меня подначивать тоже не надо
У кого АМД купил процессорную шину в свое время знаем?

Alex P
Атлон- это Альфа, адаптированный для х86
Честно говоря, это неверно. Некоторые идеи используются — но они используются везде в индустрии. Прямого "заимствования" или "адаптации" нет.

Эти усилия надо направить, если уж так хочется, интелу на внедрение вместо сомнительного НТ блоков обработки, заточенных под графику
Я не понимаю, зачем процессору исполнять часть работы графического чипа. Создание, отрисовка, просчет графики делегированы графическому процессору. Зачем перекладывать это на процессор? Выйдет медленее, и к тому же будет занимать процессор, шину, память — в общем, общая производительность станет только меньше.
Так и не понял, в чем же смысл этой задумки.

Black_Dragon
в чем проблема не пойму
Выше уже были описаны принципиальные проблемы с такой штукой. Дело в том, что в реальных игрушках ничего похожего на реальную физику не используется. Соответственно, вызывают очень большие сомнения способности этого "сопроцессора" сделать физику реальной. Слишком уж большое количество вычислений требуется.

Warrax
Год-два тому назад Альфа все еще держала рекорд в 4-way в одном из бенчмарков
Ключевые слова: "в 4 way" (там, где архитектура точка-точка особенно эффективна по сравнению с общей шиной у Интел), и "в одном из бенчмарков" (то есть наверняка нацеленном на межпроцессорное взаимодействие).

Разумеется, обычных покупателей обычных систем эти тесты (и такие системы) ни капли не интересуют. Так что никакого весомого выигрыша у Альфы не было.

Так что не катите бочку на Альфу
И мыслей не было. Просто, справедливости ради, развитие этой платформы прекратилось давно. Новых идей не было, ключевых разработчиков они тоже потеряли. Гибель Альфы в этом плане вполне закономерна, конкуренты ведь постоянно догоняли.

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