360 Vs PS3: Физика в PS3 лучше

[Togusa 3]

[quote name="Gera"] [quote]2/anty/: Где здесь что-то лишнее? Это выжимка из выступления AGEIA:
"Такие эффекты, как флюидная физика, включая движение воды и дыма, а так же сложная физическая механика будут доступны только обладателям PS3 и PC".[/quote]
Там вроде речь шла о хардварном акселераторе ПК о Сони говорилось ,что програмном обсчёте и Целл имеет возможность аппаратно обработать некоторые физические эффекты ,о специальной заточке Целла под их СДК вроде речь не шла :upset: Так что всё это можно и на 360 перенести ИМХО :lamer:[/quote]

Вообще-то новости о том, что Сони заключила договор на использование в PS3 SDK технологий Unreal Engine, Havok и Ageia уже месяц скоро будет.
И когда Ageia утверждают, что Xbox 360 не потянет, то можно, конечно, предположить, что они куплены Сони на корню, а можно смириться, что просто слепленные воедино три универсальных ядра не сравнимы в просчёте физики с семью ядрами, которые изначально для этого и создавались. :)

[yuhan 247]

[quote name="/anty/"]Флюидная физика дальше технодемок я думаю и не пойдёт( можно вспомнить демонстрации ЗЫ2, наверняка использование флюидов - а это сверх жрущий процесс при физ коректном простчёте прийдётся что то отключать, у любого железа есть лимит мощьности, для решения проблем дыма вполне можно дифлекторы использовать, никто не говорит что у PS3 на что то нехватит мощьности, другое дело что если игры будут столь же однообразными и сериальными как есть сейчас то мы скажем сони спасибо засмерть индустрии)) покрайней мере индустрии качества)) добро пожаловть в игровой макдональдс)) но с шикарной физикой и в красивой упаковке))[/quote]

По этому поводу статейка есть: [url=http://thedeathofgaming.blogspot.com]http://thedeathofgaming.blogspot.com[/url]

[xtr 878]

2/anty/: Как это не смешно, но если говорить об эволюции, то по количеству необычных проектов лидирует

PS2, затем идет GameCube и только потом Xbox.

[Bonker 0]

Вот-вот. На ps2 игровой макдоналдс это только мультиплатформа.

[GameBox720-5 0]

xtr, сказал:
У сайта есть своя политика и задачи и они не будет меняться.

Вот это и хотелось услышать, это многое и объясняет.

Как это не смешно, но если говорить об эволюции, то по количеству необычных проектов лидирует PS2, затем идет GameCube и только потом Xbox.
Речь была немного не об этом. На мой взгляд.

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

[Enemy First 1]

[b]2 Togusa[/b]

[i]256Kbyte это до хрена памяти. Туда можно MS-DOS запихнуть и движок квейка впридачу. А если сосздателей .kkreiger пригласить... [/i]
Вы забылись :). Верну вас на землю - MS-DOS туда запихнуть можно, конечно (вопрос целесообразности не рассматриваем :lol:), но далеко не всю. Q1E уже нельзя. Не говоря про демки 64K и прочие этого рода, которые только на носителе занимают так мало места, а в оперативной памяти - в сотни раз больше (полюбопытствуйте ради интереса и DLL-ки посмотрите)!

[/anty/ 531]

yuhan
Спасибо, классная статья, согласен со всем, разве что не идиализировал бы нинтенду)) но вобщем чел прав...
вобщем рано или поздно мегакорпорации либо сдохнут, либо мы на них плюнем)) но вот что факт что продажи игр для некст генов могут сильно упасть ( цена, и повтороение того что уже и без того надоело) ацена возврастёт, и будет кризис перепроизводства с кризисом отсуствия продаж..))

[size=75]Добавлено 06 Сен 2005, 15:42:[/size]

