Benchmark

Здравствуйте.
Как Вы все безусловно знаете, в последнее время стало очень модным тестировать железо на пакетах трёхмерной графики. Но, так как ни один из российских (да и не только) сайтов занимающихся обзорами hardware не может похвастаться тем что в своих рядах имеет человека, который разбирается в таких пакетах проффесионально, то тестирования эти проходят как кому бог на душу положит. В отличии от того же Photoshop где есть уже устоявшиеся методики. Я являюсь постоянным автором 3Dnews и пишу, в частности, про SMP машины. Я был бы очень благодарен, если Вы поможете выработать стандартную методику тестирования в, скажем, 3D MAX. Что бы тестировалось не то, что мне кажется правильным, а те параметры которые дествительно важны в работе.
Один из наших читателей уже обратил внимание на то, что существующие методики тестирования мягко выражаясь несовершенны, и выразил готовность создать несколько абстрактных сцен которые, по его мнению, правильно нагрузят машину. Он же посоветовал мне обратится сюда за помощью, так как не считает себя достаточно компетентным, что бы решить такую проблему в одинчку. Так что если у Вас есть своё мнение о том, как ПРАВИЛЬНО тестировать компьютеры в программах 3D графики, и Вы готовы потратить некоторое количество Вашего времени на выработку методики, то милости просим.

 

[Vaicartana]

1. Сцена должна быть достаточно большой для кэша, но достаточно маленькой для памяти. Это уберет своп с диска или сведет его к минимуму (т.е. лишние уйдут тормоза) и по идее должон показать мощь интела 8)).
2. В Махе дольше всего считаются ВолумЛайты и РэйТрейсы - используется сопр. Поэтому многие так любят атлоны.
3. Ну и ессно видюха. Чем быстрее она будет все это крутить тем быстрее идет процесс моделинга/анимации. Проверять надо на как на вирефреймах, так и на хайлайтах.
Можно также смотреть на параметр передачи винт-->мемори и обратно.
Сцена должна быть анимирована и получено среднее время рендера.

 

Итак, есть первые результаты. Ниже будет приведенна цитата с предпологаемой методикой тестирования. Все нобходимые файлы: фотошоповский файл действий для создания текстуры и сами сцены могут быть высланы по почте всем желающим принять участие в нашем благородном деле. Размер архива - 43 килобайта.

1. Сложные материалы.

1.max - сцена с большой битовой картой, содержащей
шум. Здесь я попытался сымитировать совокупность
высококачественных карт, когда объект надо поставить
очень близко к камере. Обычно, конечно, карты
используют не такие здоровые (а 2000*2000 где-то или
поменьше) - это своего рода гротеск, чтобы
хорошенько заставить комп. поработать с памятью и
проверить его пропускную способность (при этом не
дав сжать данные). В реальной ситуации карт может
быть несколько, но меньшего размера.
Тем не менее, это тест относительно быстрый по
прохождению, и он тем более проходит быстрее при
повторном рендеринге (такой же эффект как при
кэшировании).

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

Ещё полезно, наверное, в будущем сделать сцену,
когда шум генерится на текстуре в самом пакете, а
кадров - большая последовательность - все
сохраняются на винте. Так поток будет больше на
поток похож.

3.max - сцена с рэйтрэйсовым материалом.
Нагрузка плавно возрастает, потому что компу
приходится ещё рассчитывать путь световых лучей. Всё
это соответственно нагружает память и проц.

Далее по плану (пришлю попозже):

Сцена с рэйтрэйсовым материалом с горением внутри
(атмосферный эффект).

Сцена с рэйтрэйсовым материалом со сложной физикой
движений (объёмные деформации, частицы).

Сцена с дисплэйсовым материалом (текстурой
замещения).

Сцена с материалом сложной структуры.

2. Объекты.

Сцена с большим количеством объектов с одинаковой
битовой текстурой большого размера.

Сцена с большим количеством нетекстурированных
объектов.

Сцена с большим количеством граней объекта.


3. Эффекты и окружение.

Смаз объекта.
Смаз изображения.
Глубина резкости.
Объёмный свет.


4. Ресурсы Видеокарты.

Тестирование на стандартных бенчмарках. Ещё как-либо
тестировать трудно, потому что неизвестно как и чем
мерить. Класс карты очень важен при работе в окнах
проекций, но посчитать FPS при работе на ручном
приводе трудновато. Поэтому этот вопрос в целом
тяжёлый, его надобно серьёзно обсудить с кем-то из
знатоков.


5. Основные плагины.
Reactor - расчёт механики движения объектов.
(перед рендерингом, в процессе отладки)


Со следующими вещами я плотно не работал, поэтому
про них лучше у кого-нибудь ещё спросить.

Mental Ray - рендеринг.
Character Studio - что конкретно тестировать, надо
ещё придумать.

 

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

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

 

Тут хотелось бы дабавить пару слов о тестах, как таковых...(к 3-D имеет самое прямое отношение - я работал тогда на 3D Studio R3 (DOS))

