LINUX.ORG.RU

Корпорация AMD анонсировала GPUOpen — инструменты, графические эффекты, библиотеки и SDK с открытым исходным кодом

 , , , ,


3

3

Разработчикам будут предоставлены инструментарий и ресурсы для того чтобы выжать из видеокарт по максимуму, как в играх, так и в приложениях направленных на вычисления.
И, в отличии от широко используемого GameWorks корпорации NVIDIA, GPUOpen не будет «непригодным для использования черным ящиком».
Исходные коды даже будут выложены на GitHub!

Напомню, что месяц назад также был обещан альтернативный компилятор совместимый с CUDA — Boltzmann.

>>> Подробности

AMD

Но играть под Linux оно так и не может.

Зато исходнички! :D

anonymous ()

Они теперь пытаются стать котиками и няшками?

Promusik ★★★★ ()

Анонсировала — не выпустила.

AP ★★★★★ ()

Ну ждём, чо.

«непригодным для использования черным ящиком»

Это как понимать? Отсебятина какая-то.

Sunderland93 ★★★★★ ()

Хотя бы пролистали источник до второй страницы и таки написали бы, что релиз будет в январе.

anonymous ()
Ответ на: комментарий от anonymous

Ну будем считать, что новость про анонсирование.

shahid ★★★★★ ()

Офтопик-лист, какой там пункт?

mittorn ★★★★★ ()

Это как-то улучшит ситуацию с драйверами?

sudopacman ★★★★★ ()
Ответ на: комментарий от AP

Анонсировала — не выпустила.

Джва чая... стоп, сегодня же пятница, тогда... джва виски этому господину.

r3lgar ★★★★★ ()
Ответ на: комментарий от AP

не упарываюсь

У тебя сегодня не пятница? Ну ладно, тогда два чая или кофе.

r3lgar ★★★★★ ()

Надеюсь, они открыли всё это в связи с тем, что собираются бросить все ресурсы на поддержку https://www.khronos.org/vulkan ?

Anonymous ★★★★★ ()

обещан альтернативный компилятор совместимый с CUDA — Boltzmann

Любопытно, интересно.

I-Love-Microsoft ★★★★★ ()

На открытых то дровах заведётся или блоба потребует?

WARNING ★★★★ ()

GPUOpen не будет «непригодным для использования черным ящиком».

Wut?

weare ★★ ()
Ответ на: комментарий от alozovskoy

Они теперь пытаются стать котиками и няшками?

«Software development kitы», наверно.

Казалось бы, причем тут хохлосрач :)

slackwarrior ★★★★★ ()

Наконец-то альтернатива мерзкой проприетарщине Nvidia CUDA.

anonymous ()
Ответ на: комментарий от anonymous

OpenCL

Наконец-то альтернатива мерзкой проприетарщине Nvidia CUDA.

А разве OpenCL не был всю жизнь альтернативой мерзкой проприетарщине NVIDIA CUDA?

Camel ★★★★★ ()

Короче АМД отрелизила опенсорсный CodeXL. Расходимся, посоны, дров не открыли.

anonymous ()

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

anonymous ()
Ответ на: комментарий от anonymous

Нет, CodeXL - инструменты разработки. А GPUOpen и GPUWorks - SDK высокого уровня, упрощающие жизнь (мех рисовать, жидкости симулировать итд), почти готовый движок. Про ченый ящик я поясню, я с этим сталкивался. Идем например сюда OptiX_SDK_3.0.0\SDK-precompiled-samples\ptx\ и видим кучу ptx ассемблера, скомиленый под разные поколения GPU. Так эти закрытые SDK и работают, берут версию CUDA, выбирают нужный скомпиленый бинарник. Однако работает это не всегда, из-за этого большинство примеров старых Optix на моем GTX 980 не работают. Так же не заработать на боле новых GPU может любой другой SDK от nvidia и нужен fallback для отключения данной технологии. Потому в том же ведьмаке 3 HairWorks отключаемый, а не просто регулируемый.

anonymous ()

И, в отличии от широко используемого GameWorks корпорации NVIDIA, GPUOpen не будет «непригодным для использования черным ящиком».

Большая часть исходников GameWorks открыта, конкретно PhysX и Flex. И это только начало

mastermind ()
Ответ на: комментарий от anonymous

Расходимся, посоны, дров не открыли.

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

Orlusha ★★★★ ()
Ответ на: комментарий от anonymous

ИМХО они решили форсировать процесс, дав комьюнити как можно больше инструментов для его проведения.

Orlusha ★★★★ ()
Ответ на: комментарий от anonymous

Вообще принципиально ситуация поменяется, когда будет одно из следующего: 1. mesa поддержит OpenGL bindless texture\buffer https://www.opengl.org/registry/specs/ARB/bindless_texture.txt 2. Все поддержат OpenCL 2.1 или Vulkan. Это позволит сделать шейдер\ядро, которое имеет доступ ко всем ресурсам GPU (без так называемых binding points и ограничений\оверхеда, превращая GPU в фактически полноценный удаленный самостоятельный комп). Сейчас это тоже возможно, но есть проблемы. Nvidia застряла на OpenCL 1.2, но якобы поддержала Vulkan, но он еще не вышел. Можно использовать bindless texture\buffer или DX12, но сделать что-то одно чтобы работало везде нельзя. Кстати первой такая возможность появилась в OpenGL и до DX12 на DX это было недоступно (и вообще в DX12 многое уже стырено у GL а не наоборот). И вот когда эти интерфейсы наконец выйдут везде - открытый SDK на них очень пригодился бы.

anonymous ()
Ответ на: комментарий от mastermind