xtr
Я бы сказал что PS это эволюция..)) революции закончились на дримкасте((((( а жаль.

[yuhan 247]

[quote name="/anty/"]yuhan
Спасибо, классная статья, согласен со всем, разве что не идиализировал бы нинтенду)) но вобщем чел прав...
вобщем рано или поздно мегакорпорации либо сдохнут, либо мы на них плюнем)) но вот что факт что продажи игр для некст генов могут сильно упасть ( цена, и повтороение того что уже и без того надоело) ацена возврастёт, и будет кризис перепроизводства с кризисом отсуствия продаж..))

[size=75]Добавлено 06 Сен 2005, 15:42:[/size]

xtr
Я бы сказал что PS это эволюция..)) революции закончились на дримкасте((((( а жаль.[/quote]

Но кстати этот парень не поклонник Нин... Знает толк в играх (косвенно предположу) - 1400 игр в колекции, не шутка.

[Bahamut 0]

[quote name="Togusa"]Даю бесплатный совет: доки по Cell надо читать, а не курить.[/quote]

было бы очень неплохо, если бы ты сам сначала этим советом воспользовался.

[quote]1. SPE -- совершенно самостоятельный проц, умеющий то-же что и какой-нить 8086 или Z80, но с новейшими FPU, встроенной памятью и работающий на частоте 3.2GHz (PS3)[/quote]

в этом-то и проблема, что он слишком самостоятельный.

[quote]2. Каждый SPE имеет 256Kb оперативы, находящейся прямо на чипе. Причём из LS данные можно пергонять прямо в другие SPE или в память черз шину готовую работать сразу со всеми SPE.
3. 256Kbyte это до хрена памяти. Туда можно MS-DOS запихнуть и движок квейка впридачу. А если сосздателей .kkreiger пригласить...[/quote]

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

на мой взгляд, идеальный графический акселератор (вертексная его часть по крайней мере) должен иметь похожую архитектуру (а совсем не шейдеры). но когда тебе надо пробежаться по нескольким тысячам игровых объектов, которые находятся в [b]ОСНОВНОЙ[/b] памяти, причем в разных местах, то про все свои 7 SPE ты можешь смело забыть. они тебе не помогут ничем.

[quote]4. Роль PPE при правильном подходе к программированию состоит в том, чтобы загрузиться с BIOS, затем залить в SPE микроядерные операционки, которые самостоятельно (по указанию от OS) скачают из памяти программы для SPE, запустят их, сохранят/передадут результаты работы и загрузят следующую микропрограмму. PPE может в это время вообще чем хочет заниматься. Он не нянька. Он бригадир.[/quote]

попробую на пальцах. у тебя есть 10 000 игровых объектов, которые находятся в определенных точках и движутся с определенным ускорением. ты хочешь "обработать" их и понять где они будут на следующем кадре по формуле p = p + v * t + a * t^2 / 2. потом надо еще проапдейтить позиции этих объектов в, допустим, осt-tree.

как это сделать на обычном проце:

>перебрать все объекты и для каждого выполнить:
> p = p + v * t + a * t^2 / 2
> v = v + a * t;
> перераспределить объекты согласно новым координатам в oct-tree:
> найти старую поизицию объекта в oct-tree и удалить ее
> найти новую позицию объекта в oct-tree и записать туда ссылку на объект


теперь то же самое на cell:

PPE:

>перебрать все объекты и для каждого:
> записать в поток в памяти его p, v и a
>запустить программу на SPE
>заниматься другими делами (не можем себе позволить простой PPE)
>понять, что программа на SPE выполнилась
>перебрать все объекты и для каждого:
> прочитать из потока его новые p и v
> перераспределить объекты согласно новым координатам в oct-tree:
> найти старую поизицию объекта в oct-tree и удалить ее
> найти новую позицию объекта в oct-tree и записать туда ссылку на объект

SPE:

>для каждого элемента gпотока:
> прочитать из входного потока p, v и a
> посчитать p_ = p + v * t + a * t^2 / 2
> посчитать v_ = v + a * t;
> записать p_ & v_ в выходной поток

сравни объемы и сложность даже такого убогого псевдокода. обрати внимание на то, что на cell потребуется создание дополнительных буферов в памяти. на практике все еще сложнее. и это мы говорим о физике - одной из самых "удобных" игровых задачь для архитектуры cell. а сказки про то, что SPE "сохранят/передадут результаты работы и загрузят следующую микропрограмму" и "PPE может в это время вообще чем хочет заниматься", ты можешь рассказывать феде, а не мне.

[quote] [quote name="Bahamut"]
а вообще, судя по твоей эмоциональности, ты являешься упертым фанатом cell. рационально спорить с такими людьми занятие бесперспективное. так что верь во что хочешь.
[/quote]
О да. Точно. Гениальный аргумент. "Ты дурак, и я с тобой не дружу, поэтому иди из моей песочницы!!!". :)[/quote]

не надо перевирать. я говорил о предвзятости. ты на все смотришь через пелену фанатизма. а это паршивая основа для дискуссии.

[quote]Да мне нравится Cell у него сложная, но очень красивая архитектура. Отсутствие кэша вообще меня в дичайший восторг приводит. [/quote]

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

[quote]Демосцена от такого проца вообще кипятком писать должна. Ещё бы, восемь процов с 2Mb памяти, работающей на частоте ядра! Это же прелесть, что такое![/quote]

надо феде запретить писать в форум. оказывается это заразно.

[Togusa 3]

[quote name="Enemy First"][b]2 Togusa[/b]

[i]256Kbyte это до хрена памяти. Туда можно MS-DOS запихнуть и движок квейка впридачу. А если сосздателей .kkreiger пригласить... [/i]
Вы забылись :). Верну вас на землю - MS-DOS туда запихнуть можно, конечно (вопрос целесообразности не рассматриваем :lol:),[/quote]

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

[quote name="Enemy First"]
оперативной памяти - в сотни раз больше[/quote]

Уели-уели... :) Привык я к Z80 и Apple II где 48k оперативки было и ничего, я под Агат даже редактор писал. :) Сейчас, конечно, объёмы кода не те. Но всё-же, думаю, вряд-ли код в демках так хорошо пакуется. А медиа-данные они пускай в основной памяти хранятся... :)

