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

[wish 0]

[quote name="Lucifer"]Блин коробои достали-всем итак ясно что ваш гроб хуже ЗЫ3,можете --- скок влезет ниче этим не докажете![/quote]

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

[Togusa 3]

[quote name="Bahamut"]
любые. данные о игроках, о объектов. где они находятся, что делают, данные AI, айтемы, скрипты, служебные объекты - все что угодно. игра очень сложная программа, и там этого добра - хоть :ass: ешь.
[/quote]

Нуууууу... Мне всегда казалось, что число этих данных не сильно выросло со времён Quake 1 или Unreal, в отличие от медийных, геометрических и физических, число которых выросло порядка на два... И с этими "игровыми" данными вполне справится PPE, пока SPE лопатят физику, геометрию, звук и сетевые данные.

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

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

Ага... Ну ты уж извини, но по моему нагружать Cell задачей с которой в системе обязан справляться RSX, это идиотизм. Изначальный посыл спора состоял в том, что SPE настолько несамостоятельны, что PPE будет всё время вынужден менять им подгузники и у него не останется времени на те задачи, ради которых его в Cell и впихнули. Вроде мы выяснили, что это не совсем так? :)
Но ежели ты так хочешь алгоритм, пожалуйста. SPE0 считывает текстуру как линейный поток данных, разбивает его на цветовые компоненты из которых, скажем, красную оставляет себе, а остальные передаёт SPE1-SPE3 каждый из них определяет новые линейные координаты компоненты точки (что кстати позволит сделать эффект разделения по цветам при желании), и скидывают их в буфер в LS. По мере накопления точек с текущими координатами они скидываются в SPE4, который опять собирает цветовые компоненты вместе и скидывает результат в память.
Ограничение у алгоритма есть. Необходимое условие для твоей текстуры -- в среднем точки не должны уходить от своих начальных линейных координат более чем на одну двадцатую размера текстуры. Но для эффекта ряби, марева, искажения -- вполне себе рабочий алгоритм. И поточный к тому же. :)

[quote name="Bahamut"]
т.е. все данные игры (физические объекты, строки, скрипты и проч.) нам надо разместить в одном массиве, а потом при каждом чихе прогонять все эти данные через SPE? ты представляешь что такое игровой объект? у тебя в одном объекте обычно лежит хренова куча всего - координаты, направление, анимационные данные, количество жизни, прорва всяких состояний, матриц, ссылок на другие объекты, строки, синхронизационные данные итд итп. даже если все объекты одного типа лежат в одном массиве, ты предлагаешь ВСЕ ЭТО прокачивать каждый раз через SPE, чтобы использовать из всего этого позицию, скорость и массу???[/quote]

Блин, если у тебя такие трудности -- сделай отдельный массив физических данных с индексом на более крупный массив с "количествами жизней" и прокачивай черз SPE только его. :)

[quote name="Bahamut"]
это один из популярных методов поиска объектов в пространстве и исключения объектов, не видимых в сцене (формирование PVS). обычно что-то подобное лежит в сердце любого 3д движка. не oct-tree, так bsp. не bsp, так порталы.[/quote]

Нуууу... BSP кажется формировалось только для уровня и один раз ещё на процессе создания уровня. Видимо сейчас у вас там другие порядки. Но ежели по условию задачи так и так прогоняем все координаты черз SPE во время физических расчётов, то почему бы просто не персчитать все координаты в системе координат с камерой в начале координат, повёрнутой вверх вдоль оси Z и отбросить все точки у которых Z^2

• Наверх

[JayDi 1]

Gera, посмотри на дату этой статьи: 17 марта 2005. А официальная и полная инфа о Cell'e была зарелизина лишь 8 августа. Так что актуальность и правильность всех этих рассуждений - под большим вопросом.
P.S. У каждого SPE есть 128 128-и битных регистра (общего назначения). А это ой как много. Вот поэтому в SPE и нет кеша, который работает на порядок медленнее сверхбыстрых регистров.

[Bahamut 0]

