Everlast82
Ну так между api и железом драйвера производителя.

Everlast82
Нет, API передает комманды драйверу производителя. Разве это не очевидно?

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

Ага - реклама нового PCI-E комутатора Хотя, вспомним "єверест" с аппаратным транслятором - может и тут нечто подобное(таки бабаян не зря в интеле трудится ). Итого мы будем имент немного запутанную топологию: картинка поступает на чип(хотя, как тут говорили - мона это и софтом делать), тот её делит и выдаёт результат на драйвер производителя карты, которые в свою очередь выдают данные на карту. Встаёт вопрос как потом собирать картинку обратно? Можно пойти сложным путём - брать результат расчётов картинки с карты, гнать обратно в чип, собирать, и опять выводить на какую-то карту для вывода в монитор. Мона и проще - делать вывод картинки сразу с "гидры". И опять вопрос - а зачем сам гидра нужен, если всё можно проделать на софтовом уровне(разве что для сбора результатов и вывода картинки нужен отдельный чип, которым с успехом может стать встроенная видюха!).

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

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

Имхо ждем мамки MSI, где это добро будет на борту, и результатов тестов + обзоры . (а, ткните плз носом, где почитать про работу SLI?)

Не будем спорить возможен/невозможен, еще не такие задачи выполняли и сколько современных достижений используется сейчас, считавшихся невозможными...
Чтобы производительность не упиралась в CPU - вот для чего. Специализированный чип, заточенный под конкретную задачу может выполнять эту задачу быстрее, чем универсальный CPU. Если не использовать Lucid Hydra, то при таком способе возросшая нагрузка на процессор вообще может превратить игру, которая выдает 120 fps в среднем в нечто неиграбельное.
начальный спрос, которым могла бы заинтересоваться крупная компания не может сформироваться без "венчурного стартапа вроде агеи".
вам юзерам AMD - может и нет, но многим пользователям NV нужна.
В 30 раз медленнее или с гораздо меньшим числом объектов. Есть задачи, которые GPU выполняют эффективнее, а есть те, которые они пока не могут выполнять. Если физика значительно ускоряется при использовании GPU, то пусть они её и просчитывают.
High-end продавался и будет продаваться, даже несмотря на небольшой % пользователей, прибыли все равно окупают разработки и с каждым годом этот % пользователей, которые ставят несколько видеокарт/двухчиповые видеокарты, увеличивается. Была даже новость на этом сайте, что к какому-то году в большинстве игровых PC будут стоять многочиповые решения. Если этот сектор был бы убыточен, стали бы производители выпускать все более дорогие видеокарты? А если повысить эффективность и избавиться от недостатков многочиповых конфигураций с помощью Lucid Hydra или каким-то другим способом, количество пользователей multi-GPU станет еще больше.

http://programmersclub.ru/gruzin-api-perhvat/

Everlast82
Из этого вообще хоть что-то следует?

Everlast82
По данной ссылке речь вообще идет о программном (а другой невозможен в данном случае) перехвате вызовов приложение>API. Собственно я сразу предположил, что новый чудо-чип так и работает (вернее работает некая идущая с ним софтина, а чип с большой долей вероятности лежит мертвым грузом).
И да, причем здесь вообще то, что софт MS абстрагирован от конкретного железа благодаря драйверам вендоров?

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

Добавлено спустя 2 минуты 41 секунду:
особо ни при чём, но возможно драйвер гидры выглядит для драйверов видеокарт как обычный API.....

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

Если только драйвера гидры. Вот только ускорение чего на него можно повесить чтобы перегоны по шине оправдали себя? Обработка API-вызовов не настолько ресурсоемкая задача, но при этом требующая минимум задержек.

Итого, подводя итог - чип "гидра" служит просто интеллектуальным PCI-E коммутатором-перераспределителем, раздающим нужные данные на нужный разьём PCI-E и потом собирающем эти данные обратно в общую картинку. Всё остальное с 99.99% вероятностью будет делать драйвер этой гидры. И как всегда(в таком случае) - всё упрётся в процессор. Главное, чтоб драйвер мог распараллеливать потоки вычислений.