[size=75]Добавлено 06 Сен 2005, 19:28:[/size]

[quote name="Bahamut"]
SPE:

>для каждого элемента gпотока:
> прочитать из входного потока p, v и a
> посчитать p_ = p + v * t + a * t^2 / 2
> посчитать v_ = v + a * t;
> записать p_ & v_ в выходной поток

сравни объемы и сложность даже такого убогого псевдокода. обрати внимание на то, что на cell потребуется создание дополнительных буферов в памяти.
[/quote]

А не проще так? Делим твоё oct-tree на четыре ветви, и распределяем ветви по SPE. После чего каждый SPE выбирает из памяти пакет данных, пересчитывает координаты, скорости, ускорения оценивает, не покинуло-ли тело родную ветвь и если да -- передаёт её ну хотя бы и PPE, чтобы тот глянул, куда его передать. А можно напрямую пустить следующему SPE на вход, чтобы тот проверил, его ли это теперь точка и если нет, и если нет то передал бы дальше.

Получаем где-то трёхкратное приемущество перед однопроцессорным вариантом.

Ты извини, ты диаграммы IBM видел? Они давно уже рендеринг ландшафта с 30fps осуществили. Причём PPE там только точки генерирует. А отражения, лучей, кадрирование, антиалиазинг -- всё делается на SPE-хах. Причём между собою они обмениваются данным вовсю. И "буфера памяти" у них не во внешней памяти, а в LS, которая работает на частоте процессора.

[quote name="Bahamut"]
не надо перевирать. я говорил о предвзятости. ты на все смотришь через пелену фанатизма. а это паршивая основа для дискуссии.
[/quote]

Извини, это ты тут рассказываешь, что инженера IBM в доках всё врут. Кто тут фанатик? :)