[quote name="Togusa"]Нуууууу... Мне всегда казалось, что число этих данных не сильно выросло со времён Quake 1 или Unreal, в отличие от медийных, геометрических и физических, число которых выросло порядка на два... И с этими "игровыми" данными вполне справится PPE, пока SPE лопатят физику, геометрию, звук и сетевые данные.[/quote]

1. выросло сильно
2. то, что GPU рендерит графику не значит, что в движке нет работы с геометрией

[quote]Ага... Ну ты уж извини, но по моему нагружать Cell задачей с которой в системе обязан справляться RSX, это идиотизм.[/quote]
еще раз повторяю - это просто абстрактная задача, которая демонстрирует ущербность архитектуры.

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

[quote]Вроде мы выяснили, что это не совсем так? :)[/quote]

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

[quote]Но ежели ты так хочешь алгоритм, пожалуйста. SPE0 считывает текстуру как линейный поток данных, разбивает его на цветовые компоненты из которых, скажем, красную оставляет себе, а остальные передаёт SPE1-SPE3 каждый из них определяет новые линейные координаты компоненты точки (что кстати позволит сделать эффект разделения по цветам при желании), и скидывают их в буфер в LS. По мере накопления точек с текущими координатами они скидываются в SPE4, который опять собирает цветовые компоненты вместе и скидывает результат в память.
Ограничение у алгоритма есть. Необходимое условие для твоей текстуры -- в среднем точки не должны уходить от своих начальных линейных координат более чем на одну двадцатую размера текстуры. Но для эффекта ряби, марева, искажения -- вполне себе рабочий алгоритм. И поточный к тому же. :)[/quote]

это опять бессвязный набор слов, а не алгоритм. даже если текстуру разбить на компоненты, компонент не влезет в LS. кроме того, текстур обычно кладут больше 1. или ты имел ввиду, что все как-то текстурируется пока текстура "прокачивается"? это нереализуемо, т.к. текстура 2хмерная и может лежать как попало - повернутой на 90 или 180 градусов, растянутой как угодно.

[quote]Блин, если у тебя такие трудности -- сделай отдельный массив физических данных с индексом на более крупный массив с "количествами жизней" и прокачивай черз SPE только его. :)[/quote]

такая архитектура хранения данных фигова для PPE, и чудовищно неудобна для программистов.

[quote]Но ежели по условию задачи так и так прогоняем все координаты черз SPE во время физических расчётов, то почему бы просто не персчитать все координаты в системе координат с камерой в начале координат, повёрнутой вверх вдоль оси Z и отбросить все точки у которых Z^2
опять куча слов, не имеющих вообще никакой связи с реальностью. какая нахрен камера? причем тут камера вообще?

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

[Togusa 3]

[quote name="Bahamut"]
[quote]Ага... Ну ты уж извини, но по моему нагружать Cell задачей с которой в системе обязан справляться RSX, это идиотизм.[/quote]
еще раз повторяю - это просто абстрактная задача, которая демонстрирует ущербность архитектуры.[/quote]

Ну да взяли сибирские мужики японскую бензопилу и подсунули ей стальной лом. Не выдержала бензопила, сломалась. Доказалаи сибирские мужики слабость японской техники! Эдак вам абстрактную задачу, доказывающую полное ничтожество процессоров Intel перед аналоговыми компьютерами приведут.
Попытки рассматривать отдельный компонент вне системы -- это вопиющий идиотизм.

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

Бог ты мой. На асме для Агат 7 кодил, на Бейсике писал, на C интерфесы рисовал, на автолиспе дипломный проект выполнял. Поздно товарищ меня от программирования отгонять. Опоздали.
Но вы не огорчайтесь товарищ, работодатель заставит, и на SPE запишете за милую душу. И данные на потоки раскидывать научитесь и текстурировать и физику считать... :)

[Artiom 1]

