Im just trying the Doom Demo on a 750TI, it losses about 10fps by going to Vulkan... nice work ID Tech, what a good patch to improve old card performance, this is how is done.
Normal for nVidia cards. When the scene is GPU limited you can lose up to 20% of performance: https://youtu.be/d16FlJxp-sw?t=19
It is just a broken Vulkan path. :thumbsdown:
Im just trying the Doom Demo on a 750TI, it losses about 10fps by going to Vulkan... nice work ID Tech, what a good patch to improve old card performance, this is how is done.
What do you expect when the lead rendering programmer is out retweeting "#BetterRed"?
Fortunately my 1080 destroys this game in OpenGL and my upcoming Titan X will do an even better job of it, so whatevs.
Marty Stratton on stage to unveil #DOOM running on @VulkanAPI & GeForce GTX 1080 #GameReady #FightLikeHell
Why don't you guys stop blaming id just like you blamed Oxide, when both id and Oxide work directly with Nvidia daily, and instead blame Nvidia for having shitty drivers.
You're seeing the effects of gpu open according to another poster.Actually, NVIDIA's drivers had excellent support for Doom on day 1, see how well it did in OpenGL relative to the competition which had utterly broken OpenGL drivers.
The (relatively) poor performance on the Vulkan codepath for NVIDIA has nothing to do with NVIDIA's drivers, IMO, as a lot of what the driver handled before is now handled explicitly by the developer.
The Vulkan codepath for Doom is optimized and tweaked for AMD hardware as that codepath likely is a port/derivative of the console codepath.
Do you think 10 fps less in avg is "getting all out of the hardware"? please, wharever you can do in OGL you could do it better on Vulkan, if you wish to, there is no excuse for the loss of performance, worse case scenario should be equal.
You're seeing the effects of gpu open according to another poster.
Amd unified the libraries between console and desktop so optimizations in console can carry over or something to that effect.
Someone needs to explain that program to me more though because I fail to see how it's open when it's clear amd gains the most benefit from it.
Open? As in Open Source? Anyone can use the resources there, modify and distribute them to their hearts content. Practically the very definition of open. It's really not that hard to understand.
Everyone benefits from it. You can learn how to best utilize the GPU hardware by reading the code, you can use the code in your project.. Nvidia can inspect and make sure there are no benchmark cheating shenanigans in it, unlike what we can do with blackbox Gameworks middleware which is completely closed.You're seeing the effects of gpu open according to another poster.
Amd unified the libraries between console and desktop so optimizations in console can carry over or something to that effect.
Someone needs to explain that program to me more though because I fail to see how it's open when it's clear amd gains the most benefit from it.
Do you think that the AMD exclusive GCN shader intrinsic are "open" to optimization on NVIDIA hardware?
Weren't you one of the people (correctly) laughing off claims of bias before the Vulkan patch? Now the tables turn and you do the exact same thing, huh?What do you expect when the lead rendering programmer is out retweeting "#BetterRed"?
Fortunately my 1080 destroys this game in OpenGL and my upcoming Titan X will do an even better job of it, so whatevs.
Uh. Does your browser have some sort of GPU vendor check? If not, then it's as open as can be. https://github.com/GPUOpen-LibrariesAndSDKs
The GCN architecture contains a lot of functionality in the shader cores which is not currently exposed in current APIs like Vulkan or Direct3D® 12. One of the mandates of GPUOpen is to give developers better access to the hardware, and today were releasing extensions for these APIs to expose additional GCN features to developers.
Shader Extensions
With those shader extensions, we provide access to wavefront-wide functions, which is an important building block to exploit the SIMD execution model of GPUs. For instance, the use of mbcnt and ballot can replace atomics in various cases, drastically boosting performance. The wavefront-wide instructions also include swizzles, which allow individual lanes to exchange data without going through memory.
Additionally, we expose readfirstlane and other functions which enable the compiler to move data from VGPRs into SGPRs. Especially for VGPR heavy code, marking variables as wavefront-uniform can reduce the VGPR count significantly.
Another often-requested feature which is getting exposed today is direct access to the barycentric coordinates. This is again an important building block for various algorithms.
Finally, we also provide various utility functions. In this release, were providing the 3-parameter min, max and med functions which map directly to the corresponding GCN opcodes.
Weren't you one of the people (correctly) laughing off claims of bias before the Vulkan patch? Now the tables turn and you do the exact same thing, huh?
It's really simple:
-legacy NV products don't properly support DX12/Vulkan and often lose performance as a result.
-AMD products gain a lot of performance under them, often beating their NV competitors as a result.
-iD obviously has marketing deals with both companies.
With a hand on your heart just tell me, this looks like "extracting all performance out of the hardware" to you?
This is 100% ID Tech fault, trying to blame it on Nvidia drivers is a pittyfull justification by AMD lovers, thats no how low apis work. If 40 fps can be archived by a old, inefficient high level api, them the same can be archived by a new, highly efficient low level api with the right devs work, there is no excuse for the loss of performance, i can fully accept that AMD cards gain MORE fps can Nvidia ones, but not this.
Its VERY funny how Gameworks bashers are defending this ID Tech dissaster and trying to blame it on Nvidia drivers, its VERY funny.
Well, 2 GB of memory is your problem right there. What res is that, 1080p?
VRAM doesn't change in going from OGL to Vulkan.
Well, 2 GB of memory is your problem right there. What res is that, 1080p?
Uh, yeah, that's how APIs work. These API's interface through a driver to the GPU, low level or otherwise. And it seems only AMD has a reliable one fer Vulkan. Zlatan states as such 'ere:
http://forums.anandtech.com/showthread.php?p=38227826&highlight=#post38227826
Entirely possible for there to be a performance regression, if the hardware developer has shoddy drivers. Great example; Direct3D 9 -> OpenGL on AMD hardware. OpenGL just performs like a dog. Why? Inadequate drivers.