[Bahamut 0]

[quote name="Togusa"]А не проще так? Делим твоё oct-tree на четыре ветви, и распределяем ветви по SPE. После чего каждый SPE выбирает из памяти пакет данных, пересчитывает координаты, скорости, ускорения оценивает, не покинуло-ли тело родную ветвь и если да -- передаёт её ну хотя бы и PPE, чтобы тот глянул, куда его передать. А можно напрямую пустить следующему SPE на вход, чтобы тот проверил, его ли это теперь точка и если нет, и если нет то передал бы дальше.

Получаем где-то трёхкратное приемущество перед однопроцессорным вариантом.[/quote]

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

[quote]Ты извини, ты диаграммы IBM видел? Они давно уже рендеринг ландшафта с 30fps осуществили.[/quote]

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

[quote] Причём PPE там только точки генерирует. А отражения, лучей, кадрирование, антиалиазинг -- всё делается на SPE-хах. Причём между собою они обмениваются данным вовсю. И "буфера памяти" у них не во внешней памяти, а в LS, которая работает на частоте процессора.[/quote]

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

[quote]Извини, это ты тут рассказываешь, что инженера IBM в доках всё врут. Кто тут фанатик? :)[/quote]

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

[Chez 0]

у мя вопрос, а такой всплеск небывалого ботанизма на старте каждого поколения?

[Warge 0]

[quote name="Chez"]у мя вопрос, а такой всплеск небывалого ботанизма на старте каждого поколения?[/quote]
Не умничай. Свой IQ ты уже показал. :mrgreen:

[GameBox720-5 0]

Одна из интересных мыслей, кстати - Chez, сказал: у мя вопрос, а такой всплеск небывалого ботанизма на старте каждого поколения?
А вообще приятно почитать, потом ещё и сравнить, а ещё позже купить то, про что досканально знаешь. Или не купить или купить назло пряников, выпить чаю... эх, поэзия...

[JayDi 1]

[quote]попробую на пальцах. у тебя есть 10 000 игровых объектов, которые находятся в определенных точках и движутся с определенным ускорением. ты хочешь "обработать" их и понять где они будут на следующем кадре по формуле p = p + v * t + a * t^2 / 2. потом надо еще проапдейтить позиции этих объектов в, допустим, осt-tree.

как это сделать на обычном проце:

>перебрать все объекты и для каждого выполнить:
> p = p + v * t + a * t^2 / 2
> v = v + a * t;
> перераспределить объекты согласно новым координатам в oct-tree:
> найти старую поизицию объекта в oct-tree и удалить ее
> найти новую позицию объекта в oct-tree и записать туда ссылку на объект


теперь то же самое на cell:

PPE:

>перебрать все объекты и для каждого:
> записать в поток в памяти его p, v и a
>запустить программу на SPE
>заниматься другими делами (не можем себе позволить простой PPE)
>понять, что программа на SPE выполнилась
>перебрать все объекты и для каждого:
> прочитать из потока его новые p и v
> перераспределить объекты согласно новым координатам в oct-tree:
> найти старую поизицию объекта в oct-tree и удалить ее
> найти новую позицию объекта в oct-tree и записать туда ссылку на объект

SPE:

>для каждого элемента gпотока:
> прочитать из входного потока p, v и a
> посчитать p_ = p + v * t + a * t^2 / 2
> посчитать v_ = v + a * t;
> записать p_ & v_ в выходной поток

сравни объемы и сложность даже такого убогого псевдокода. обрати внимание на то, что на cell потребуется создание дополнительных буферов в памяти. на практике все еще сложнее. и это мы говорим о физике - одной из самых "удобных" игровых задачь для архитектуры cell. а сказки про то, что SPE "сохранят/передадут результаты работы и загрузят следующую микропрограмму" и "PPE может в это время вообще чем хочет заниматься", ты можешь рассказывать феде, а не мне. [/quote]
Bahamut, только ты не учел одного - сам расчет займет намного больше времени, чем процесс передачи данных. А т.к. SPU 7 штук, они эти расчеты будут вестись одновременно. Тем более, в примере была простейшая операция, а ведь в реальности придется решать более сложные задачи. Вот тут и проявится вся мощь параллельного вычисления. А если добавить то, что SPE специально оптимизированы (дополнительные команды?) для вычисления физических задач, то Cell уходит далеко вперед, имхо.