[quote]Но вы не огорчайтесь товарищ, работодатель заставит, и на SPE запишете за милую душу. И данные на потоки раскидывать научитесь и текстурировать и физику считать... [/quote]
Вот она, сермяжная правда, респект Togusa :up: Кому охота работать тот работать будет в конце концов и будет зарабатывать. А кто легких денег хочет - будет канючить до самой смерти.

[Warge 0]

[quote name="SSnake"] [quote]Но вы не огорчайтесь товарищ, работодатель заставит, и на SPE запишете за милую душу. И данные на потоки раскидывать научитесь и текстурировать и физику считать... [/quote]
Вот она, сермяжная правда, респект Togusa :up: Кому охота работать тот работать будет в конце концов и будет зарабатывать. А кто легких денег хочет - будет канючить до самой смерти.[/quote]
Тебе один раз уже сказали? Школу закончи вначале - потом разглагольствовать будешь.

[Artiom 1]

[quote name="Warge"] [quote name="SSnake"] [quote]Но вы не огорчайтесь товарищ, работодатель заставит, и на SPE запишете за милую душу. И данные на потоки раскидывать научитесь и текстурировать и физику считать... [/quote]
Вот она, сермяжная правда, респект Togusa :up: Кому охота работать тот работать будет в конце концов и будет зарабатывать. А кто легких денег хочет - будет канючить до самой смерти.[/quote]
Тебе один раз уже сказали? Школу закончи вначале - потом разглагольствовать будешь.[/quote]
А ты для начала из детсада выберись :-D

[Togusa 3]

[quote name="SSnake"]Кому охота работать тот работать будет в конце концов и будет зарабатывать. А кто легких денег хочет - будет канючить до самой смерти.[/quote]

Да не. Баламут -- человек очень интересный. Как и EF. Помог мне разобраться, почему IBM называет Cell потоковым процессолром процессором.
С другой стороны, конечно Epic для меня больший авторитет и их утверждениям о том, что UE3 замечательно работает на PS3 я поверю скорее, чем утверждениям о том. что такого быть не может потому что не может быть никогда.
А стоны о том, что для Cell алгоритмы надо переписывать и кое где менять в корне -- это всё известно давно. Теперь я узнал, в чём видят трудности профессиональные программисты. :) Похоже не зря EA создаёт специальныее учебные курсы для Cell программеров.

[Artiom 1]

[quote]Похоже не зря EA создаёт специальныее учебные курсы для Cell программеров.[/quote]
А вести их будут ребята из Сони?

[Bahamut 0]

[quote name="Togusa"]Ну да взяли сибирские мужики японскую бензопилу и подсунули ей стальной лом. Не выдержала бензопила, сломалась. Доказалаи сибирские мужики слабость японской техники! Эдак вам абстрактную задачу, доказывающую полное ничтожество процессоров Intel перед аналоговыми компьютерами приведут.
Попытки рассматривать отдельный компонент вне системы -- это вопиющий идиотизм. [/quote]

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

[quote]Бог ты мой. На асме для Агат 7 кодил, на Бейсике писал, на C интерфесы рисовал, на автолиспе дипломный проект выполнял. Поздно товарищ меня от программирования отгонять. Опоздали.[/quote]

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

[quote]Но вы не огорчайтесь товарищ, работодатель заставит, и на SPE запишете за милую душу. И данные на потоки раскидывать научитесь и текстурировать и физику считать... :)[/quote]

вы смешные. я-то напишу. только заплатите мне за это [b]вы[/b]. из своего кармана. кругленькую сумму.

[Togusa 3]

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

Ага, уонечно! Лом -- это частный случай ствола. Если бензопила неспособна распилить лом, то какая речь может идти о пилении досок, книжных досок и создании авиамоделей из фанеры?!!

