LINUX.ORG.RU
ФорумTalks

NVIDIA открывает спецификации на свои GPU

 datasheets, ,


1

4

Вы не поверите! Но 23 сентября в рассылку nouveau пришло такое письмо:

Hi Nouveau developers,

NVIDIA is releasing public documentation on certain aspects of our GPUs, with the intent to address areas that impact the out-of-the-box usability of NVIDIA GPUs with Nouveau. We intend to provide more documentation over time, and guidance in additional areas as we are able.

As a first step towards that, we've posted a document here:

ftp://download.nvidia.com/open-gpu-doc/DCB/1/DCB-4.0-Specification.html

Оригинал

★★★★★
Ответ на: комментарий от leg0las

Да ладно?
Куча ноутов с оптимусом. Вполне продаются

Серьёзно. Интегрированная графика за последние несколько лет стала лучше на порядки и получила распространение даже на десктопах.
Даже согласно Steam HW Survey за последние чуть больше года доля графики Intel выросла с <10% до >14%.
Это всего лишь чуть больше чем за год и только лишь среди геймеров. Среди не геймеров доля интеграшек возросла гораздо сильнее.

Если договорятся с кранами, то еще не все потеряно.

Я очень сомневаюсь, что стимбокс по количеству продаж сможет сравниться с консолями от мс и сони. Перспективы проекта вентилей вообще очень туманны.

Тегра (мобильники)

Тегра в жопе и почти нигде не используется.

Тесла

Тут соглашусь, но рынок очень маленький. Хоть и денежный.

Не думаю что аж совсем караул

Ну пока что не совсем караул явно, но если они ничего не придумают в ближайшее время, то плавно скатятся на дно. Причём скорее всего достаточно быстро, как это в своё время сделали те же S3 или Matrox.

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

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

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

Какой нафиг «зашибенчик», это едва ли 5% от нужных данных - по ссылке голимые форматы данных для определения оборудования. Про всяческие енкодеры-декодеры-конвейеры там вообще ни слова.

no-dashi ★★★★★
()
Ответ на: комментарий от ncrmnt

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

Самые топовые карты типа титана нафиг практически никому не сдались из-за неадекватной цены. Титан - это скорее понт, нежели реальный продукт.
А в адекватном ценовом диапазоне у карт нвидии есть вполне достойные конкуренты от амд.
Согласно данным всё того же hw survey стима за нвидией 52%, за амд - 33%. Разрыв ощутимый, но не прямо таки катастрофический.
Лично мне нвидия нравится больше из-за более прямых дров, но это уж кому что.

Да и тегры, несмотря на кривизну софта сейчас одни из самых мощных в плане графики SoC'ов

Неа, выше уже об этом писали.

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

Ты просто, видимо, не играешь в современные игры.

Играю и довольно неплохо.
И в курсе, что разница между средними@50-60FPS и максимальными@15-20FPS полтора пикселя.

devl547 ★★★★★
()
Ответ на: комментарий от ranka-lee

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

а через что?

dikiy ★★☆☆☆
()
Ответ на: комментарий от devl547

И в курсе, что разница между средними@50-60FPS и максимальными@15-20FPS полтора пикселя.

Сходи к окулисту. Серьёзно.

Ramen ★★★★
()

amd-капец наступил

Reset ★★★★★
()
Ответ на: комментарий от ranka-lee

handle op = dma_copy_command_buffer(buffer, size); wait(op); wait_vsync(); execute_command_buffer(op); От gapi нужны только эти команды.

Resetу уже ответил. То есть писать свой движок для каждой видяхи? Вместо унифицированного интерфейса OpenGL? Спасибо - не надо.

dikiy ★★☆☆☆
()
Ответ на: комментарий от Reset

Да, как в 90х делали.

в 90-х писали софтверный движок. который работал _на всех_ процессорах. так же был 3dfx, на котором _уже_ работал MiniGL (подмножество OpenGL).

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

А что в этом плохого? Сейчас уже почти так делают, только в качестве backend'ов выступают специализированные API от sony, микрософта, nintendo ...

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

minigl использовались в паре игр, в остальных использовались родные API

какие родные API? API куда?

А что в этом плохого? Сейчас уже почти так делают, только в качестве backend'ов выступают специализированные API от sony, микрософта, nintendo ...

как будто это хорошо. Получается будешь покупать видюху под игры. Это маразм и шаг назад в развитии.

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

