Мне кажется разделение на CPU/GPU изначальным фейлом. На мой взгляд куда проще сделать кучу одинаковых универсальных ядер, на которых смогут работать как пользовательские приложения так и рендеринг графики.
Олсо если архитектура будет закрытой то это станет еще большим фейлом.

>>24265

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

А как быть с алгоритмами, которые плохо распараллеливаются, либо вообще не распараллеливаются (такие есть!) ? Они требуют сносной производительности ядра. Если делать все ядра такими производительными, то это дорого обойдется, да и остальные ядра во время работы таких программ будут простаивать.

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

>Олсо если архитектура будет закрытой то это станет еще большим фейлом.

Что даст открытость архитектуры, если фактически по всей планете смогут производить соответсвующие камни только 2-3 корпорации?

>>24267

> А как быть с алгоритмами, которые плохо распараллеливаются, либо вообще не распараллеливаются

Сложно себе представить современный десктоп, на котором будет выполняться только одна программа. Даже если каждая программа будет иметь только один поток, то просто каждая из них будет выполняться на отдельном ядре, что уже даст прирост производительности за счет отсутствия необходимости часто переключать контекст. Кроме того не так уж и мало ресурсов расходуется на ожидание ввода-вывода, чем опять же можно занять ядро.

> Что даст открытость архитектуры, если фактически по всей планете смогут производить соответсвующие камни только 2-3 корпорации?

Возможность писать компиляторы и софт кому угодно.

>>24268

>в системе работает много процессов

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

>Возможность писать компиляторы и софт кому угодно.

Думаешь, Intel хочет (и может!) быть единоличным разработчиком софта под свои (широкого потребления, кстати, сказать) процессоры?

>>24270

> Да, но как правило пользователя заботит больше всего конкретная программа, которой он в данный момент пользуется

Это так. Но программа в "чистом виде" работать не может. Она активно взаимодействует с оконным менеджером (если конечно графическая), с дисковой подсистемой и прочими вспомогательными процессами, если эти задачи переложить на другие ядра, то высвободится куча ресурсов на основном.
Кстати браузер на сегодняшний день довольно ресурсоемкое приложение и распаралеливание встроено во многие браузеры.

> Думаешь, Intel хочет (и может!) быть единоличным разработчиком софта под свои (широкого потребления, кстати, сказать) процессоры?

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

>>24272

>NVIDIA показала себя не так уж и хорошо, выпустив закрытый компилятор для своих GPU и не подумав об остальных.

Из документации к CUDA:

Goals of PTX
PTX provides a stable programming model and instruction set for general purpose parallel programming. It is designed to be efficient on NVIDIA GPUs supporting the computation features defined by the Tesla architecture. High level language compilers for languages such as CUDA and C/C++ generate PTX instructions, which are optimized for and translated to native target-architecture instructions.
The goals for PTX include the following:
- Provide a stable ISA that spans multiple GPU generations.
- Achieve performance in compiled applications comparable to native GPU performance.
- Provide a machine-independent ISA for C/C++ and other compilers to target.
- Provide a code distribution ISA for application and middleware developers.
- Provide a common source-level ISA for optimizing code generators and translators, which map PTX to specific target machines.
- Facilitate hand-coding of libraries, performance kernels, and architecture tests.
- Provide a scalable programming model that spans GPU sizes from a single unit to many parallel units.

Да, native target-architecture instructions на выходе открытого компилятора не получится, а вот создать транслятор, который транслирует какой-нибудь язык программирования в PTX вполне можно. Но на самом деле это не такая и проблема. Думаю, nvidia закрыла это дело не [только] из жадности, а скорее из-за недостатка стандартизации в ее камнях (как думаю и в камнях Ati) - так как на разные серии видеокарт идут разные драйвера, по всей видимости бинарный код для GPU может быть в разных сериях различным (хотя может разные драйвера имеются только из-за новых возможностей и расширений).

>>24289
Если один камень отличается от другого то это не такая уж и проблема - сделать компилятор под каждую из них, поскольку не думаю что отличия настолько серьезные. А использование транслятора - расточительство ресурсов, имхо.
Кроме того нет ясности, где и как выполняется разделение ресурсов между различными приложениями, сипользующими GPU, и что будет происходить, если с GPU захотят работать 2 или больше приложения, причем с разными приоритетами в системе.

>>24291

>использование транслятора - расточительство ресурсов, имхо.

Any application that wants to run on future device architectures must load PTX, not
binary code. This is because binary code is architecture-specific and therefore
incompatible with future architectures, whereas PTX code is compiled to binary
code at load time by the driver.

Я и нвидиеские инженеры так не считаем. Ты забываешь, что бинарный код еще будет отправлятся по шине к GPU, что займет определенное количество времени, поэтому задержка от трансляции PTX драйвером на хосте не заметна.

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