[GameBox720-5 0]

JayDi, писал:
А если добавить то, что SPE специально оптимизированы (дополнительные команды?) для вычисления физических задач, то Cell уходит далеко вперед, имхо.

А потом возвращается назад и делает ещё парочку кругов, потому, что...... ему это просто нравится! Мир полон гениальных идей и все они рядом, буквально, под ногами!

[xtr 878]

Интервью представителя Crytek В немецком Ggamestar:

You work straight on the next game and concurrently on the CryEngine2...

... said we to it something?

You, I * g * where do not go the technical journey?

In the rough one the journey goes to an Streaming architecture, CROSS platform to Multi Threading, thus multi-core and Multi CPU, and over each pixel at least a Shader will run.

Do you remain with SM3.0 or do jump it directly on SM4.0?

We support SM2.0 and upward

And upward?

And upward.

The new PC processors and the coming consoles set substantial on Multi Threading. How do you use the Potential?

We scale the individual modules such as animation, physics and parts of the graphics with the CPU, depending on how many threads the hardware offers. We support both Multi CPU systems and Multi Threading and multi-core. With three CPUs with two hardware Threads each (dual core CPUs) it can be that we scale on six Threads. Possibly we do in addition, without it, depending on, how quickly the individual cores and/or CPU Threads run. But we develop a system, which analyzes, how much Threading power are available and scale the engine then accordingly.

x86, power PC and power PC plus Cell: All architectures have their own Threading organization.

The 360 resembles Hyperthreading. There is in principle three CPUs with two Hyperthreads each. If you ask the hardware manufacturers, is not it naturally like that. But if one analyzes it as a software developer, it is nothing different one than Hyperthreading. That is, one has six Threads, actually however only three times 1.5 Threads. On the PlayStation 3 it looks differently with Cell: The head CPU has two Threads (somewhat better than Hyperthreading), and in addition comes seven synergetic processors. The eigth SPU existing in the Design was omitted.

Because of Yields?

A pure aspect of production. The SPUs are not as flexible as a conventional CPU, and therefore we scale there differently.

Between individual architectures hardly the complete code can be transferred. At least Low level calls x86 and power PC must be modified, but how portable is the code within the two power-PC-BASED consoles?

Also not really portable. We have, I believe, the only German enterprise PS3-Devkits. Accordingly we can look ourselves in the hardware and practice instead of only speculate. The PS3 is a system, which needs special adjustments, which are particularly begun to cut on the PS3-Architecture - a simple port does not function.

It is thus not like that, how Sony stated that you a beautiful Layer have, your code, and everything functioned on Cell marvelously?

Wish themselves in such a way. But that is far still. Also the Devkits is not so far yet. On the basis of the provided information to the Devkits one must operate at quite a Low level, in order to get which from the hardware.

Topic interprocess communication: how relevant are the differences between Multi Thread architectures?

A very relevant question. The following things are relevant with the Multi Threading on the hardware side: Does the Threads run on genuine cores (they in each case their own register set have?)? Or there is a hardware abstraction as with power the PC, where - here two - the Threads has genuine own registers sets, but on the same core is nevertheless, so that at the Issuen of instructions on only individually existing units both Threads cannot work. Multi Threading with Hyperthreading tries only to always distribute the instructions on the different super+scalar units (Math operations on the Integer and floating unit, load/net curtain etc.).