Массивы, товарищ, бывают разные. От таблиц квантования до RAW-файлов Фотошопа, обработка которых погружала в глубокую задумчивость не один компьютер. :)
И знаете, если на Cell прекрасно (48 потоков одновременно!) работает непростой в принципе алгоритм вопроизведения MPEG2, то думается мне, ваши слова о неспособности SPE к элементарным операциям сиииильно преувеличены. Да, от программера под SPE требуется большая продуманность действий, большее внимание к организации данных, использование приспособленных к паралельным вычислениям алгоритмов, но вот таких вот страшных ограничений, как вы говорите нет. :)
Программеры из Epic тоже эти ограничения как-то обошли, так что я скорее поверю в то что инженера IBM не полные маразматики. :)

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

Что, Винера уже отменили? Программируем кубиты и ДНК? :)

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

Конкретно вам из моего кармана достанется максимум центов пятьдесят. Можете выпить на них пива. ;)

[Bahamut 0]

ладно, медицина тут бессильна.

[JayDi 1]

Bahamut, а давай еще аудио-карты от Creative попробуем заставить работать с текстурами? А потом будем утверждать, что в этой компании сидят одни лохи и ничерта не умеют делать аппаратуру.

[Togusa 3]

[quote name="Bahamut"]ладно, медицина тут бессильна.[/quote]

Добро пожаловать в морг, товарищ! :)

[Wildduck 0]

Неужто и тут нашлись свои мажоры, которые доказывают что 360 лучше пс3? )))

[Gera 0]

Неужто и тут нашлись свои мажоры, которые доказывают что ПС3 лучше 360? )))
:gigi:



