Originally posted by indepe
View Post
Announcement
Collapse
No announcement yet.
OpenGL vs. Vulkan For Older NVIDIA Kepler GPUs (Early 2017)
Collapse
X
-
- Likes 1
-
Originally posted by johnc View Post
I told everyone from the get-go that this whole low-level API craze was nothing more than a big marketing snow-job.
Within a few years developers will be screaming for abstract APIs again.
But even something like vulkan can get layers in the future than will make it easier to use, the possibilities are very wide. Performance-related, we are probably not seen its full potential yet.
Comment
-
Originally posted by johnc View Post
Gaming work is hard to scale across multiple cores also, since there is so much synchronization required in game play. It is done, of course, but it's not without its challenges. You can get more bang for your buck by removing inefficiencies within the API layer and driver, which, to their credit, the new APIs do well, much like AZDO in OpenGL, etc.
Nevermind it's been ages since developers have been exposed to things like manual memory management; doesn't surprise me the first batch of DX12/Vulkan games were bug riddled messes at launch.
- Likes 1
Comment
-
Originally posted by gamerk2 View Post
Pretty much this. Games simply don't scale because of all the synchronization that has to be done. Period. You can get minor gains within certain parts of a game, but on the whole, their structure is serial in nature.
Games are more and more simulating the real world, and the real world is parallel in nature.
Comment
-
Originally posted by indepe View PostGames are more and more simulating the real world, and the real world is parallel in nature.
It's not really parallel in the sense that you can have ten people individually counting objects and then at the end sum the ten sums to get a final sum.
Gaming is one of those workloads where it's hard to just throw more cores at the problem.
Comment
-
Originally posted by johnc View Post
Gaming is heavily synchronized though. When you click a button to fire a gun there's audio, video, AI, and network code that all has to collaborate. That kind of synchronization isn't cheap in terms of efficiency (or bug potential).
It's not really parallel in the sense that you can have ten people individually counting objects and then at the end sum the ten sums to get a final sum.
Gaming is one of those workloads where it's hard to just throw more cores at the problem.
It seems more expensive to build higher frequency CPUs, while even less expensive CPUs seem to have more cores than are usually being used, currently. In so far as future games will want to use more CPU processing power, there doesn't seem to be much of an alternative, except trying to move more and more processing onto the GPU. That requires an even stricter parallelism. And given the efforts of "overclocking" CPUs, and liquid cooling, for example, there does seem to be an interest in more CPU processing power, so why not use those idle cores which are available for free?
Comment
-
You should not forget that many OpenGL engines use translation layers similar to wine. This translation (at least HLSL to GLSL) is often done on one core and is therefore limited by the speed/core. You rarely find engjnes with similar speed across multiple OS.
Comment
-
Originally posted by johnc View Post
I told everyone from the get-go that this whole low-level API craze was nothing more than a big marketing snow-job.
Within a few years developers will be screaming for abstract APIs again.
Comment
Comment