With several cores still the question about the bus binding exists: Do they divide the same bus to the periphery and to main storage? How is the Caches implemented, does divide all Threads the same Cache? And: Shared MEMORY vs. independent local memory. A complete power PC core is also part of the Cell system. This is present however not only as independent arithmetic and logic unit, but also as host for the individual Cell cores. With Cell architecture still individual Cell cores connected by an ultrahigh bus are in the system except the power PC core, which can communicate independently with one another. If one uses the optimal parallelism, one can by this parallel architecture and the super fast bus during optimal extent of utilization a linear scaling with the number of Cell cores to reach.

How do Multi Thread systems on single core PCS behave?

As developers we are in the bloedesten situation, in which we could be. We must support 32 and 64 bits, single and Multi CPU, Singleund Multi Thread, Cell and not Cell as well as OpenGL and DirectX. The expenditure to develop a technology which uses these parameters optimally, is extremely high. The technical expenditure is at least twice as high as with the first CryEngine.

The step from 32 to 64 bits was program-technically surely simpler than from single to Multi Threading.

Unfortunately it is not a step. We cannot dare the step yet, we must both support.

Are there performance problems, if multi threaded the programmed Cry engine 2 on a single core PC runs?

The code can run sequentially. One loses thereby some efficiency, but what one wins by further optimizations, is higher. Thus the price to lose a certain Framerate if the code on a single Thread CPU runs, is so marginal that one can clean-get by other code improvements again. Most PCSpiele is anyway not correctly optimized, also far Cry.

In the console segment the developers take often amazing out of a relatively harmless hardware, because they must make it. Would run on the PC exactly the same, one need for Doom 3 probably only a Geforce 4 Ti.

That is the point. The development of the hardware is so rapid, which one gets only short time, around which rauszuholen. Exactly the same it is also with the CPUs. If one goes with a Multi Threading Renderer on a CPU, one must take oneself evenly the time to optimize. The largest problem thereby are Cache Misses. Additionally one should avoid global memory between the individual Threads. Simply said: If we access the same pot, the pot may not change. If I access briefly before you an element, then kriegst you it no longer, or it is not any more what you expected. In order to go around, one changes in best in a step the something, gives the ErErgebnis then further to the open memory and there for other CPUs freely (Unlocking).

How keep do I consistent with six Threads physics?

One can solve that not only technically, but also creatively. One must go new ways: As we can, and that is a basic question, how we can scale our play from single Thread to eight Threads qualitatively. In such a way that equal Gameplay it remains but the play qualitatively better ausieht, or in such a way that I can play it better. On the PC one must reduce its choice to cosmetic improvements, since everyone has the power, but it would give serious differences in the Gameplay. On the technically fixed consoles one could permit also better Gameplay with the suitable optimizations. Accordingly one must examine two scaling bar as multi-platform developers: FX and Gameplay. On the PC often only FX is optimized (higher dissolution of texture etc.). We would like to scale both FX and Gameplay, over the intensity of the logic or over the quality of the Shader for example.

How does it stand with the Portability between x86-PC and Xbox 360?

Architecture is different in principle, but nevertheless a lot more similarly than from Xbox 360 to PS3. The CPUs of PC, Xbox 360 and PS3 has actually only a relevant similarity - and that is Multi Threading. When generic CPU is the 360-Prozessor the most efficient, but if one takes the seven SPUs of the PS3 in addition, then achievement conditions look again differently. Before we had the PS3-Devkits, we thought that PS3 and Xbox 360 are closer than PC and console - with the development. Does not seem so however * laughs *

Therefore you optimize your engine on the SPUs of the PS3?

Definitely. That is a must for us, since we want to use the power of the PS3 completely. Accordingly the PS3 is gotten nearly a completely own engine architecture, a kind sub-architecture in the CryEngine 2.

The development of the console title far Cry Instincts still outward gave. This time is portiert?

[GameBox720-5 0]

xtr, писал: Интервью представителя Crytek В немецком Ggamestar: (...)

А чего, собственно, ничего нового они и не сказали. Всё пока подтверждается. Реализация разная того, сего, бла, бла, бла. А что на повестке дня? В чём фишка то? Той стори?

