закомить им патчей же, ну! но в целом этот код ещё не достиг стадии когда его надо отрефакторить.

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

А что за видимокарта? На Polaris OpenGL 4.5 есть и в открытых дровах. На SI тоже должен быть.

DirectX "must die"

Об этом и разработчики Star Citizen писали публично уже, поэтому они сейчас выкидывают поддержку DirectX 12 окончательно и бесповоротно, а имеющийся код быстро и ненапряжно переводят на Vulkan.

Об этом и разработчик YSFlight также заявил

ysflight.in.coocan.jp/ysflight/ysflight/e.html#20161124

In YSFLIGHT for OpenGL 2.0, I have implemented the shadow-map method. I believe it can also be done with Direct X9, but, I don't want to spend even a second to learn an API that runs on only one operating system, and even declared deprecated by the vendor. Shadow-map feature will be available only in YSFLIGHT on OpenGL 2.0/ES 2.0 for now. If Vulkun API catches up the speed, I will add support for Vulkun. Then the shadow- map feature will be available in YSFLIGHT on Vulkun then. But, I don't know how popular Vulkun can become. It may just fade away. Right now, there is no replqcement of OpenGL 1.1. I need to go very high- level, which is pretty much useless for me, or very low-level, which needs work to make it useful for me. Not everyone needs photo-realistic movie- like graphics. For me, I need 3D graphics to prove my concept in my research. OpenGL 1.1 was just good for my purpose. To use OpenGL 2.0 with ease, I wrote a cover library. Maybe I'll need to do the same for Vulkan eventually.

But, what I desperately want to avoid is to spend considerable time to lean how to use Vulkun only to see Vulkun just fading away. I wasted too much time to learn Direct3D9. Microsoft ditched it in Direct X10. If I knew my knowledge in DirectX9 becomes useless in such a short time, I definitely wouldn't have wasted time learning Direct3D9. I learned from it. I will never spend time learning Direct X12.

Они удалили код что ли?

anonymous> Не люблю оскорблять людей, но ты феерически туп

Да ладно. А аппаратно что там с FP16?

Thero> скорее всего разработчики стар ситизен писали о том что если таки сесть и разобраться то вулкан не настолько сложнее насколько профитней и перспективней..

Они прямо написали, что отказываются от DirectX 12 и что Star Citizen теперь будет на Vulkan, и что им нет причин делать рендерер под DirectX 12, если только не даст этот API большого прироста производительности.

Thero> но для большинства среднестатистических игроделов дх12 на несколько порядков проще..

Практика показала, что не проще.

q0tw4> Починили бы лучше дрова под мою видюху. А то сижу на открытых, а там не то что вулкана, опенжля 4.5 нету.

Чинить дрова нвидии - это вне компетенции AMD.

Аппаратно халфы есть во всех видеокартах со времен царя Гороха. В центральных процессорах есть только специальные инструкции для конвертации туда и обратно. В Паскалях они в двое быстрее обычных флоатов, потому что используются в нейросетях. У AMD в Веге (или уже даже в Полярисе, я не уверен на самом деле) тоже появятся специальные инструкции, которые позволяют в одном регистре работать с двумя халфами по образу и подобию инструкций SSE и MMX. Архитектуры вплоть до Максвелла у NVIDIA и Фиджи (вероятно еще и Поляриса, но, опять же, не уверен) у AMD не получают профита в плане скорости вычислений, но позволяют экономить пропускную способность памяти.

И что же за агрегат у вас? Если ниже GCN 1.X, то можешь и не ждать.

но зачем тут отдельные процедуры?

Альтернативы процедурам - дёргать объект ради одного его маленького свойства, или вызывать интерпретатор. Монструозно.

Вот просто интересно: f16 -> f32 - откуда брать недостающее? f32 -> f16 - куда складывать не влезшее?

Есть два варианта. Первый - если тип данных неизвестен, то красиво всё почикать/округлить. А второй - если тип данных в переменных известен и его нужно конвертировать, то использовать процедуры, которое это сделают.

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

я знаю что они написали в анонсе, не знаю что они писали в подробностях на форуме но знаю что там речь не о простоте\сложности самого языка, а о том что переход с дх11 на любой из апи будь то ДХ12 или вулкан достаточно трудоёмок что-бы выбрать тот который имеет больший охват платформ вместо того что-бы в последствии делать ещё одно портирование.. ( и они молодцы)

в реальности есть несколько основных случаев когда ты можешь построить рабочий процесс с нуля и когда ты обновляешь существующий.. в обоих случаях ограничение накладывает совместимость рабочих инструментов с теми или иными технологиями и инструментами и инструменты для организации разработки под дх12 пока опережают те что есть для вулкана, хоть ситуация и сильно улучшилась за последнее время.. ожидаю что к концу 2017 вулкан станет однозначно перевешивать и останется бороться только с теми кого инерция вынесет с дх11 в дх12

А второй - если тип данных в переменных известен и его нужно конвертировать, то использовать процедуры, которое это сделают.

Вот у меня есть 0xFEBA. (ради простоты я приведу пример с i16 и i8). Это дело можно округлить, потеряв в точности - 0xFE. Что предлагают делать тут? Куда они будут складывать оствшиеся 0xBA? Как они потом планируют что-то с ними делать? Как к примеру будет выглядеть сложение?

Ты хранишь там нормализованные векторы. Значение было 0.75643, а стало 0.76. Информация потеряна, но никто не заметит, если в компьютерной игре один пиксель будет темнее, чем надо.