Детальное 360 и ПС3 сравнение от компетентного источника
Microsoft's Xbox 360, Sony's PS3 - A Hardware Discussion
[url=http://www.anandtech.com/video/showdoc.aspx?i=2453]http://www.anandtech.com/video/showdoc.aspx?i=2453[/url]
одностраничный вариант из форума специалистам читать обязательно :clever:
[url=http://www.ps3forums.com/viewtopic.php?t=3532]http://www.ps3forums.com/viewtopic.php?t=3532[/url]

[xtr 878]

2Gera: [Статья хорошая, но есть много сомнительных мест. Плюс ко всему, я не уверен, что они видели продукты в живую.

[Gera 0]

Сделать такой детальный анализ не имея возможности ознакомиться с железом практически невозможно ИМХО :clever:Документации по Пс3 у него явно достаточно вот RSX пока полных данных нет, ваще готов ли он :confused: Может Соня планирует всёж совместо с НВИДИА хорошенько переработать его :upset:

[Bahamut 0]

[quote name="Gera"]Детальное 360 и ПС3 сравнение от компетентного источника
Microsoft's Xbox 360, Sony's PS3 - A Hardware Discussion
[url=http://www.anandtech.com/video/showdoc.aspx?i=2453]http://www.anandtech.com/video/showdoc.aspx?i=2453[/url]
одностраничный вариант из форума специалистам читать обязательно :clever:
[url=http://www.ps3forums.com/viewtopic.php?t=3532]http://www.ps3forums.com/viewtopic.php?t=3532[/url][/quote]
слушай, ты уже это сравнение в этом топике практически целиком запостил :gigi:, не говоря уже о бесконечных ссылках на одно и то же. сонибоям и прочим фанатам это все бестолку - они по-английски читать не умеют. все остальные имхо давно прочитали.

статья хорошая, но не без изъянов, в частности по теме, которую тут обсуждали:

[quote]One method of implementing collision detection in a game is through the use of a Binary Search Partitioning (BSP) tree. BSP trees are created by organizing lists of polygons into a binary tree. The structure of the tree itself doesn’t matter to this discussion, but the important thing to keep in mind is that to traverse a BSP tree in order to test for a collision between some object and a polygon in the tree you have to perform a lot of comparisons. You first traverse the tree finding to find the polygon you want to test for a collision against. Then you have to perform a number of checks to see whether a collision has occurred between the object you’re comparing and the polygon itself. This process involves a lot of conditional branching, code which likes to be run on a high performance OoO core with a very good branch predictor.

Unfortunately, the SPEs have no branch prediction, so BSP tree traversal will tie up an SPE for quite a bit of time while not performing very well as each branch condition has to be evaluated before execution can continue. However it is possible to structure collision detection for execution on the SPEs, but it would require a different approach to the collision detection algorithms than what would be normally implemented on a PC or Xbox 360.[/quote]

они все перепутали и во всех бедах обвинили отсутствие branch prediction процессора, в то время, как настоящая проблема в невозможности заранее предсказать по какой ветви BSP пойдет поиск (тоже branch prediction, но совсем из другой оперы), и соответственно заранее сформировать запрос на доступ к памяти со всеми вытекающими.

[Gera 0]

Дык его вроде стёрли Вот я и подправил :upset:

[Bahamut 0]

упс. сорри, похоже это у меня уже глюки. это наверно где-то в другом треде было :oops:.

[Togusa 3]

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

Было-было... Никаких глюков. Я смотрел и думал, почему человек просто ссылку не кинул. :)

[size=75]Добавлено 09 Сен 2005, 12:32:[/size]

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

Кстати, а что скажешь про [url]http://graphics.stanford.edu/papers/tpurcell_thesis/tpurcell_thesis_lowres.pdf[/url]

RAY TRACING ON A STREAM PROCESSOR -- дипломный проект какого-то чела, который тесно сотрудничал с nVidia. Он вместо BSP использовал некую Uniform grid, утверждая что оно хардварно хорошо ускоряется.

Я глянул, что за зверь и на [url]http://www.gamedev.ru/forum/?group=0&topic=13874&page=2[/url]
утверждают

[i]Регулярная сетка хороша для физического collision - т.к. движущиеся тела имеют небольшой фиксированный размер - быстро выбираем узлы для AABB тела (обычно получается 4-8 узлов) и отправляем входящие треугольники физ. двигу.

Для рендера - только иерархия. Для больших пространств имхо лутьше объектная иерархия (строится частично дизайнером) - типа мебель->комната->дом->квартал->деревня. Хотя для большого дома стоит сделать свой октри.

Для земли - квадтри (т.к. октри - лишнее третье измерение никчему), или секторами (я так делаю). [/i]

[Bahamut 0]

[quote name="Togusa"]Кстати, а что скажешь про [url]http://graphics.stanford.edu/papers/tpurcell_thesis/tpurcell_thesis_lowres.pdf[/url]

RAY TRACING ON A STREAM PROCESSOR -- дипломный проект какого-то чела, который тесно сотрудничал с nVidia. Он вместо BSP использовал некую Uniform grid, утверждая что оно хардварно хорошо ускоряется.[/quote]

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

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

[quote]Я глянул, что за зверь и на [url]http://www.gamedev.ru/forum/?group=0&topic=13874&page=2[/url]
утверждают

[i]Регулярная сетка хороша для физического collision - т.к. движущиеся тела имеют небольшой фиксированный размер - быстро выбираем узлы для AABB тела (обычно получается 4-8 узлов) и отправляем входящие треугольники физ. двигу.

Для рендера - только иерархия. Для больших пространств имхо лутьше объектная иерархия (строится частично дизайнером) - типа мебель->комната->дом->квартал->деревня. Хотя для большого дома стоит сделать свой октри.

Для земли - квадтри (т.к. октри - лишнее третье измерение никчему), или секторами (я так делаю). [/i][/quote]

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

[Togusa 3]

[quote name="Bahamut"]да, и что дальше? чем объемная регулярная сетка (трехмерный массив) лучше, чем текстура (двухмерный массив)? и как
она поможет получить доступ к объектам в основной памяти?[/quote]


Да нет... Сетка предлагалась как замена oct-tree. Кстати говоря об oct-tree -- правильно я понимаю, что это дерево вершина которого -- координаты точки в пространстве, которая разбивает его на восемь секторов (кубов, грубо говоря) и сслыки на восемь других вершин дерева которые в свою очердь являются точками лежащими в этих секторах и бьющими их ещё на восеь подсекторов и т.д. и т.д. И задача "невыполнимая для Cell" -- это быстро пройти черз ссылки по вершинам дерева и определить в коком из секторов находится точка? :)