Если тебе это действительн интересно, почитай доки. При работе с CUDA создается контекст выполнения (каждый системный процесс может иметь несколько контекстов, но только 1 активный). Несколько системных процессов со своими контекстами могут работать параллельно. Тут нужно вспомнить, что GPU - обычный ресурс с точки зрения ОС, поэтому его время будет раздаваться точно так же, как и время, скажем, жесткого диска.
Единственное, могут быть проблемы (отказ в выдаче контекста или даже аварийное завершение работы), если не хватает памяти, но тут, честно говоря, я слабо представляю, что могла бы сделать видеокарта (не свапиться же).

>>24292

> задержка от трансляции PTX драйвером на хосте не заметна

По времени - нет, по ресурсам - да. GPU тем и интересен, что может высвободить CPU для других задач, повышая тем самым суммарную производительность системы.

> поэтому его время будет раздаваться точно так же, как и время, скажем, жесткого диска

Для жесткого диска существует несколько дисциплин управления, в том числе и с приоритетами. Между всем этим счастьем можно переключаться, как выбирая алгоритм распределения времени, так и выбрать приоритет для каждого процесса, если конечно базовый алгоритм это поддерживает. Как это делать с GPU - непонятно.

>>24305

>По времени - нет, по ресурсам - да. GPU тем и интересен, что может высвободить CPU для других задач, повышая тем самым суммарную производительность системы.

Вычисления на GPU специфичны. Максимальный выигрыш достигается тогда, когда мы скидываем всю нужную информацию (в том числе объектный код) по шине в видеопамять и запускаем какой-нибудь ресурсоемкий алгоритм, который работает с видеопамятью и мало информации гоняет по шине (если вообще что-то гоняет кроме результата). Как видишь, получается, что изначально затрачивается какое-то линейнозависимое время на загрузку, а потом уже все зависит от алгоритма и видеокарты и общее время: t = t(загрузки)+t(работы). Когда мы имеем транслятор на входе, время загрузки возрастает (кстати сказать совсем немного), но это единовременные затраты, и на время работы алгоритма не влияет. В итоге общее время увеличиться совсем чуть-чуть. Это как подтолкнуть машину с плохим стартером, чтобы завести и поехать в другой город или идти пешком - что более ресурсоемкая вещь?

>непонятно

Запусти несколько приложений, которые используют 3д-ускорение твоей видеокарты через OpenGL или DirectX и посмотри, как распределяется время видекарты между ними. Как видишь, системным программистам вполне понятно, как распределять время видеокарты между задачами.

>>24311

> Вычисления на GPU специфичны. Максимальный выигрыш достигается тогда, когда мы скидываем всю нужную информацию (в том числе объектный код) по шине в видеопамять и запускаем какой-нибудь ресурсоемкий алгоритм, который работает с видеопамятью и мало информации гоняет по шине (если вообще что-то гоняет кроме результата).

Справедливо для сферического алгоритма в вакууме, на практике же таких алгоритмов для пользовательских задач не встречается, большинство задач требует работы с какими-либо другими ресурсами. Кроме того обычной практикой является многократный запуск одного и того-же алгоритма по несколько раз с другими аргументами, каждый раз транслировать его при этом - не самая лучшая идея, намного лучше оттранслировать все один раз при установке/компиляции приложения, что освободит CPU от дальнейшего многократного выполнения этой задачи.

> Запусти несколько приложений, которые используют 3д-ускорение твоей видеокарты через OpenGL или DirectX и посмотри, как распределяется время видекарты между ними.

С 3d ускорением работают не приложения а графическая подсистема, в алгоритме работы которой и прописывается, как именно это все должно работать, что кстати тоже иногда можно настроить тем или иным способом. В данном же случае совершенно непонятно, что и как работает с видеокартой, как например будет вести себя закрытый драйвер в случае одновременного 3d рендеренга и проведения каких-то неграфических вычислений на ней.
Я бы например на месте разработчиков всего этого при работе в десктопном режиме загружал в видеокарту основные алгоритмы декомпресии изображений и гонял бы по шине сжатые картинки. Еще довольно полезной фичей есть декомпрессия видео на GPU, что почему-то реализовано только для H264. Еще много чего полезного можно было бы сделать, если бы был доступ к архитектуре видеокарты.

>>24313

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

Говоришь так, как-будто без таких вызовов нельзя обойтись, переделав интерфейс программы.

>Справедливо для сферического алгоритма в вакууме

Справедливо для тех алгоритмов, которые в данный момент используют GPGPU. Будь то обработка видео, где фрагменты (возможно, отдельные кадры? в видео-форматах не силен) постепенно считываются и порциями обрабатываются на GPU.

Кстати сказать, возможность загружать код без трансляции ЕСТЬ в CUDA. Как у меня освободится время, я обязательно проведу ряд тестов и составлю несколько профайлов - я уверен, траты на трансляцию незначительны (вижу, с тобой спорить бесполезно).