во-во, тоже такая мысль посетила

Добавлено спустя 24 минуты 33 секунды:
если им верить то получается что это даже быстрее чем то что мы сейчас имеем.

Описание для домохозяек, подумать только "команды OpenGL и DirectX от процессора к графическому процессору".

Everlast82
4e_alex
ХЫ! А я вот только щас задумался над кое-чем интересным - если верить описанию, внутри чипа "гидры" должен стоять полностью рабочий компьютер, который для "большого" процессора(равно как и для системы) будет выглядеть как единичная видеокарта, а для видях - как тот-же компьтер, но нагружающий каждую своей работой. Итого, в "гидру" УЖЕ должны быть вшиты все данные по всем известным видяхам, УЖЕ должна стоять своя система(100% чтонить асамблерное, самиздатовское, заточенное на скорость), ну и все возможные драйвера и ДХ-сы для всех возможных систем По другому это не выполнить. Чип гидры должен работать на аппаратоном уровне. Иначе всё плюсы умрут под софтовой реализацией.
Хотя прошлый вариант с "интеллектуальным коммутатором" и драйвером-перехватчиком выглядит более реально. Но тут о отсутствии задержки можно даже не упоминать! Конечно, результирующие данные(разделённые) и команды к чипу гидры пойдут "практически без задержек и без отправки служебных команд центральному процессору"(ибо всё ужо посчитано ). Встаёт всётаки вопрос - а как они будут собирать картинку обратно?

Так для чего железка то нужна? Если софтовая часть гидры работает между приложением и драйвером видеокарты или/и между драйвером и GPU, то получается, что гидра это в первую очередь очень сложный программный продукт. Стороннему разработчику, без поддержки NVIDIA/AMD, это реализовать вряд ли получится. Наверное, гидра коммутирует сигналы поступающие на шины PCI-E, распределяя их по GPU. Но как то сомнительно, что на этом уровне можно придумать какие-то производительные алгоритмы диспетчеризации. И как картинка собирается, а затем выводится на экран...

Никогда не изменится. Распараллелить бинарный код на потоки - это ненаучная фантастика. Я сам являюсь разработчиком ПО и мне регулярно приходиться фиксить баги, связанные с многопоточностью. Для распараллеливания даже на уровне компилятора нужно создать не просто искусственный интеллект, а искусственный сверхинтеллект. Распараллеливание - это задача, начинающаяся на этапе разработки архитектуры приложения, это неформализуемая задача. Сложность находится на уровне синхронизации и сложных семантических зависимостей, которые даже по исходному коду, даже очень опытному программисту, порой, без помощи документации не понять, какой уж тут робот. Есть правда такая штука как функциональное программирование, которое допускает естественное автоматическое распараллеливание. Но как показывает практика чистый функциональный подход бессилен к решению универсальных задач. И время здесь не поможет - функциональный и императивный подходы родились почти одновременно (54 и 58 года).

ГЫ! А ведь в стартовой статье всё ЭТО и написано:
- "движок"(в простонародье "драйвер") как раз и будет делить, а чип только: - ну чем вам не обычный PCI-E коммутатор? К слову - они сами себе противоречат! Общем ждём тестов!!!

Ну не знаю. Комманда приличных программеров справится должна. Есть проекты типа 3DAnalyse или DXTweaker, которые являются по сути своей как раз 3D API-перехватичками. DXTweaker так вообще проект одного человека, он умел подменять многие капсы, включать wireframe, указывать цветом используемые форматы текстур и версии PS.

Не знаком с этими программами, не специалист я в 3D технологиях, но подозреваю, что в данном случае речь идёт о трансляции: API -> API и трассировке. В случае гидры, полагаю, работа не может ограничиться данным уровнем.