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

А насчет предвзятого отношения к геймерам- так без них мы все бы сейчас сидели на Matrox Millennium PCI.

я проглядел статейку эту, там достаточно немно написано понятного.
Как я понял можно использовать только видяхи семейства 8*** и то не все. И кроме использования специальных дров нада еще и самому делать проги..
А как на счет использования видях семейства 7*** и прог которые уже сделаны под винду (ворд например тот же, фотошоп, проги конвертирования видео и аудио файлов), неужто нет такого, чтобы часть вычислений автоматически передавались на видяшку и проц немного разгружался??

_Leon_ а зачем? зачем вводить данную функцию для поколения "старого", если продавать надо нынешнее? это не выгодно.
надеюсь я прально понял мысль)

_Leon_
Выше почитай. Для этого ускорителя нужно писать программы на специальном языке, произвольный софт на нем устественно не запустится, епт.

А как на счет эмуляторов? Мысль выполнима?

_Leon_ НЕТ. RTFM!

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

[quote="Cootri"][/quote]
Если ЭТО будет приносить прибыль - сделают. Проблем в программистах нет.
Аутсорсинг если что. Другое дело надо ли это?
Спрос рождает предложение.

Вычисления на G80 можно проводить только с 32-битной точностью.
Так что область применения у этой штуки будет весьма ограниченнная.

И так мало памяти, что там вообще можно делать полезного?

Cootri Я говорил не об эффективности компиляторов, а об удобстве написания. Впрочем, не настолько владею предметом чтобы углубяться.

maxuser нам бы с тобой такое в мах9, а то достало уже по 27 часов рендерить.

Злой_Прапор ТОЧНО, как прикрутят к майе и максу с лайтваром, так будет счастье! Слава программерам!!!

I.N.

Эт точно, вначале Sony кормила сказками про Cell, потом AMD с фьюжином, затем Agea, теперь NV c теслой со своей ну и где они сейчас все ? У многих стоят такие девайсы, взять туже PhysX который в ультре лежит за 300$. Имхо эти "сказки" для корпаративного рынка и узкого приминения, дома им нечего делать.

ну и нафиг такое чудо покупать? Пара младших тесл обойдётся как 4 ультры или пять ПЕЧей. А вот уж пять ПЕЧей раскумаренных или хотя бы 4 ультры подразогнанных если они будут использоваться не для обработки графики уж стопудово пошустрее этого Теслы будут.
Интересно , а "суперкомпьютеры на видеочипах" G84 и G86 они делать будут? (типа даёшь крэй в каждый дом!)

Вот! А говорили, у нвидиа нет планов, по производству процессоров...

Tesla12 писал(а):

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

может кто-то впомнит, что Маркони у него радио спер?

Ну это не совсем правда. Это речь идет о точности сингл операций с плавающей точкой на каждой процессорной единице. А соответствующий алгоритм может естественно, дать любую требуемую точность. Все математические функции CUDA имеют точность дабл, имеются такие же сингл и урезанный набор быстрых функций с пониженной точностью, есть реверсивный кастинг сингл-дабл, флоат - инт. К тому же текущая версии CUDA, рассчитана только на DX9, 32 битную ОС, входные данные могут приниматься мапировкой одновременно только с одного буфера вершин, других входных данных не предусмотрено. Так что, к выходу Теслы, еще апгрейд будет, есть что улучшать.
А какие проблемы с памятью? Эта технология приделывает к ЦПУ мультиядерный сопроцессор с эффективной локальной, разделяемой и текстурной памятью. Обсчитал - слил, или поставил в очередь, чего не хватает?

И на счет С++. Автор ошибся, приложения для ГПУ пишутся либо на АСМе, либо на С- подобных языках. С++ здесь просто громоздок и избыточен. Cuda построен на чистом С.

Компиляторы может и продвинутые, но C изначально по своей сути оптимизируется плохо - слишком низкоуровневый и слишком большой простор действий с указателями. Если не писать код специально с рассчетом на последующую оптимизацию, что очень нетривиально, не изощряться с restricted pointer'ами и пр., типичный код, написанный на C, в принципе невозможно так же оптимизировать, как написанный на фортране - там у компилятора очень большой простор по оптимизации, он практически неограниченно может размещать переменные в регистрах и памяти, убирать их, заменять на другие для оптимизации вычислений и т.д. В C такое не выходит, потому что там очень часто используется доступ через указатели, а компилятор при этом практически ничего не может проверить и узнать, куда на самом деле произойдет доступ и как изменятся переменные после этого. Ни о какой их ликвидации или замене, кроме самых примитивных случаев, речь не идет. И проявляется это все именно на математике, где у компилятора большой простор по отгадыванию промежуточных значений, сохранений/загрузке их и перегруппировкам вычислительных процессов. На фортране простой и логичный код, который легко переделывается, а в C указатели, из-за которых программа может делать тысячи вещей, которые компилятору не предсказать, и руки у него связаны.

Кстати, вышла версия CUDA 0.9. Версия 1.0 будет уже поддерживать аппаратно 8600GT и 8500GT, дело какого-то месяца. Если добавят поддержку Висты и не будет требоваться специализированная версия драйвера, как сейчас для XP, вообще будет замечательно.