Я бы не сказал что большая. PhysX уже давно никому не нужен, есть bullet physics, который ничуть не хуже, эта тема давно не проблема. А вот того что всем надо пока нету, мне бы вот хотябы аналог SpeedTree найти отпенсорсный.

anonymous ()
Ответ на: комментарий от anonymous

PhysX уже давно никому не нужен, есть bullet physics

Давно я не слышал столь толстых троллей

mastermind ()
Ответ на: комментарий от mastermind

Ты хоть исходники смотрел, не тролль? Я вот смотрел, просто physx ускоряется на CUDA, bt ускоряется на OpenCL, оба ускорения реализованы нормально. Принципиальных различий нет, только в API указания модели, констрейнов и прочего. Вообще если без ускорения, простейший солвер делается «на коленке» в несколько килобайт, вот пример lion.rusfur.net/GT1_Solver_by_MFT.zip иногда даже этого вполне достаточно, если обхектов не миллион.

anonymous ()
Ответ на: комментарий от anonymous

Я на исходники смотрел еще до того, как они стали публичными. Что значит «оба ускорения реализованы нормально»? Ты смотрел примеры PhysX и BulletPhysics? Бенчмарки?

mastermind ()
Ответ на: комментарий от Orlusha

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

ckotinko ☆☆☆ ()

принято решение переписать все дрова изначально в опенсорсном проекте
Расходимся, посоны, дров не открыли

В 2045 году встречаемся. Ждать осталось недолго.

slony ()
Ответ на: комментарий от sudopacman

А там что-то нуждается в кардинальном улучшении? amdgpu уже есть для gcn1-2, для старых карт radeonsi работает практически идеально. Управление питанием завезли, декодирование для uvc1-uvc2 тоже. Блоб для игродаунов, где меза уже не тащит.

aegi ★★ ()
Ответ на: комментарий от mastermind

Так а что сам не кинул ссылок на бенчмарк? Разумеется смотрел, вот например http://www.codercorner.com/blog/?p=914 И использовал сам, например тут http://www.youtube.com/watch?v=oNSIRTQAzA4 . По опыту: большой разницы нет, даже если объектов много, если у тебя физика ест более 10% от всего - ты что-то делаеш не так. А от этих 10% разница в 10% влияет на восприятие не значительно, нужно существенное ускорение, а скорость у всех на уровне, разница только на CPU считать или на GPU.

anonymous ()

AMD прям как Балмер скачет: «Developers, developers!»

void_ptr ★★★★ ()
Ответ на: комментарий от anonymous

По твоей ссылке:
However I think these posts may reach their limited goal, which is simply to show with very basic tests that:
PhysX is getting faster all the time
PhysX is very well optimized, thank you very much
Конечно, для простых случаев, вроде твоего разницы особой нет. В реальных играх все иначе.
Ну и на засыпку, если ты считаешь, что PhysX не нужен, попробуй сделать вот это в BulletPhysics - https://www.youtube.com/watch?v=fjguI90nSok https://www.youtube.com/watch?v=6vipmar3wS4. Это open source.

mastermind ()
Ответ на: комментарий от mastermind

Кстати, раз ты в теме и доступ к исходникам до публикации есть. У тебя нет PS4 SDK или хотя-бы ${SDK_PATH}\target\samples\sample_code\system\tutorial_cpu_gpu_optimization\GPU_photon_mapping\ или другого нормального примера Photon Map на GPU? Нормальный это значит есть акселерационная структура, сцена динамическая, а не как в большинстве на гитхабе.

anonymous ()
Ответ на: комментарий от aegi

Блоб для игродаунов

Какие только оправдания амд-дауны не придумают :3

anonymous ()
Ответ на: комментарий от anonymous

В кривых ручонках анонима вообще ничего не будет работать, вполне естественно. :)

trueshell ★★★★★ ()
Ответ на: комментарий от mastermind

Нет, «PhysX is getting faster all the time» это значит PhysX от версии к версии становится быстрее, т.к. это его бенчмарк и речь про него, это действительно так (особенно CPU у старых страдал). Самые распространенные тесты rigid body смотри, там гдето bullet впереди, где-то physx. И я же говорю - когда объектов много, просто такого примера на ютубе у меня не залито.

anonymous ()
Ответ на: комментарий от anonymous

С PS4 я не работаю. Тебе обязательно photon mapping? Что сделать хочешь? Global Illumination?

mastermind ()
Ответ на: комментарий от mastermind

Я тоже с PS4 не работаю, но единственный известный мне рабочий пример там http://graphics.cs.williams.edu/papers/PhotonI3D13/ . Ну да, конесно GI, что же еще, только не SSAO\HBAO и даже не VXGI, а смесь рейтрейса (пока рилтайм невозможно слишком шумит http://www.youtube.com/watch?v=YD26DXuFI4o ) и PhotonMap (требуется его помощ). Это уже вполне возможно https://www.youtube.com/watch?v=gAcTyQC072M

anonymous ()
Ответ на: комментарий от anonymous

А чем VXGI не устраивает? Есть рабочие примеры под GPU (Maxwell), но они непубличные (пока). Есть много инфы по Photon Mapping, что мешает самому закодить?

mastermind ()
Ответ на: комментарий от mastermind

У VXGI тоже есть свои ограничения, они хорошо видны. У PM Тоже есть свои ограничения, можно придумать полно сцен, где количества фотонов не хватит и техники придется комбинировать, но в целом реалистичность лучше VXGI, это надо видеть. Мешать то ничего не мешает, только вот получается хуже чем на видео выше, например bilateral upsampling такой же качественный не получается.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.