Ещё в бытность 486 компов я прикупил себе (стоимость даже называть не буду...) ) ещё 8 Мб памяти к 8-ми имеющимся... И если бы не появившиеся в то время тесты от Ziff-Davis, то я наверное так и не узнал бы, что мой "свежекупленный" модуль память конкретно тормозил систему...:-(( Выяснилось это просто... На работе стоял точно такой же комп (оба были куплены одновременно) и "делал" моего "домашнего" в полтора с лишним раза!... Как только я вернул всё назад, вытащив лишнюю (вот ведь сказанул ) ) память, всё заработало как надо...
Всё это я сказал только для того, чтобы объяснить "полезность" тестов, как класса...

 

Вопрос про правильную методику тестирования поднял, между прочим, не я. А человек который утверждает что именно максом и занимается проффессионально. И его не удволетворяет рекомендация "памяти побольше и проц пошустрее". Человеку охота знать, например, что даёт в максе применение разных видов этой самой памяти. И у него есть сильное подозрение, что при различных задачах влияние пропускной способности памяти различно. Он хочет знать, как различные системы ведут себя при повышении количества объектов или полигонов. Его интересует чего и где SSE даёт/не даёт. И ему не понятно, почему для Photoshop'а есть выработаная методика, когда можно посмотреть как и общую скорость выполнения тестов, так и скорость маленьких фильтров, на основе чего можно ответить практически на любые вопросы, что и как работает. а для макса нет. Есть только советы "памяти больше, и проц побыстрее. Не хватает? Значит ещё больше, и ещё быстрее".

 

там обрабатывается битовая карта...
геометрия как таковая отсутствует напрочь !
ну да... есть фильтры, есть интерполяция,
и всё равно в конечном итоге берётся общее кол-во точек и множится на время той или иной обработки каждой точки...
а в максе слишком велика разнородность выполняемых процессов...
ну... в принципе оно конечно можно понаделать разнородных
сцен, но тогда придётся писать, что такая-то конфигурация
хорошо выполняет операции с рейтрейсами, такая-то - с просчётом физики и динамики, такая-то - с таким-то плагином, такая-то - со сто пятьдесят восьмым плагином... их же чёрт-те сколько... и раз в месяц новый выходит !
параметров тестирования тогда наберётся несколько десятков...
пользователь в конечном итоге запутается !!! ( имхо )...
сегодня в магазине столкнулся с ситуацией...
продавец консультирует покупателя, спросившего о наилучшей
конфигурации компа для трёхмерки - хочет сыну подарить на
совершеннолетие, а тот (сын) сильно увлекается 3Д...
так много нового узнал !!! оказывается, что для трёхмерки самое главное -
это чтоб была самая мощная видеокарта !!!
а на такие мелочи, как оперативка и процессор можно даже
внимания не обращать !!!
и это не мелкая лавочка, а компьютер-центр "КЕЙ" !!!
я, естесственно, шороху там навёл, но надо для начала ликбез
хотя бы для таких продавцов устроить, а потом уж к тонкостям
переходить... ну это так, к слову...
я, в общем-то, не против выработки методы для разностороннего
тестирования, но этим надо заниматься конкретно,
и помимо самого макса ещё и знать архитектуру процессов...
а откуда ??? достоверной информации у меня, например, нет ...
если кто поделится - буду благодарен !!!

 

allex wrote:
> ну... в принципе оно конечно можно понаделать разнородных
> сцен, но тогда придётся писать, что такая-то конфигурация
> хорошо выполняет операции с рейтрейсами, такая-то - с
> просчётом физики и динамики, такая-то - с таким-то плагином,
> такая-то - со сто пятьдесят восьмым плагином... их же чёрт-те
> сколько... и раз в месяц новый выходит !
> параметров тестирования тогда наберётся несколько десятков...
> пользователь в конечном итоге запутается !!! ( имхо )...

В том то проблема и состоит, что бы найти оптимальное соотношение количества и качества. И сделать это могут только люди которые работают с пакетом проффесионально.

> я, в общем-то, не против выработки методы для разностороннего
> тестирования, но этим надо заниматься конкретно,
> и помимо самого макса ещё и знать архитектуру процессов...
> а откуда ??? достоверной информации у меня, например, нет ...
> если кто поделится - буду благодарен !!!

Саму архитектуру? Откуда - ответ элементарен, для AMD

http://www.amd.com/support/techdocdir.html

Для Intel, по P4, например

http://developer.intel.com/design/pentium4/datashts/

Вот только чтение это для неподготовленного человека мягко выражаясь сложновато...

 

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

 

3-дешник должен знать на каких задачах его быстродействие интересует. Потому что железячник этого точно не знает. Зато железячник может пощупать железо НЕ ПОКУПАЯ его. И рад бы он сказать 3-дешнику, надо ли ему, например меньше но DDR, или лучше больше, но SDRAM, да не знает он, как выяснить, что и где лучше.