John Carmack, Oculus Chief Technology Officer, сказал: "Мы использовали железо и драйверы Нвидии на Виндоуз и Андроид для разработки под Вулкан, и снижение ограничения ЦПУ было впечатляющим".
Moderator
Статус: Не в сети Регистрация: 27.06.2008 Откуда: Таганрог
Jeton Тут основная проблема не в самом API а, желании софтописателей с ним полноценно работать, сколько уже так было и с тем же OpenGL и с мантией, вроде как и работает, но патчи выходят с огромным опозданием и большой кривизной. Т.е. делают "на отстать", вот есть, запускается и ладно, а что и как пофиг.
Member
Статус: Не в сети Регистрация: 01.06.2011 Откуда: Кривий Рiг UA Фото: 1
VulKan же (это как же верно как то, что если владелец 970 в BDO видит что для 60 fps требуется полторы печ960, он верит что это грофоннн как в Ведьмак 3, а там на самом деле DoFа на полторы 960 и хуже чем в Two Worlds 2)
_________________ По поводу АМД можно сказать, что... http://images.vfl.ru/ii/1466552059/06f0b3de/13108371.gif
Последний раз редактировалось Renegade1979 17.02.2016 21:35, всего редактировалось 1 раз.
Member
Статус: Не в сети Регистрация: 16.06.2013 Фото: 11
MaD!CaT писал(а):
Ага, которое под виндой дх11 уступает...
но, судя по тестам, "обёртка" в Талосе уже обгоняет OGL. так что время покажется. собственно, сами разработчики Талоса ещё вчера обещали прирост производительности даже по сравнению с дх11
MaD!CaT писал(а):
желании софтописателей с ним полноценно работать
вот именно. как бы OGL не развивался, но с ним всё равно были какие-то проблемы: нет чёткой поддержки каких-то людей(сейчас хоть Вэлв с Кроносом кое-как всех объединили). а сейчас появился кое-какой шанс подняться разработчикам программ и железа
Добавлено спустя 20 минут 18 секунд: Вот разработчик Талоса интересно отвечает:
В: По вашим ощущениям, с Вулканом быстрее кодить и т.п., чем с ОГЛ ? О: С Вулканом кодить гораздо дольше, чем с ОГЛ. Однако точно ничего нельзя сказать (дальше он что-то про ОГЛ ЕС базарит..). Самое сложное - это привыкнуть к программированию нового API. Также есть два момента: во-первых, ОГЛ на данный момент может быть быстрее Вулкана(так как тот ещё не обкатан), а также быстрее ДХ11 в некоторых тяжёлых ситуациях с ЦП - он сам это видел с карточками Нвидиа. Во-вторых, он считает, что ОГЛ для "простых" игр подойдёт больше, а Вулкан больше для "тяжёлых" игр и это действительно здорово!
_________________ Ryzen 7 5800X + 32 ГБ ОЗУ + RX 6700 XT + Full HD
Member
Статус: Не в сети Регистрация: 16.06.2013 Фото: 11
Jeton писал(а):
WoT
эти кретины до сих пор с dx9 не могут слезть, о каких новейших API может идти речь ? хотя, может они и решат понтануться и запилить Vulkan (как дх12 для недоигр Сингулярити и, возможно, АРК)
_________________ Ryzen 7 5800X + 32 ГБ ОЗУ + RX 6700 XT + Full HD
Member
Статус: Не в сети Регистрация: 01.06.2011 Откуда: Кривий Рiг UA Фото: 1
mphuZ писал(а):
эти кретины до сих пор с dx9 не могут слезть, о каких новейших API может идти речь ?
видимо, потому что сами осознают ненужность дх11, графика всё равно отключаются нафиг ради 300 fps, но там нет 300 fps и даже графики и то нет, и не тащит ни один проц. Но он возможно тащит из-за самого движка, и тут просто не поможет никакой API отрисовки, ибо дело не в отрисовке, а во всём сразу, начиная с сетевого кода и кончая физикой моделей, поэтому и сидят на дх9
_________________ По поводу АМД можно сказать, что... http://images.vfl.ru/ii/1466552059/06f0b3de/13108371.gif
Member
Статус: Не в сети Регистрация: 10.05.2011 Откуда: Москва
mphuZ писал(а):
С Вулканом кодить гораздо дольше, чем с ОГЛ.
А что они хотели от low-level api? А уж какой гемор будет разные видяхи поддерживать - ух) Срач "какая игра под какие карты оптимизирована" резко поднимет градус безумия.
mphuZ писал(а):
он сам это видел с карточками Нвидиа.
nvGL - это такая интересная штука, которая не совсем opengl
mphuZ писал(а):
Во-вторых, он считает, что ОГЛ для "простых" игр подойдёт больше, а Вулкан больше для "тяжёлых" игр и это действительно здорово!
Учитывая что OpenGL 4.х закопали по сути, ИМХО, можно ждать выпуска какого-нибудь OpenGL-ng, делающего абстракции поверх Vulkan.
Member
Статус: Не в сети Регистрация: 07.04.2010 Фото: 19
mphuZ писал(а):
Ведь всё равно будут холивары дх12/вулкан
А что, есть о чем холиварить здесь, два засраных апи, выбирать между которыми должны производители софта, это для них написано, что им было легче игоры делать. А почему холиварить должны мы?
Member
Статус: Не в сети Регистрация: 16.06.2013 Фото: 11
b00german писал(а):
А почему холиварить должны мы?
для начала нужно дождаться, когда их активно начнут внедрять. а холивар начнётся тогда, когда чётко будет видно, какой API больше предпочитают
devl547 писал(а):
А что они хотели от low-level api?
он не оправдывался, а просто сообщал))
devl547 писал(а):
nvGL
не знаю, что это такое и он это не упоминал
Добавлено спустя 1 минуту 13 секунд: heidfeld дам вам текст про это "будущее"
Откровения разработчика
engine design for Vulkan is basically consited of three major parts:\
1) Port. Make it work as fast as possible just by wrapping current engine design around Vulkan. Avoid all pitfalls and bottlenecks. This is what we did by now and released as patch for Talos.
2) Use Vulkan for multi-threaded rendering. Our engine is designed really well for multi-threaded rendering, but we have only our wrapper for it - calls to graphics API (like Vulkan) are not multi-threaded. Yet. That being said, this is the next step what we'll do. And probably release that also as patch for Talos. I tried to do that with Direct3D 11 long time ago (support for its deffered contexts), but it was too much pain and too little or even no gain. That's just one of reasons why we decided to stick with our own approach for MT renderer for that long. :/
3) Redesign engine for Vulkan. This is the biggest step and can be split in two:
3a) Precache all rendering states (which mostly mean materials in game) up front. This will make rendering calls much simplier and faster. So, instead of deciding at rendering time what is needed for a material to be rendered via Vulkan, do this at loading time and then when material needs to be rendered just give it to Vulkan, via one or two simple function calls.
3b) Precache all geometry, material, textures, everything that is needed for rendering an object up front. This basically creates so called command buffer ready for Vulkan, and nothing extra needs to be set or created at render time.
3rd part of port is, obviously, the most complex one, and it'll take time to change engine design for it, step-by-step.
Hope I explained this well.
_________________ Ryzen 7 5800X + 32 ГБ ОЗУ + RX 6700 XT + Full HD
Member
Статус: Не в сети Регистрация: 01.06.2011 Откуда: Кривий Рiг UA Фото: 1
mphuZ писал(а):
3a) Precache all rendering states (which mostly mean materials in game) up front. This will make rendering calls much simplier and faster.
о боже, эта штука будет кешировать весь Готам на средних текстурах на старте игры, у меня она свапить начнёт не через две минуты, а после полминуты фризаков на подгрузке. Но для аренных шутанов пойдёть и правда, нафига стриминг, а что у нас Новиград целиком просто не влезет в их комманд буффер, они и не догадывались, что ли?
_________________ По поводу АМД можно сказать, что... http://images.vfl.ru/ii/1466552059/06f0b3de/13108371.gif
Member
Статус: Не в сети Регистрация: 12.09.2010 Откуда: Калининград
Renegade1979 писал(а):
:fingal: о боже, эта штука будет кешировать весь Готам на средних текстурах на старте игры, у меня она свапить начнёт не через две минуты, а после полминуты фризаков на подгрузке. Но для аренных шутанов пойдёть и правда, нафига стриминг, а что у нас Новиград целиком просто не влезет в их комманд буффер, они и не догадывались, что ли?
Это совсем другое значит, это, по сути, подготовка шейдеров. Они не много места в памяти занимают, но компиляция этих объектов может быть долгая То, что они их выбирают во время вызова отрисовки, только показывает, насколько поспешно этот порт сделали Они этот шаг относят к "редизайну движка" и это как-то слишком громко звучит, не вижу, почему это должно было бы быть проблематично
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения