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

Я такого нигде и не утверждал. Разве максвелл был полным редизайном кеплера? Покрутили там и сям, поправили узкие места с учетом задач. Тут тоже самое по сути, GP100 заточен считать, GP102/104/106 на графику.

Я считаю, Хуанг занесет за меня игроделам...

Какой откат к кеплеру? Обратное наращивание =/= откат. Функционально то блоки изменились.
Например, смотрим тут первую табличку http://www.anandtech.com/show/10325/the-nvidia-geforce-gtx-1080-and-1070-founders-edition-review/9
Потом вспоминаем, что кеплеры не умеют dx feature level выше 11_0

В последний раз FP16 был нативно у nvidia аж в GF FX. Все последние поколения просто дописывали нули и считали его как FP32. Кстати, в полярисе тоже заявлено добавление нативного FP16, заключается в экономии кешей и регистров (FP16 хранятся как FP16, а не FP32). В паскале есть это + 2xSIMD.
Если это так просто делается в драйвере (впечатление, что здесь все кроме меня разработали минимум по 3 графические архитектуры), то почему раньше не сделали, и почему этого нет в полярисе.

Ну это уже гадание начинается. Как минимум унаследован нативный FP16, который появился в 5.3 (GF с 5.3 не было)
http://docs.nvidia.com/cuda/cuda-c-prog ... pabilities
Но раз 6.1, значит есть еще что-то (в 6.0 заявлены операции, связанные с унифицированной памятью, но это больше к GP100)

А зачем? В мобильных устройствах это еще имеет смысл ради экономии всего.
А в настолках - ваще бесполезно для игр.

Ну так настольные GPU-ядра то сейчас в tegra идут с минимумом изменений.

Э, ты думаешь что с юзеров после этого станут меньше брать

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

я имел ввиду наращивание регисрового файла и тд

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


это все же нативное в отличии от полуаппаратного решения которое есть в паскале которые только определенные (сколько раз писать очень ограниченное количество инструкций) складывает и считает как одну фп32 все остальные считаются как и считались в этом плане изменений нет.

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

Это ты откуда вообще взял? Там обычный SIMD. Инструкция любая, единственное условие - одна и та же инструкция на оба набора операнд.

4e_alex симд не описывает само слияние те "много данных одна инструкция" вот только много чего в симд не попадает - например не все вектора в цпу могут складываться это касается всего списка от avx128 до 512 и выше... это как пример.
... откуда я это взял? конкретно была статья с разбором тех. документации на паскаль честно ссылок не осталось (точно помню не на русском).

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