Хотелось бы обсудить данную разработку http://www.hwp.ru/articles/Lucid_HYDRA_polozhit_konets_SLI_i_CrossFire__71466/, Нвидиа "обкакала" эту технологию по понятным соображениям печально, что Нвидиа занимается заколачиванием бабок, а не на благо пользователей

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

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

Среди меня бытует мнение, что не в этом дело. Все-таки себестоимость чипа и разводки под него стоит дороже тех пары $, сэкономленных на лицензировании SLI. Даже если на плате стоит Lucid Hydra, скорее всего производитель все равно заплатит за SLI. Я уверен, что в комплектации MSI BigBang мы по-прежнему увидим SLI и CF мостики, чтобы пользователь мог выбирать, в каком режиме использовать связку видеокарт. Глубинный смысл заинтересованности Lucid Hydra со стороны Intel лежит в перспективах Intel Larrabee.

если я не ошибаюсь лицензия на сли для х58 стоит немного больше пары долларов. Вроде 10$ если не ошибаюсь, и это с каждой платы.

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

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

Добавлено спустя 1 час 6 минут 8 секунд:
исправьте кто-нибудь название темы, глаза режет такое будуЮщее

Я думаю нвидиа и амд вместе задушат данную разработку... хотя конечно интересно было бы увидеть как это все будет работать

Ни один из этих методов Lucid Hydra не использует и в этом его преимущество. Представьте себе, что есть чип, который сам распараллеливает вашу программу на несколько потоков для поддержки многоядерности. Именно это делает Lucid Hydra при построении сцены. Он распределяет нагрузку между видеокартами на уровне инструкций, посылаемых через PCI-E, поэтому его и называют чип-коммутатор. Такой подход позволяет во-первых увеличивать производительность пропорционально увеличению количества задействованных видеокарт, во-вторых распределять нагрузку между разнородными видеокартами, в-третьих исключить необходимость поддержки драйверами каждой конкретной игры ну и самое вкусное - избавиться от фризов SLI/CF в режиме AFR вследствие неравномерного вывода кадров. Этот чип можно встраивать не только в мат. платы, но и сразу в многочиповые видеокарты.

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

Потому что NV и AMD конкуренты

Ну наверно им было лениво заниматься таким

Рекламу все читали. Вопрос остается открытым, и нигде я не видел на него ответ. Каким образом чип-коммутатор заставляет драйвер видеокарты делать только нужную этому чипу работу, КАК? Если только с ним не идет API-перехватчика а-ля 3DAnalyse, то НИКАК. И как быть с выводом картинки? Чип-коммутатор не может ее получить от видеокарт. Они будут упорно слать ее на свои выходы. Т.е. опять же нужен какой-то свой выход и софт, который скринит картинку от видеокарт. Или тупо какой-то девайс-сумматор, который цепляется на выходы карт. И тогда встает вопрос. А чем вообще здесь будет занят чип hydra? Ему же не остаеся работы.

Anvin Пример работы в Unreal Tournament продемонстрирован на фотографиях по ссылке выше. Почему никто из производителей не додумался ускорять физику видеокартами до того, как Ageia выпустила свой физ. ускоритель? Позднее все это вылилось в более широкую сферу применения - ускорение вычислений силами GPU, но для того чтобы Nvidia начала действовать, потребовался пинок извне. Даже если Lucid HYDRA не будет встраиваться в каждую mb, он вполне может стать началом цепной реакции встраивания чипов-коммутаторов прямо в GPU.

Добавлено спустя 5 минут 59 секунд:
DirectX передает команды драйверу-перехватчику, тот посылает их в Lucid Hydra, из него на вход видеокарт идет 2 потока инструкций, с выхода видеокарт результаты отправляются опять на Lucid Hydra, тот их соединяет и отдает на вывод (видимо одной из видеокарт, к которой подключен монитор).

ckotick
Неправильный вопрос, для него есть работа.

Добавлено спустя 9 минут 11 секунд:

Так, значит перехватчик софтовый есть . Дальше идет невероятное. Ладно, драйвер-перехватчик знает набор команд собственного чипа, это логично. Дальше чип посылает команды видеокартам. Это фантастика, чип заменяет драйвера видеокарт, независимо от их проиводителя. Такой сценарий исключен. Возможно только, что API-перехватчик отсылает вызовы дальше в реальный API. Т.е. на этой стадии чип вообще не нужен. И каким образом мы получаем результат? Если ничего не вешать на выходы карты, то только софтом. Снова не ясно нафиг нам чип. Затем компонуем 2D-картинку и отправляем на одну из карт для вывода. И снова нафиг тут чип? Или все-таки картинки с карт ловит софт, отправляет в чип, тот компонует (нереально трудная работа, достойная заведения отдельного чипа и введения дополнительных лагов на пересылку по шинам), отдает обратно софту (или чип имеет свой выход? это бы хоть как-то оправдало его существование), тот снова шлет на карту. Неверояно "изящное" решение, грозящее вагоном лагов и глюков пока API-перехватчик будут оттачивать (что может расстянуться на годы).

Представьте себе, что есть чип, который сам распараллеливает вашу программу на несколько потоков для поддержки многоядерности. Именно это делает Lucid Hydra при построении сцены. Он распределяет нагрузку между видеокартами на уровне инструкций, посылаемых через PCI-E, поэтому его и называют чип-коммутатор.

если бы это было так то этот чип нуно было встраивать перед совеременными процессорами и лафа программерам не нуно перекомпилировать покупать дорогущий софт для програмирования под многоядерники
вставил такой чип перед процессором и пожалуйста любая прога использует все 8 ядер коре ай или 12 ядер ядер коре ай 9

но если бы это было так просто...
так что скорее всего этот вариант отпадает

TIMBERWOLF К сожалению перед x86 процессором такой чип не вставить на данном этапе и даже простым перекомпилированием не удастся обеспечить многоядерность для большинства приложений. Возможно ситуация изменится, если разработают новую модель программирования. Но вывод 3D графики как раз очень эффективно распараллеливается, поэтому одна и та же сцена ускоряется при использовании например 240 потоковых процессоров в одной видеокарте по сравнению с 96 в другой.

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

а мелкомягкие когда пишут api что тоже должны знать ???