Ждём Ваших отзывов о материале.
Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!

2 TyyOx91
"А сейчас не дают?" Не дают. Нет стандартного АПИ, наподобии ССЕ или ММХ. Результаты вычислений НЕ выводятся, а остаются только для графического отображения в памяти видяхи.
Сразу хочу заметить:
1. Я не рассматриваю карты рендеринга, которые стоят туеву гору денег, и в широком кругу пользователей не используются. (Здесь этот АПИ есть, но специализированный под рендеринг.)
2. Я не учитываю наработки в этой области физускорителей от АМД и НВИДЕА. Опять же нет, общего стандарта и это не для широкого круга пользователей. (Здесь есть то чно надо, но нет стандарта и дорого. Аналог овердрайву.)
"И чем он будет отличаться от старого (в текущих GPU)?" Тем, что его нет. Нет никакой возможности сохранить результат вычислений в ОЗУ. Точнее есть, только так, как описанно в 1-2.

Ничего они медленнее не идут.

За этим бредом как ни странно будущие, а если вы думаете, что сегодня выпустили 64bit проц, а завтра все дружно перешли на 64bit ОС вот это бред. Все будет "медленно и торжественно".

Да, особенно если учесть всю мощь его интегрированного видео )))

Раз AMD интегрирует, значит и поддержку обеспечит, а это очень важно.

medcom

Ну а чем сейчас занимаются NVidia и AMD(ATI) для своих карт последнего поколения. В чём отличие API CUDA или AMD Stream Processor от API для интегрированного GPU?

SSE и MMX - это не API. Это инструкции процессора. Генерируются компайлером. Программировать же внешний контроллер - дело муторное даже при условии вылизанного API.

Ну это мелочи. Здесь нет ничего принципиально невозможного и к API это не относится.

А зря. Именно это и будет использоваться в будущем "интегрированном" GPU.

Dogmatik

Ну это замечание не в тему. Вы не знаете каким будет будущий GPU от Интел. Разве что хрустальный шар где-нибудь прикупили...
Добавлено спустя 2 минуты, 1 секунду

А сейчас нет поддержки? Ась? Драйверы для GPU не выпускаются?

Как раз таки времена поменялись.
1. Адресное пространствно теперь 64 битное, а не 8ми, 16ти и 20ти битное. Благо, можно почти все процы мира в одно 64 битное пространство объеденить.
2. Кросбар на что? Чтобы решать все вопросы с синхронизацией. НЕсколько однородных ядер хорошо ужились в современных системах. В CELL легко объеденили разнородные ядра (7 или 8 ядер одного типа и одно другого).
3. Современные физ. ускорители уживатся без проблем.
4. Уверен, что сегодня можно дешево и сердито разрешить проблему одновременного декодирования команд разными ядрами. Главное, чтоб этот интерфейс был напрямую доступен программерам, независимо от поддержки опирационками.

И вы не знаете. Пока по факту Intel интегрировать туда нечего и даже намеков нет.

Драйверы? А какая там поддержка?

medcom

Не вижу связи.

С кроссбаром будет всё ещё сложнее.

Вот именно что однородных. (Вплоть до одинаковой частоты, не говоря уже о системе комманд.)

Это как раз то, о чём я говорю. SPU приходится программировать как внешние контроллеры через спец. API. Разработчики под PS3 матерят этот Cell вовсю. Кстати, API до сих пор не вылизали.

Без проблем, говорите? Что-то я не заметил большого возбуждения у разработчиков по поводу той же AGEA.

А я уверен, что каждый блок в проце должен заниматься своим делом - пусть GPU рендерит графику, ну а для вычислений должен быть отдельный векторный блок. А то получается ни-то ни-сё (не-до-GPU и не-до-вычислялка).
Добавлено спустя 7 минут, 38 секунд
Dogmatik

Вы забыли что Интел держит более половины рынка интегрированной графики (которая, кстати, не уступает интегрированной графике от НВидиа - тесты есть на фцентре).

Поддержка расчёта графики (основная задача GPU). А вы о чём подумали?

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

Что для Вас тогда АПИ? Если я пишу
__asm{
movaps xmm0,xmmword ptr [ecx]
movaps xmm1,xmmword ptr [edx]
mulps xmm0,xmm1
movhlps xmm1,xmm0
addps xmm0,xmm1
movaps xmm1,xmm0
shufps xmm0,xmm0,00000001b
.........................
...........................
}
значит я не пользуюсь АПИ. Лично я считаю инструкции проца, частным случаем АПИ. т.е. Как бы там не было, этот набор инструкций доступен пограммерам через определенный АПИ . А то что компайлеры бывают такими умными и могут генерить из обчного сишного кода такой АПИ, это не значит, что я сам не могу им пользоваться.

