Thread replies: 6
Thread images: 1
Thread images: 1
I wonder if people have ever tried to code something in low level OpenGL or Direct3D. Those subsystems do most of the parallelism on the GPU level, don't work well with multithreading on the CPU level/they often work even faster if a single thread is feeding them instructions, and in many cases you can make it much worse by multithreading them. In many game genres it's simply bad design to not go largely single threaded when all you do is feed extremely simple stuff to an extremely paralleled GPU pipeline.
People should shake their heads when others suggest that games can become a lot more multithreaded on the CPU level since in most cases the most you can subthread is something like a sound engine that won't be more than 2% of your load, the genre might not even need AI and similarly for other game logic, and a lot of that stuff also move into GPUs' parallelism to begin with.
PS. Some benchmark reviewers are so clueless that they bottleneck their GPUs and then pretend that they do a CPU test. The entire point is to test the CPU bottlenecks when you test CPUs. If you don't, you practically do motherboard testing.
>>
Quality post
What about Vulkan?
>>
>>59213531
When a GPU is already being fed as much as it can(can't) handle, why would it matter if you can feed it even more?
>>
>>59213531
>Vulkan
In most cases it makes the CPUs even MORE irrelevant.
Read the basic descriptions about it on it:
> Reduced driver overhead, reducing CPU workloads.
> Reduced load on CPUs through the use of batching, leaving the CPU free to do more computation or rendering than otherwise.
> Better scaling on multi-core CPUs. Direct3D 11 and OpenGL 4 were initially designed for use with single-core CPUs and only received augmentation to be executed on multi-cores. Even when application developers use the augmentations, the API regularly do not scale well on multi-cores.
Out of 3 advantages, 2 of them REDUCE CPU load, and the third is usually not even needed to begin with since the GPU has been already bottleneck.
So in order for Vulkan to make multicore CPUs more relevant, they must do EVEN MORE parallel stuff ALREADY *(and in most cases they do almost nothing before Vulkan appeared), or it's used on software that does NOT bottleneck a GPU at all which is kinda unrealistic for most gaming scenarios a lot of non-gaming also.
>>
>>59213511
I'm shit at multithreading stuff efficiently. But I'm sure there are engineers out there that sperge on multithread efficiency all day long who wouldn't have too much trouble optimizing a game for multicore performance.
>>
>>59214624
There is nothing to optimize usually! Most games already bottleneck the GPU, not the CPU. Even when something like Vulkan/nuOpenGL/nuDirect3D try to make it more multithreaded, they remove even more load from the CPU at the same time with their other additional methods like batch instructions!
Thread posts: 6
Thread images: 1
Thread images: 1