>С 3d ускорением работают не приложения а графическая подсистема, в алгоритме работы которой и прописывается, как именно это все должно работать, что кстати тоже иногда можно настроить тем или иным способом.

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

Олсо, гонял CUDA-приложения с включенными эффектами рабочего стола (эффекты юзают 3d-ускорение). Никаких проблем не обнаружил. Завтра погоняю несколько CUDA-приложений одновременно, чтобы убедиться, что никаких проблем с этим нет. Также попробую поиграть с приоритетами (nice). Хотя, если их воздействие никак не скажется на работе программ, это ничего означать не будет. Такая же ситуация часто и с обычными приложениями наблюдаю.

>Еще много чего полезного можно было бы сделать, если бы был доступ к архитектуре видеокарты.

Ко всему этому у тебя ЕСТЬ доступ (я правда не знаю, как там с закрытыми видео-форматами, но это видимо не вина nvidia).

>>24320

> Говоришь так, как-будто без таких вызовов нельзя обойтись, переделав интерфейс программы.

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

> проведу ряд тестов

Буду рад ознакомиться с результатами.

> Что ты имеешь в виду под графической подсистемой?

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

> Олсо, гонял CUDA-приложения с включенными эффектами рабочего стола (эффекты юзают 3d-ускорение). Никаких проблем не обнаружил.

Как распределяются ресурсы между всеми этими задачами? Влияет ли на распределение ресурсов приоритет приложения и насколько существенно?

> Такая же ситуация часто и с обычными приложениями наблюдаю.

Я не наблюдал. Если приложение использует именно CPU и производительностью упирается именно в него, то приоритеты отрабатывают очень четко, и это как правило заметно даже невооруженным глазом. С приоритетами i/o серьезных опытов не проводил, но они тоже есть, и задаются отдельно.

> Ко всему этому у тебя ЕСТЬ доступ

Можно увидеть ссылку на архитектуру видеокарт и систему команд их процессорам?

>>24321

>Можно увидеть ссылку на архитектуру видеокарт и систему команд их процессорам?

вышеоговоренные вещи можно реализовать без этого.
Кстати, на сколько я знаю,

>Еще довольно полезной фичей есть декомпрессия видео на GPU, что почему-то реализовано только для H264.

это реализовано методом паяльника и ничего нельзя тут сделать. Но опять-таки говорю, МОЖНО написать собственный плеер, который будет пересылать по шине видео и декодировать на GPU, а после сразу отображать.

Я так и не понял, чего тебе не хватает. Не мог бы ты сформулировать, какие приложения ты не можешь написать из-за того, что оп-коды видеокарт недоступны?

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

Тут ты прав, действительно, в том виде, в котором оно сейчас есть, видеокарта не может забрать на себя все вычислительные затраты. Но разве в этом предназначение технологии CUDA? Думаю, что нет. Она работает с каким-то определенным приложением, например, расчет физики в игре и справляется со своей задачей. То, что эта технология не справляется с чужими задачами, не является ее недостатком, разве не так?

Все результаты экспериментов будут в субботу-воскресенье.

>>24322

> это реализовано методом паяльника и ничего нельзя тут сделать

не думаю, алгоритм очень сложный, скорее всего драйвера подгружают в видеокарту декодер по необходимости

> Не мог бы ты сформулировать, какие приложения ты не можешь написать из-за того, что оп-коды видеокарт недоступны?

Из-за этого невозожно реализовать грамотною подсистему управления ее ресурсами, как сделано с CPU или HDD. Сейчас это не представляет проблемы, но когда появиться много приложений, использующих GPU - проблема появится. Большое количество ядер так и просит, чтобы на них работала куча программ.
Кстати есть куча задач ввода/вывода, когда ядро CPU больше простаивает чем работает. Если это ядро будет ядром видеокарты то производительность увеличится.

>>24323

>Кстати есть куча задач ввода/вывода, когда ядро CPU больше простаивает чем работает.

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

>Из-за этого невозожно реализовать грамотною подсистему управления ее ресурсами, как сделано с CPU или HDD. Сейчас это не представляет проблемы, но когда появиться много приложений, использующих GPU - проблема появится. Большое количество ядер так и просит, чтобы на них работала куча программ.

С этим согласен (пока), но нужно будет еще почитать, как же дела с мультизадачностью на самом деле там обстоят.

>>24324

> Гм, а специально для таких задач разве не заводят отдельные потоки, которые блочаться, когда нужно?

Я говорю о несколько более низком уровне, когда CPU отправляет команду устройству и ждет от него ответа.

>>24325
прерывания, не?

>>24326

> прерывания

Когда их слишком много CPU задыхается от переключений контекста.

традиционный бамп с последней страницы

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

>>26797
а я уж было подумал что ты совсем забыл