Это не мелочи. Это пару милионов транзисторов, которые физически соединяют внутренюю шину с внешней, для вывода данных. Это дополнительный набор инструкций, позволяющий это делать, и для этого набора дополнительные транзисторы тоже нужны, чтобы управлять теми транзисторами. В совокупности эти и те транзисторы снижают производительность, добавляя латентность в передаче данных по внутренним шинам, а также увеличивают себестоимость. Так что к АПИ это тоже относится.
Здесь я хотел сказать, что я не учитываю то, что не доступно массово. Массово будет доступно после интеграции этих нароботок в новые ядра. В этом и есть основное отличие между тем, что сегодня доступно, и тем, что будет доступно после интеграции.
Добавлено спустя 7 минут, 20 секунд

х87 не могли в те времена "грамотно" организовать из-за дифицита адресного пространства.

medcom

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

Ну если вы так пишете, то вы лет на 5 отстали от жизни .

Это далеко не одно и то же. И дело даже не в том, что программисты предпочтут написать C = A + B, чем что-то типа C = send_to_GPU_for_addition(A,B). Проблема в том, что при программировании внешних контроллеров наду учитывать кучу дополнительных факторов - например тот же SPU(Cell) не имеет кэшей (и соответственно доступа в общую память). Поэтому чтобы сложить А и В, сначала нужно освободить место в локальной памяти SPU, потом организовать DMA transfer из общей памяти в локальную, сложить и вернуть в общую память - опять с помощью DMA.
К тому же такая "беседа" между CPU и GPU сопряжена с потерей времени (да и процессор, вместо того, что бы считать, занимается пересылкой данных туда-сюда) -как следствие худшая производительность относительно такого же блока интегрированного непосредственно в ядро.

