Войти
ПрограммированиеФорумГрафика

Diligent Engine - современная кросс-платформенная низкоуровневая графическая библиотека (10 стр)

Страницы: 19 10 11 1217 Следующая »
#135
19:11, 13 окт. 2019

assiduous
Увидел спасибо.
Надо будет попробовать сколько он моделей потянет. )))


#136
4:06, 14 окт. 2019

Эх, зачем всё так сложно сделано...

Вот чтобы просто сохранить один указатель на ID3D11Device, такое количество классов:
IObject->IRenderDevice->IRenderDeviceD3D11 = RenderDeviceBase<>->RenderDeviceD3DBase<IRenderDeviceD3D11>->RenderDeviceD3D11Impl

#137
4:22, 14 окт. 2019

Потому что есть ещё D3D12, Vulkan, OpenGL, в которыз часть функциональности берется из базовых классов, что позволяет избежать копи-пасты

#138
15:37, 3 ноя. 2019

assiduous
В статье http://diligentgraphics.com/2016/04/20/implementing-dynamic-resou… h-direct3d12/ динамические ресурсы реализованы с помощью ring-буфера, но в мастере, насколько я понял, уже другая реализация https://github.com/DiligentGraphics/DiligentCore/blob/master/Grap… DynamicHeap.h - линейный аллокатор + страницы. в связи с чем было переделано? в чём приемущества?

#139
17:04, 3 ноя. 2019

assiduous
> , в которыз часть функциональности берется из базовых классов, что позволяет
> избежать копи-пасты
Bad Design

#140
18:53, 3 ноя. 2019

xruck
> динамические ресурсы реализованы с помощью ring-буфера, но в мастере, насколько
> я понял, уже другая реализация

Да, имеено так и есть. Первоначальный подход пришлось немного переосмыслить в основном из-за следующей проблемы: когда несколько потоков записывают команды каждый с помощью своего deferred контекста, то всем может понадобиться выделять динамическую память. При использовании общего ринг-буфера возникает ограничение, что все контексты должны завершить запись к тому моменту когда вызывается глобальный FinishFrame. То есть асинхронная запись команд через границу фрейма становится невозможной.

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

При текущей реализации каждый контекст аллоцирует себе страничку из глобального аллокатора, и выделяет из нее динамическую память без локов и мутексов - работает быстрее ветра.
В конце фрейма (приложение обязано явно вызвать FinishFrame для всех контекстов кроме immediate) все использованные страницы возвращаются в глобальный пул.

#141
0:26, 4 ноя. 2019

assiduous
Эволюция:) Одно меня конечно пока останавливает от использование библиотеки - распыление на новые и старые апи. Вот если бы только Vulkan/Dx12...С тем старьем уже все понятно

#142
3:53, 4 ноя. 2019

xruck
> Одно меня конечно пока останавливает от использование библиотеки - распыление
> на новые и старые апи. Вот если бы только Vulkan/Dx12...

А что именно смущает и почему было бы легче, если бы были только новые API? Библиотека изначально ориентирована на Vulkan/D3D12 и все решения принимались исключительно в их пользу. Вместе с тем очень много разработчиков спрашивают про GLES3.0, Direct3D11 на Windows7, и для них тоже есть ответ.

#143
(Правка: 8:28) 4:02, 4 ноя. 2019

Direct3D11, кроме того, устанавливает базовый уровень производительности. Я потратил очень много времени на то, чтобы и Direct3D12, и Vulkan были как минимум такими же производительными. Без Direct3D11 очень легко начать давать ложные обещания: мол у меня только новые API и потому все намного быстрее. Я могу со 100% уверенностью говорить о том, где и как использовать преимущества Direct3D12 и Vulkan.

#144
7:29, 4 ноя. 2019

assiduous
> Direct3D11, кроме того, устанавливает базовый уровень производительности. Я
> потратил очень много времени на то, чтобы и Direct3D12, и Vulkan были как
> минимум такими же производительными.

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

#145
7:52, 4 ноя. 2019

innuendo
а ты думал, что быстрый код за тебя gapi само напишет что ли? производительность на каком-нибудь древнем говне мамонта определяется скиллом драйверописателей * 0.75, потому что они пишут драйвер на все возможные случаи применения, а не только на твой. а на современных gapi код будет работать ровно настолько быстро, насколько быстрым ты его напишешь.

#146
(Правка: 8:13) 8:04, 4 ноя. 2019

Suslik

не смешно, даже в UE с DX12 куча проблем  до сих пор

#147
10:20, 4 ноя. 2019
innuendo
> даже в UE с DX12 куча проблем до сих пор
Это вина DX12 или UE?
#148
(Правка: 10:22) 10:22, 4 ноя. 2019
prowkan

когда у тебя будет коммерческий проект под DX12 вот тогда и поговорим

#149
11:35, 4 ноя. 2019

assiduous
Можно было бы убрать все лишнее, и стало бы легче разобраться как пользоваться. Сейчас часть кода неактуальна для старых API а часть для новых. Накатить нормальную абстракцию CommandList, чтобы можно было создавать свои, эмитить...сейчас он почему-то пустой https://github.com/DiligentGraphics/DiligentCore/blob/master/Grap… CommandList.h. (хотя ожидал там все увидеть) А для сравнения перфа написать тесты на чистом DirectX11 но где-нибудь отдельно от движка. А то сейчас получается интерфейс выглядит в стиле DX11 с подпилами под новые API.

Страницы: 19 10 11 1217 Следующая »
ПрограммированиеФорумГрафика