Ну дак AX7750 2GBK3-HE. Да уж старовата, но в винде же все норм, и вулкан работает.

Если ниже GCN 1.X, то можешь и не ждать.

1.1 по идее

Зачем гадать? Если будешь на библиотеке программировать, то увидишь предлагаемые варианты. Всё равно, одно и тоже зашумлённое видео и раньше по разному смотрелось на штеудах и радеонах. Практика украшательства картинки продолжится. Одним покупателям нужны фпс, а другим - чтобы рипы и ютубы хорошо смотрелись.

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

Чейта? Ну вот у меня горбуха на ПрямоХере, и решил я Пукан впендюрить, чтобы модно было. Нешто я буду инструкции наживую заменять? Не, выделю интерфейс и сделаю два рендера, а то есть шанс не завершить работу ваще

Не, выделю интерфейс и сделаю два рендера, а то есть шанс не завершить работу ваще

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

Ну, во первых, Пукан ради Пукана - тоже вариант, а во вторых - всё дело в уровне абстракции. Если достаточно высок - может жрать поменьше, ибо имплементация на Пукане будет чувствовать себя свободнее

anonymous> Аппаратно халфы есть во всех видеокартах со времен царя Гороха.

Что же тогда пишут, что их только недавно добавили аппаратно? Только в тех же паскалях появились у нвидии, и то, похоже, только для CUDA.

anonymous> В Паскалях они в двое быстрее обычных флоатов, потому что используются в нейросетях.

Конечно быстрее. Потому, что они там через FP32 сделаны костылями.

anonymous> не получают профита в плане скорости вычислений, но позволяют экономить пропускную способность памяти

В этом вся суть. Всё равно что разрядность шины нарастить. За счёт этого общая производительность и поднимается.

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

Впиливать Vulkan не значит убирать имеющийся рендерер. Уже лет 20 наверно движки умеют отдельные рендереры подключать.

Thero> я знаю что они написали в анонсе, не знаю что они писали в подробностях на форуме но знаю что там речь не о простоте\сложности самого языка, а о том что переход с дх11 на любой из апи будь то ДХ12 или вулкан достаточно трудоёмок что-бы выбрать тот который имеет больший охват платформ вместо того что-бы в последствии делать ещё одно портирование.. ( и они молодцы)

Они сначала заявляли, что будут делать игру под DirectX 12, и только потом рассматривать возможность реализации рендеринга на Vulkan. Трудоёмкость их не пугает в принципе - у них процесс разработки целиком и полностью на прототипировании и переписывании основан. Они уже даже CryEngine успели выкинуть и перейти на форк от Amazon. Говоря о трудоёмкости, отмечу, что переход на любой незнакомый API трудоёмок в принципе. Потому достаточно нанять человека, который Vulkan хорошо знает (такие уже должны быть). Кстати, интересно ещё и то, что разработчики Star Citizen заявили о переходе на Vulkan и отказе от DirectX 12 то ли незадолго до, то ли сразу после того, как появилась новость о поддержке MGPU в Vulkan.

Примерно столько же. Ибо возможности DirectX 12 и Vulkan идентичны. Даже API очень сходные за счёт того, что AMD дала мелкософту те же наработки, что и Khronos Group для Vulkan. И результат оказался забавным, но предсказуемым: при прочих равных условиях кроссплатформенное и открытое решение побеждает.

а во вторых - всё дело в уровне абстракции. Если достаточно высок - может жрать поменьше, ибо имплементация на Пукане будет чувствовать себя свободнее

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

Впиливать Vulkan не значит убирать имеющийся рендерер. Уже лет 20 наверно движки умеют отдельные рендереры подключать.

Ага, заходишь в игру Х и никакого опенгл тебе на выбор не предлагают. Более того, меня прикалывает веселуха, когда видеорежим можно выбрать только внутри самой игры загрузив её полностью, ну или искать конфиг и что-то там наугад править. Как включишь веселуху,, которая устраивает системную ошибку ядра, типа «кернел повара», так грузись и соревнуйся при тыканьи настроек с тормозами загрузки карты и спамом. А ведь добавлять вход в меню настроек в начало загрузки игры тоже давно научились.

Примерно столько же. Ибо возможности DirectX 12 и Vulkan идентичны.

Ты хочешь сказать что на моей видухе работает двенадцатый директ? Даже работу в икспишке в 32 битных играх придётся поддерживать, даже если там тормозит. Если ты начнёшь впиливать в игру новьё и собирать её по модному, то тестируй потом во всех режимах.

Сначала такие «кококо производительности мало к железу ниблизко дайте кококо ручками байты пердолить в списках команд». Потом, послевыхода вулкана «ой кокококудах ачетак сложна та кудах хеллоуворлдв тысячу строк та? Не го верните нам фабрики абстракций и километры прослоек»

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

Все соснули, всё как обычно и бывает.

Амудепроблемушки.

Намекаешь на то, что с энвидией ПО не глючит и из игр не выкидывает? А ещё есть такой прикол, что на конкретной системе игра Y просто не запускается или валится при входе, пользователь её качает, натыкается на грабли, посылает, качает Х и там вроде как-то работает. А если Х станут переделывать для поддержки вулкана, вдруг и там случатся теже глюки;) Это же лотерея. С такими темпами внедрения, когда Вулкан станет очень актуален, может появиться уже Вулкан 2.