Размер не имеет значения ))) Intel сильно отстала и сможет ли их ядро что-то ускорить еще вопрос. (Думаю если сравнять качество графики от Intel и от NVIDIA, то производительность Intel'овского решения сильно пострадает).

Ну я так подумал фильм перекодировать (как наиболее актуальный случай).

2 TyyOx91.

Только почему-то именно Интел тоже ухватилась за эту идею. Пока неизвестно, будет это всего лишь интеграция или все-таки предоставит какой-то АПИ для доступа к вычислительным блокам. Напомню, что ещё недавно Интел расказывал о 128 однородных ядрах в одном проце. А ещё несколькими годами ранее, таже интел расказывала о 20ГГц в 2006-2007 году.


1. Никто не будет складывать 2 числа даже в ССЕ, не говоря уже об сложении 2х чисел в ГПУ. Это проще выполнить с помощью стандартных инструкций. А вот сложением 2х матриц объемом по 1 мбайт можно занять ничего не далающий ГПУ. Накладные расходы при этом на проц не большие.
2. Самим ДМА трансфером проц не занимается. Поэтому и назвается "Директ Мемори Эксес", что трансфером занимается само устройство. А пока происходит трансфер, можно процу другим делом заняться.
3. Никакой разницы нет, между беседой однородных процов с разделным КЕШем и разнородных, если интерфейс обмена данными одинаковый и растояние между ядрами и кросбаром такое же. Судя по слайду так оно и будет. Поэтому бояться потери не стоит, тем более, АМД обещает общий кеш 3го уровня. Так что, надеюсь, даже трансфера организовывать не нужно будет. Все будет лежать рядом. И будет происходить по принципу, "сложика ты вон тот мегабайт с этим, а я пока пару окон передвину, а то юзер жалуется на отзывчивость системы".
4. Может пример с CELLом был неудачный. Так как ГПУ будет иметь свой шикарный буфер, если не подводит меня моя память, в 16 мбайт.

Dogmatik

Подождём и посмотрим. Ещё недавно не верили, что интел может выпустить процессор который будет быстрее АМД .

Не знаю. На качество вроде бы не жаловались.
http://www.xbitlabs.com/articles/chipse ... 50_12.html


Вы конечно можете на это надеятся. NVidia вот уже лет пять кормит сказками о высокопроизводительных вычислениях на GPU. Но я вам не советовал бы забывать, что основное назначение GPU, это графика - а всё остальное это "как получится". Типа F@H - да считает. Но не понятно быстрее или медленнее чем CPU. При этом куча багов да и CPU грузит процентов на 80.

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

Me4tatelI>, я только "ЗА" такое решение. Я лишь привел аргумент того, что Интел тоже считает это решение разумным, не только "безумная" АМД.

Сейчас я поясню, что имел ввиду
64-битный лейбл - звучит возбуждающе, но в практическом плане это всего лишь хитрый маркетинговый трюк, скрывающий не только достоинства, но и недостатки. Нам дарованы 64-битные операнды и 64-битная адресация. Казалось бы, лишние разряды карман не тянут и если не пригодятся, то, по крайней мере, не помешают. Так ведь нет! С ростом разрядности увеличивается и длина машинных команд, а значит, время их загрузки/декодирования и размеры программы, поэтому для достижения не худшей производительности 64-битный процессор должен иметь более быструю память и более емкий кэш. Это раз.

64-битные целочисленные операнды становятся юзабельны только при обработке чисел порядка 2^33+ (8.589.934.592) и выше. Там, где 32-битному процессору требуется несколько тактов, 64-битный справляется за один. Но где ты видел такие числа в домашних и офисных приложениях? Не зря же инженеры из Intel пошли на сокращение разрядности АЛУ (арифметичного-логичесокго устройства), ширина которого в Pentium-4 составляет всего 16 бит, против 32 бит в Pentium-III. Это не значит, что Pentium-4 не может обрабатывать 32-разрядные числа. Может. Только он тратит на них больше времени, чем Pentium-III. Но, поскольку, процент подлинно 32-разрядных чисел (то есть таких, что используют свыше 16 бит) в домашних приложениях относительно невысок, производительность падает незначительно. Зато ядро содержит меньше транзисторов, выделяет меньше тепла и лучше работает на повышенной тактовой частоте - в целом эффект положительный.

64-битная разрядность… Помилуй! Адресовать 18.446.744.073.709.551.616 байт памяти не нужно даже Microsoft'у со всеми его графическими заворотами! Из 4 Гбайт адресного пространства Windows Processional и Windows Server только 2 Гбайта выделяют приложениям.

3 Гбайта выделяет лишь Windows Advanced Server, и не потому, что больше выделить невозможно! x86-процессоры с легкостью адресуют вплоть до 16 Гбайт (по 4 Гбайта на код, данные, стек и кучу), опять-таки обходясь минимальной перестройкой операционной системы! Почему же до сих пор это не было сделано? Почему мы сидим на жалких 4 Гбайтах из которых реально доступны только два?! Да потому, что больше никому не нужно! Систему, адресующую 16 Гбайт, просто так не продашь, кого эти гигабайты интересуют? Вот 64-бита - совсем другое дело! Это освежает! Вот все вокруг них и танцуют.

Сравнивать 32- и 64-битные процессоры бессмысленно! Если 64-битный процессор на домашнем приложении оказывается быстрее, то отнюдь не за счет своей 64-битности, а благодаря совершенно независимым от нее конструктивным ухищрениям, на которых инженеры едва не разорвали себе задницы!

Если бы наши "за" аовлия ли бы на их разработки, вот было бы..



Думается, что если бы это было бы так кретично, то все давно бы перешли, но это не так уж сейчас нужно (не везде).

А если поставить вопрос наоборот: нафига нужны графические ядра без собственных обслуживающих их процессоров?

Ведь при отсутствии процессора, обслуживающего графическое ядро, у центрального процессора, выполняющего код видеодрайвера, отьедается от 10 до 40-50% вычислительной мощности.

medcom

Можно долго спорить о том кто был первый. Но не зная о том, что там варится на"кухнях" АМД и Интел - это бесполезно. Хочу только отметить, что учитывая намеченный выход Нехалема на середину 2008-го и 4-х летний цикл разработки, можно предположить что разработка Нехалема началась более двух лет назад. Тогда как о покупке АТИ фирмой АМД заговорили меньше года назад. Странно правда?

Ну это понятно. А+В я привёл для наглядности.

К сожалению, складывать и умножать - это всё, что умеет GPU. Весь алгоритмический код процессору всё равно придётся брать на себе. Так что во множестве алгоритмов использование GPU будет неэффективным из-за возможной "игры в пинг-понг" - постоянного перебрасывания данных из бафера GPU в кэш CPU и обратно. (SPE в Cell xотябы может исполнять код.)

Проц занимается программированием DMA.

Это не верно. Кэши общаются между собой по интерфейсу MESI (для обеспечения когерентности) - баферы его естественно не имеют. Так же баферы не имеют механизмов WriteBack и автоматического замещения данных (типа LRU) - это значит что все загрузки и выгрузки в/из бафера выполняются "вручную". Если интересно, почитайте о том, как люди извращаются, пытаясь реализовать software cache для SPE.

2 Manaus.

Сегодня именно дифицит физического адресного пространства, а не программного, которого сегодня достаточно для домашнего пользования. В первую очередь 64 битное адресное пространство нужно для масштабируемости на уровне девайсов, а не на уровне майкрософт. Не болит голова при организации межпроцессорных шин и прочих девайсов. Любое устройство прозрачно линкуется к 64 битному адресному пространству. Организация многопроцессорных систем также упрощается, хотя это не так важно для настольных систем. Но для удешевления себестоимости серверов и настольных систем очень важно сегодня объеденить обе сферы на аппаратнов уровне (интерфейсы, система команд и ПО). Тогда делая одно ядро (1 еденицу затрат на разработку этого ядра), можно его применять во всех сферах. А удешевление себестоимости приводит к бОльшей доступности во всех сферах.


1. На СИМД инструкциях это не сказывается вообще.
2. Немного сказывается на производительности х86 инструкций, но есть одно но. Проц общается с памятью пакетами определенного размера. Выложив один раз на адресную шину адрес у которого последние биты нули, а получает данные с этого адреса по 64 битной шине по адрес, в котором все эти биты равны 1. А данные они и так измеряются в байтах, и пофиг через какую разрядность. Так что для х86 вычислений, влияние ширины адресной шины на производительность за счет пакетного обмена нивелируется.
3. Немного теряем на хендлах. Но в 64 битном режиме это компенсируется отстутствием потребности гонять данные туда-сюда, так как имеем в этом режиме 16 регистров общего назначения.
4. Да, длина команд увеличивается, так как абсолютные адреса в этих командах стали больше в 2 раза. Но это скажется только на 64 битном софте. На 32 битном это не сказывается, причем пофиг под какой операционкой 64 битной или 32 битной. Так что там из-за этого потерь не так много. Но в 64 битном приложении есть доплнительтельные регистры, которые нивелируют эту потерю, а может даже и на порядок перекрывают. Скажем так, что не так велик процент команд с абсолютной адресацией в программном коде, чтоб это так негативно сказалось на производительности в 64 битном режиме.
Что получаем в итоге. Согласно 2 и 3 мы теряем в 32 битном софте под 64 битную ось около 2-3%. Не так уж много, чтоб в замен получить сегодня доступ к 64 битному софту, который на 20-80% при быстрее 32 битного аналога.
Добавлено спустя 48 минут, 21 секунду
2 TyyOx91.

А больше ничего и не нужно. Имея пропускную способность в десятки ГБ/с можно этого не сильно бояться, при условии, что считать ГПУ будет очень быстро. Круг задач, где это даст пользу думаю будет. Различное кодирование, декодирование, САПР, рендеринг, физические расчеты в играх и др. Благо пин-понг будет проходить в КЕШе 3го уровня, а не через оперативку.


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


Надеюсь люди из Интел и АМД проявят благоразумие и наделят эти буфера протоколами когерентности MESI и MOESI соответственно, если будет требовать война между гигантами. Как бы там не было, на скорости десятки ГБ/с это будет очень быстро.

Дайте ссылку, с удовольствием почитаю.


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

Тестировал конечно же Гаврик я прав?

Технология эта - начало давно ожидаемого перехода от современных сборных систем к моноблочным машинам будущего, которые будут компоноваться из 4-5 основных компонентов, не более... Начало перевода компьютера в разряд бытовых устройств, для которых не так важна мощность начинки, как её соответствие стандарту, под который делается ПО. Это именно то, что сейчас мы имеем с игровыми приставками. В будущем все компьютеры будут "чёрным ящиком", кроме узкого сегмента "профессиональных, сверхмощных" машин, который будет по прежнему комплектоваться из россыпи по принципу "самое мощное на данный момент". Большинству это просто не нужно...
Сейчас от этой судьбы спасает трёхмерная графика, которой много мощности не бывает. Однако лет через 10 HDTV, причём стерео, если нужно, станет доступно на любой самой простой машине... С качеством выше нынешних 32 бит. Офисные приложения давно уже не требуют той мощи, которая имеется в процессоре. 90% времени, по крайней мере. В общем, интеграция видео и контроллера памяти в процессор - это просто предвидение неизбежного будущего. Сектор таких машин будет только расширяться со временем.
Добавлено спустя 5 минут, 24 секунды

А не кажется ли тебе, что именно потому Cell и может исполнять код, что он специально приспособлен для этого, а не просто "склеен" из разных деталек? Если графику будут вливать в проц, а не просто клеить под одну крышку, как кое-кто собирается, то это будет кардинальное изменение всей архитектуры, и уж как правило, никакого прогона из кэша в кэш не будет. Потому что не будет такой разницы между CPU и GPU как сейчас. Даже если одно ядро будет "преимущественно GPU", то никто не позволит ему зря стоять, пока работы для GPU не хватает и напрасно гонять данные, если вдруг понадобилось применить инструкцию ХХХ, которая чисто для графики ни к чему.