какие родные API? API куда?

В 90х у каждого вендора был свой фирменный API (glide, s3 metal, powervr wtf ...), потом кое-как переползли на directx.

Получается будешь покупать видюху под игры.

Я сейчас и так видюху под игры покупаю, а зачем еще нужна мощная видюха?

Reset ★★★★★
()
Последнее исправление: Reset (всего исправлений: 1)
Ответ на: комментарий от Reset

А тут будет как в конце 90-х что Riva не умеет Glide, поэтому riva - говно для камагеддона второго и т.д.

Dark_SavanT ★★★★★
()
Последнее исправление: Dark_SavanT (всего исправлений: 1)

Новость конечно хорошая.....

Но меня и проприетарные дрова устраивают.

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

В 90х у каждого вендора был свой фирменный API (glide, s3 metal, powervr wtf ...), потом кое-как переползли на directx.

интересно. Ну вот видишь, как хорошо, что унифицировали.

Получается будешь покупать видюху под игры.

Я сейчас и так видюху под игры покупаю, а зачем еще нужна мощная видюха?

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

dikiy ★★☆☆☆
()
Ответ на: комментарий от devl547

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

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

Ага. Видеокарт на свете всего 3 штуки. Разница между ними - коды командного буфера и микрокод шейдеров. На C тоже пишут на разное железо одинаковый код.

Вместо унифицированного интерфейса OpenGL?

Этот интерфейс - жирный костыль который давно не отражает устройства железа. Писать на нём это как считать ядерную бомбу в браузере с помощью JavaScript. Можно, но по сути гигантский набор костылей. Например вызовы тьмы разных фукций gl* могут быть заменены одним-двумя memcpy.

ranka-lee
()
Ответ на: комментарий от Reset

Через год новый глава микрософт откроет винду и наступит линуксокапец :)

ты сам то в это веришь?

ggrn ★★★★★
()
Ответ на: комментарий от ranka-lee

Этот интерфейс - жирный костыль который давно не отражает устройства железа

Ты хоть четверку в глаза видел?

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

Вот вам пример того как выглядит прямое программирование видеокарты без OGL на примере librsx, для хаченой PS3: https://github.com/ps3dev/PSL1GHT/blob/master/ppu/librsx/commands.c Весь код всех функций состоит из «записать число по указатели и увеличить его».

ranka-lee
()
Ответ на: комментарий от ranka-lee

Но что в этом хорошего то? Люди специально старались, уровень абстракции для облегчения понимания и запоминания человеком и уменьшения количества кода пилили, а ты теперь предлагаешь всё выкинуть и вернуться к ассемблеру.

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

Эти абстракции создают тормоза. Разница может быть буквально в сотни раз. Никто же не запрещает оставить поверх них OpenGL для неосиляторов.

ranka-lee
()
Ответ на: комментарий от ranka-lee

Когда они тормоза создают? В момент компиляции?

kranky ★★★★★
()

Наконец-то нвидиа-фаны могут вылезти из ямы с говном, если конечно там не огрызок кинули.

paran0id ★★★★★
()
Ответ на: комментарий от ranka-lee

Эти абстракции создают тормоза. Разница может быть буквально в сотни раз. Никто же не запрещает оставить поверх них C/C++ для неосиляторов.

Пофиксил

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

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

ranka-lee
()
Ответ на: комментарий от buddhist

Аналогия с ассемблером некорректна. Тут ближе к программированию на JavaScript в браузере. Оно вообще связи с тем что реально считается и как оно работает не имеет.

ranka-lee
()
Ответ на: комментарий от ranka-lee

Тут ближе к программированию на JavaScript в браузере

Вот это совсем не пришей рукав. Если аналогия с ассемблером не совсем корректна, вот вам другая аналогия: зачем нужны ФС? Там же сплошной костыль на костыле, какие-то тормоза, журналирование и потери. Давайте писать на диски напрямую!

buddhist ★★★★★
()
Ответ на: комментарий от ranka-lee

Тут ближе к программированию на JavaScript в браузере.

Да каким боком то оно ближе? Жабаскрипт интерпретируемый, интерпретаторы корявые, вот он и тормозит. Какое отношение к этому имеет абстрактный API, если он при компилировании превращается в такой же код, какой получился бы при твоих двух memcpy?

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

АМД фанбой в треде. ложил я на спеки нвидии и ати, сижу на блобе и не жужжу.

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