DX12 is pure trash, yes. It's the windows vista of the gaming APIs.I'm starting to fell DX12 is the biggest issue.
With DX11 you could max out the GPU pretty easy... now with DX12 you basically have several issues and the GPU is threre basically doing nothing.
There are something weird with DX12 that related to these PC ports and Series S/X performance.
Was DX12 new features just marketing?
DX12 was a pure marketingI'm starting to fell DX12 is the biggest issue.
With DX11 you could max out the GPU pretty easy... now with DX12 you basically have several issues and the GPU is threre basically doing nothing.
There are something weird with DX12 that related to these PC ports and Series S/X performance.
Was DX12 new features just marketing?
I've been suspecting this for a long time. The whole shader compilation stuttering thing came out of nowhere, this was not a common issue on PC.I'm starting to fell DX12 is the biggest issue.
With DX11 you could max out the GPU pretty easy... now with DX12 you basically have several issues and the GPU is threre basically doing nothing.
There are something weird with DX12 that related to these PC ports and Series S/X performance.
Was DX12 new features just marketing?
Very generic summary. Be creativeAllow me to summarize:
Very generic summary. Be creative
Phil told us that DX12 would bring 1080p gaming on the xbone and unparalled performance on PC.I'm starting to fell DX12 is the biggest issue.
With DX11 you could max out the GPU pretty easy... now with DX12 you basically have several issues and the GPU is threre basically doing nothing.
There are something weird with DX12 that related to these PC ports and Series S/X performance.
Was DX12 new features just marketing?
Yes.Phil told us that DX12 would bring 1080p gaming on the xbone and unparalled performance on PC.
Does Vulcan have similar shaders build issues?
Among problems that developers have with using Vulkan and potential areas of development for the future, I noticed several common themes:
- Shader/pipeline compilation versus dynamic states. All the pipeline states baked into a pipeline object obviously require lots of time to compile. But not only time - Valve said their pipeline cache can be several gigabytes of storage per game! Adding more dynamic states, on the other hand, could introduce unexpected slow paths in the driver. Someone said that "best practices" validation layer could help with this problem - it includes performance recommendations specific to a GPU vendor. There was also a voice that engine developers should start contributing to "best practices" too, to include things they observed to work well. There was a hand voting who wants everything baked into a pipeline state versus more dynamic states. Result was a tie.
- Multiple presentations showed developers’ struggles with resource binding. They often mentioned going bindless, appreciated VK_EXT_descriptor_buffer.
- Development of shading languages. General direction seems to be that developers want more high-level languages, like C++, with classes, templates etc., that would allow them to develop entire complex libraries, preferably also to interleave GPU code with C++ code in the same source file. Khronos/LunarG admitted HLSL is in better shape than GLSL already. GLSL is still to be maintained, but not going to get new big features like templates. There was an idea to use Circle as the shader language.
Sony’s APIs are also a lot closer to the metal than XBox, and that makes a huge difference.Remember "oh man Xbox will be so much better than PS5 due to dx12" when we knew Sony has some of the best apis tht they use.
They didn't realize that Playstation already had an api with all the features it needed. Sony just didn't feel the need to beat their chests over it.Remember "oh man Xbox will be so much better than PS5 due to dx12" when we knew Sony has some of the best apis tht they use.
"Buh, buh RDN2, TOOLS!!!"They didn't realize that Playstation already had an api with all the features it needed. Sony just didn't feel the need to beat their chests over it.