[xtr 878]

2GameBox720,5:

The 360 resembles Hyperthreading. There is in principle three CPUs with two Hyperthreads each. If you ask the hardware manufacturers, is not it naturally like that. But if one analyzes it as a software developer, it is nothing different one than Hyperthreading. That is, one has six Threads, actually however only three times 1.5 Threads. On the PlayStation 3 it looks differently with Cell: The head CPU has two Threads (somewhat better than Hyperthreading), and in addition comes seven synergetic processors. The eigth SPU existing in the Design was omitted.

[GameBox720-5 0]

xtr, именно это я и хотел перевести когда писал ответ, но потом воздержался, подумал, может что есть поважнее. Понятно, ничего. Возможностей больше, а вот окончательное быстродействие... я понял. Ждём развития событий.

[Togusa 3]

[quote name="Bahamut"] но стоит тебе захотеть добавить к этому какое-нибудь текстурирование, и привет - текстуры не влезут в память SPE при всем желании, а снаружи прочитать он их не умеет.[/quote]

Хорошо, я вижу что тытут самый умный, тогда обясни мне, идиоту, за каким чёртом инженера SCEI на диаграмме...

[url]http://research.scea.com/research/html/CellGDC05/15.html[/url]

нарисовали немаленькую такую стрелочку между SPE-шным Local Store и здоровенным прямоугольником в котором написали XDR Dram (те самые 128Mb памяти от Rambus), LS of other SPEs (это буфера в Local Store, других SPE, когда идёт потоковая обработка данных в несколько этапов распределённых по SPE) и ещё какие-то (лень разбираться) MMIO registers и IO device memory.

Ты что, хочешь сказать, что инженера Сони, мягко говоря врут или скрывают тот факт, что посередине этой стрелочки должен висеть PPU? У меня большие сомнения в этом, потому как не я один читая доки думает, что SPE имеет доступ к памяти.

Вот и Блечфорд в списке команд SPE упоминает доступ к памяти...

1. Based on VMX / AltiVec - some instructions added, some removed.
2. Includes some (all?) of the PS2’s Emotion Engine ISA.
3. Supports vector or scalar operations.
4. Includes loads, stores, branches and branch hints.
5. 8, 16, 32 and 64 bit integer operations.
6. Single and dual precision floating point.
7. Saturation arithmetic for FP (not integer).
8. Simplified rounding modes for single precision FP.
9. IEEE 754 support for double precision FP (not precise mode).
10.Logical operations.
11.Byte operations: Shuffle, Permute, Shift and Rotate (Shift / Rotate er Qword or slot).
12. 128 x 128 bit Registers.
[b]13. Local Store DMA I/O (to / from any address in system).[/b]
14. Commands for mailbox access, interrupts etc.

Может тебе доступна какая-то инсайдерская информация? Не поделишься, а? :)

[/anty/ 531]

Инженеры сони никогда не врут..)) И инженеры майкрософт кристально честны))
Лучше всего инженеры любой конторы анализируют железо конкурентов))

[Togusa 3]

[quote name="/anty/"]Инженеры сони никогда не врут..)) И инженеры майкрософт кристально честны))
Лучше всего инженеры любой конторы анализируют железо конкурентов))[/quote]

Тру! :)

[JayDi 1]

Если кому интересно, то можете почитать 600(!) страниц о Cell'e и его архитектуре.
[url=http://cell.scei.co.jp/e_download.html]http://cell.scei.co.jp/e_download.html[/url]

[Gera 0]

Не влезая в дебри скажу что изначально Целл делали из расчёта на обработку графики ,отсюда и его ограничения как универсального процессора я не понимаю споров програмистов Но ИМХО я думаю что Хеон 360 более универсален чем Целл и тот факт что супер Целл не способен работать с шейдерами наводит на мысль что современную графику сам по себе Целл построить не в состоянии ,а тут ещё в плане технологий RSX задвинули :upset: