![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
-
Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.
Tools sound far more important to third party developers using an engine, if you are the actual dice engine team would they need the same level of documentation to get going with their own engine? I think you are letting out why some engines do better on more hardware. If the engine devs are directly responsible for parts of the creation of the game
This seems like a major added layer of expertise that can be brought to bare on a project than some random third party game dev using a third party engine with nowhere near the depth of knowledge of the internal workings of the host engine. Add on years of experience with an engine team that has spent countless hours optimizing games for different hardware and its no wonder that such games run better across the board.
Even bioware under the aegis of EA likely benefits. They can work with the frostbite engine team and add things and discuss how it will interact with the engine and different hardware. I wonder if there is some metric to gauge the levels of interaction between engine devs and game devs under the umbrella of different engines?
I'd imagine it's pretty strong within frostbite since it's basically all EA, pretty good for game devs creating their own engine from scratch because... they are literally handling both aspects fully like Firaxis, And weakest with the third party engines (Again, maybe among the big three UE4 is the best of the bunch, the Lord of the Flies, the king of the sunken hill) but that still translates OK to nvidia because in dx11 their hardware is less reliant on engine/games being designed to run optimally to perform well.
This makes me hope EA gobbles up more studios until the third party guys are better able to provide better performance across the board, because as much as people hate EA, their engine dev guys are ahead of the pack when it comes to making sure their games run well and are NOT AC unitys and batmans.
I see the conversation has now drifted to engines.
Disclaimer: I don't get much of a say in which engine is used by my studio. I also do not wish to disclose which engine my studio uses.
However, I can assure you, technical capability of an engine is often not the top priority when a game is in production and developers are taking a straw poll on which engine to use. There are many factors at play, be it licensing costs, the tools available, the documentation available, the library of code available, the support available, the wealth of assets available, the speed of updates available, the stability of the engine, the ease of developing on the engine and finally the ease of testing with the engine.
As I mentioned, games development is becoming increasingly expensive even for non-AAA games. Very often, you will find that the main constraint we have with an engine is not its technical superiority, but which one our development budget affords.
Take Unity engine for example. It's not the most capable engine and doesn't produce the biggest wow-factor compared to any of the engines, yet it is fast becoming one of the most popular engines in use. Why? As I mentioned, developers don't like to invent the wheel twice. Whatever they can do to reduce the amount of work they need to do, they will do it. Unity has so much library code available, along with assets that people can freely access that there is a lot of money development budgets can save from by using the Unity engine.
Game developers have 1 main overriding objective: To make a game. Everything else is secondary, so long as it helps in making the game. If the game is made, and is fun, and has mediocre graphics, so be it. If the game is made, and is fun, and manages to have superb graphics to boot, even better.
But a game that is made, is not fun and has superb graphics, that's a tech demo. There's a game out there which fits this description like a glove. You know which one it is.
Now, I do want to address DirectX12 in particular(I am avoiding Vulkan because our studio is not touching Vulkan or OpenGL with a barge pole). In general, what I see happening in the industry is, we push standards not because it's fun or exciting to do it. Okay some do, but we push standards because we encounter problems that the current technology cannot solve. Each iteration of DirectX pushes the boundaries because we want to solve problems that previous iterations of DirectX won't let us solve.
In my opinion, most developers can achieve nearly all the visual effects they want with DirectX11. DirectX12 is more of a performance gain rather than improving anything visual. We already achieve most of the wow-factor we want with DirectX11 and DirectX12 is more making the wow go faster. Perhaps one day someone will show me something DirectX12 can render which DirectX11 cannot but for now, I'm sticking to the line that it's all about removing performance bottlenecks.
But with that in mind, I see that as being contrary to the mission statement of being an IHV, which is to sell hardware. If DirectX12 really gives all the old hardware a new lease of life, then we are talking about a hardware vendor losing 1-2 generations worth of sales, because there's no point to it. Think of our CPUs, most of us hardly upgrade CPUs at the rate we upgrade GPUs, because CPUs are good enough. If DirectX12 delivers all that, then IHVs have signed themselves a few quarters of losses.
Without naming any particular IHVs, I think some of the IHVs figured that out. I don't know if they do it deliberately, but my anecdotal evidence is that support of DirectX12 has been lacklustre and nowhere near the older days with DirectX9/11. A lot of people seem to put a lot of faith in that one of the IHVs will gain plenty in particular with using DirectX12. I would hope so but in general, I cannot see a lot of developers spending their development time writing for that hardware. There's one particular IHV who is very eager to push DirectX12 but unless you are a big name, you still won't be getting help.
Disclaimer: I don't get much of a say in which engine is used by my studio. I also do not wish to disclose which engine my studio uses.
However, I can assure you, technical capability of an engine is often not the top priority when a game is in production and developers are taking a straw poll on which engine to use. There are many factors at play, be it licensing costs, the tools available, the documentation available, the library of code available, the support available, the wealth of assets available, the speed of updates available, the stability of the engine, the ease of developing on the engine and finally the ease of testing with the engine.
As I mentioned, games development is becoming increasingly expensive even for non-AAA games. Very often, you will find that the main constraint we have with an engine is not its technical superiority, but which one our development budget affords.
Take Unity engine for example. It's not the most capable engine and doesn't produce the biggest wow-factor compared to any of the engines, yet it is fast becoming one of the most popular engines in use. Why? As I mentioned, developers don't like to invent the wheel twice. Whatever they can do to reduce the amount of work they need to do, they will do it. Unity has so much library code available, along with assets that people can freely access that there is a lot of money development budgets can save from by using the Unity engine.
Game developers have 1 main overriding objective: To make a game. Everything else is secondary, so long as it helps in making the game. If the game is made, and is fun, and has mediocre graphics, so be it. If the game is made, and is fun, and manages to have superb graphics to boot, even better.
But a game that is made, is not fun and has superb graphics, that's a tech demo. There's a game out there which fits this description like a glove. You know which one it is.
Now, I do want to address DirectX12 in particular(I am avoiding Vulkan because our studio is not touching Vulkan or OpenGL with a barge pole). In general, what I see happening in the industry is, we push standards not because it's fun or exciting to do it. Okay some do, but we push standards because we encounter problems that the current technology cannot solve. Each iteration of DirectX pushes the boundaries because we want to solve problems that previous iterations of DirectX won't let us solve.
In my opinion, most developers can achieve nearly all the visual effects they want with DirectX11. DirectX12 is more of a performance gain rather than improving anything visual. We already achieve most of the wow-factor we want with DirectX11 and DirectX12 is more making the wow go faster. Perhaps one day someone will show me something DirectX12 can render which DirectX11 cannot but for now, I'm sticking to the line that it's all about removing performance bottlenecks.
But with that in mind, I see that as being contrary to the mission statement of being an IHV, which is to sell hardware. If DirectX12 really gives all the old hardware a new lease of life, then we are talking about a hardware vendor losing 1-2 generations worth of sales, because there's no point to it. Think of our CPUs, most of us hardly upgrade CPUs at the rate we upgrade GPUs, because CPUs are good enough. If DirectX12 delivers all that, then IHVs have signed themselves a few quarters of losses.
Without naming any particular IHVs, I think some of the IHVs figured that out. I don't know if they do it deliberately, but my anecdotal evidence is that support of DirectX12 has been lacklustre and nowhere near the older days with DirectX9/11. A lot of people seem to put a lot of faith in that one of the IHVs will gain plenty in particular with using DirectX12. I would hope so but in general, I cannot see a lot of developers spending their development time writing for that hardware. There's one particular IHV who is very eager to push DirectX12 but unless you are a big name, you still won't be getting help.
Not many people are happy to work at EA
my lead programmer, was part of the Frostbyte team when they were making it initially, he personally told me, it was a nightmare company to work for. and I know for a fact working with them at a distance with another company in the middle, the management isn't the greatest.Dev support wise, that is different they have always been good with that, but that comes from the developers and they are very responsive, which is good, hell at the end its their product being showcased.
When buying a license from the other companies though like Epic or Crytek, you do get dedicated support from your project (I'm not talking about the free licenses or the indie developer licenses, their support is relegated to forum support) I could actually call up Crytek and get info as quickly as I'm thinking of the question.
All of these engines are actually IHV agnostic, yeah some of them tend to lean towards one IHV or the other but thats not the engine, that is the game and game dev team's doing and what ever they have access too and what ever contracts or promises they have made to either IHV.
This will never change as well, doesn't matter who controls the consoles.......
Bottom line money talks BS walks, and money constitutes time saved and what IHV's can provide as support for game dev's to make their time easier.
Last edited:
crazycrave
2[H]4U
- Joined
- Mar 31, 2016
- Messages
- 2,247
I don't play a lot of games other then World Of Tanks which has finally made it to DX 11, My X58 Xeon 6 core and 290x just destroys WoT at 1920 x 1080 HD Max as it's 112 to 120fps and super smooth game play , so saying AMD sucks at DX 11 kind of sounds like you have not ran an AMD card in like the past 6 years or your just part of the monkey see monkey do Nvidia fan club.
nice sample size
I have both nV and AMD cards,but haven't updated my last AMD card from a 290x nor is it even being used any more. World of Tanks doesn't do much on CPU's now a days, and you having a 6 core CPU is overkill for it, damn even 4 core i5 CPU's chews through the requirements for that game.... I don't see why you even need an overkill system like that for just one game, of course since you are using a xeon I'm expecting your work to be doing with something that would need such a system.
AMD's driver support for their CPU OVERHEAD is bad (I'm not talking about anything else, their driver stability is just fine), it hurt their sales too!, there is way around that, I don't care if you can get Jessica Alba to strip for me, it won't change that fact.
Last edited:
- Joined
- Aug 15, 2005
- Messages
- 9,231
Interesting results here, for a first gen i5 and a phenom II X4. Seems to show Vulkan taking a hit with AMD, on these older, stock clocked processors. whereas Nivida is pretty much transparent and performs the same, no matter the CPU, in Vulkan. And still quite similar, in OpenGL.
Last edited:
Tup3x
[H]ard|Gawd
- Joined
- Jun 8, 2011
- Messages
- 1,946
^^It looks like AMD still has issues with overhead. Now it just scales better with multiple cores but if IPC sucks then the performance will be poor too.
JustReason
razor1 is my Lover
- Joined
- Oct 31, 2015
- Messages
- 2,483
Needs more context. They only show 1 new processor against old ones, too extreme cases. If you really wanted to make it scientific it would have been nice to see some in betweens.
JustReason
razor1 is my Lover
- Joined
- Oct 31, 2015
- Messages
- 2,483
If you weren't so hellbent on acting superior, you would see that the pool of information there is a bit shallow. Having some processors between the lineage used would go a long way to understanding why the huge discrepancy. I am in no way inferring AMD is equal to Nvidia on overhead but when nearly all results using current CPUs including AMDs own 4-6 year old versions do not show these results then it does make one curious as to why on those. Obviously it is some coding issue. Ashes showed great results of the phenoms although I cant recall if there were Nvidia/AMD direct tests done. That was my point and my interest in more information so I can ascertain at least a small idea as to why the huge variation.
I'm not saying I'm superior, its just a IRONIC statement from you lol, just look here.
Now we need more information because there seems to be a negative effect on lower end CPU's?
Hmm its a two way street ya know.
So what is it, the CPU is being bogged down to the point async doesn't help with lower end systems? or Async can magically over come anything and it is the real reason why AMD is doing so well on LL API's?
Now we need more information because there seems to be a negative effect on lower end CPU's?
Hmm its a two way street ya know.
So what is it, the CPU is being bogged down to the point async doesn't help with lower end systems? or Async can magically over come anything and it is the real reason why AMD is doing so well on LL API's?
JustReason
razor1 is my Lover
- Joined
- Oct 31, 2015
- Messages
- 2,483
Those posts are independent from one another. And the first mirrors greatly all review results. The second is a rational request is it not? Does more information bother you? Do you fear what we could glean given such? You are being difficult just to be difficult. Its ok you don't bother me, it is fun watching you squirm though.
no I don't, I usually always ask for more information lol, I haven't drawn any conclusions yet, but looking at how this problem seems to be a recurring one, I wouldn't be surprised if its still there. Specially in Doom where those death animations and physics heavy scenes might hurt a lower end CPU
PS, they aren't really independent from each other, cause they just aren't, you are telling someone they are wrong based off of a preconception of yours which is incorrect, then when I chimed in and stated there might be issues with Doom on one of the IHV cards and we really haven't seen the fix for AMD cpu overhead yet, at least for DX12, (also its might still be there for other API's too and DX11 at least compared to nV cards, you go about getting personal......
Yes AMD's overhead is still there on LL API's but its much less but becomes predominantly worse with heavy CPU physics I have seen this first hand on UE4, when not using Flex for water simulations, albeit I didn't think Doom would have used that much CPU for the things they are doing but I guess they are..... Nor did I expect to see any game so soon hit this, so..... Also its more on the developers end cause its not smart to push the CPU to that type of usage, still have to many many systems selling with i3's so that should be looked into.
Gleaning done? Now you have it, its something the developer did wrong...... or could do better......
Oh yeah lets add this in there too, this problem doesn't seem to show up on the console version of the game so hmm yeah I can see low level api transitions are simple to do from console to pc?
PS, they aren't really independent from each other, cause they just aren't, you are telling someone they are wrong based off of a preconception of yours which is incorrect, then when I chimed in and stated there might be issues with Doom on one of the IHV cards and we really haven't seen the fix for AMD cpu overhead yet, at least for DX12, (also its might still be there for other API's too and DX11 at least compared to nV cards, you go about getting personal......
Yes AMD's overhead is still there on LL API's but its much less but becomes predominantly worse with heavy CPU physics I have seen this first hand on UE4, when not using Flex for water simulations, albeit I didn't think Doom would have used that much CPU for the things they are doing but I guess they are..... Nor did I expect to see any game so soon hit this, so..... Also its more on the developers end cause its not smart to push the CPU to that type of usage, still have to many many systems selling with i3's so that should be looked into.
Gleaning done? Now you have it, its something the developer did wrong...... or could do better......
Oh yeah lets add this in there too, this problem doesn't seem to show up on the console version of the game so hmm yeah I can see low level api transitions are simple to do from console to pc?
Last edited:
Car analogies are rarely good and this is no exception. AMD has shit performance per watt compared to nVidia, the exact opposite of what a highly tuned 4 does compared to a V8.
Last edited:
GameLifter
Gawd
- Joined
- Sep 4, 2014
- Messages
- 717
Odd. It shows you as quoting me when I'm not the one who made this post. Not sure what happened but thought I'd point it out. No big deal or anything like that.
PontiacGTX
Gawd
- Joined
- Aug 9, 2013
- Messages
- 810
My bad, not sure how I messed that up... Fixed
PontiacGTX
Gawd
- Joined
- Aug 9, 2013
- Messages
- 810
AMD GCN Structure hasnt changed significantly so that wont be a problem
err not all are exposed across all api's that I'm aware of and not for all GCN either.
GCN Shader Extensions for Direct3D and Vulkan - GPUOpen
GCN Shader Extensions for Direct3D and Vulkan - GPUOpen
PontiacGTX
Gawd
- Joined
- Aug 9, 2013
- Messages
- 810
that might be solved also it is compatible with all GCN GPUs , and Vulkan works with the Shader intrinsic functions like DOOM shows and gets really big performance gains compared to Paxwell
That isn't why those gains are there in Doom, shader intrinsic make it so that the developer doesn't need to worry about porting correct? Guess what it took them quite a bit of time to port to Vulkan even with them, is that what you are getting at. AND no they aren't available yet and they aren't equal across all GCN products.
That is exactly what I highlighted if you read it. They specifically go into what is supported and what isn't across the DX12 and Vulkan and they even say you have to check to see what is supported by device.
Porting is never easy, doesn't matter if ya have shader intrinsics or not. Yeah it might make it a little easier but specific shader code that might use shader intrinsics are not the only shaders there nor is the only problem area of porting. How many people here with experience with porting, have stated the same thing? Reading a document about shader intrinsics isn't the same as using them or doing a port.....
Using someone elses code to port is always harder then building something from ground up. Writing code is like the way a programmer thinks, each person thinks differently, you need to understand what and how the original programmer created the code as a whole and then break it down to its sub parts, then start the port. Its not a longer process than creating something from scratch but when things go wrong, its harder to back trace and figure things out because, as I stated earlier the familiarity with the code is what makes porting hard.
if you have a secondary company doing the PC port, they almost are guaranteed to have less experience the original programming team that did the console version of the game.
That is exactly what I highlighted if you read it. They specifically go into what is supported and what isn't across the DX12 and Vulkan and they even say you have to check to see what is supported by device.
Porting is never easy, doesn't matter if ya have shader intrinsics or not. Yeah it might make it a little easier but specific shader code that might use shader intrinsics are not the only shaders there nor is the only problem area of porting. How many people here with experience with porting, have stated the same thing? Reading a document about shader intrinsics isn't the same as using them or doing a port.....
Using someone elses code to port is always harder then building something from ground up. Writing code is like the way a programmer thinks, each person thinks differently, you need to understand what and how the original programmer created the code as a whole and then break it down to its sub parts, then start the port. Its not a longer process than creating something from scratch but when things go wrong, its harder to back trace and figure things out because, as I stated earlier the familiarity with the code is what makes porting hard.
if you have a secondary company doing the PC port, they almost are guaranteed to have less experience the original programming team that did the console version of the game.
Last edited:
Alkaladur
Limp Gawd
- Joined
- Apr 9, 2016
- Messages
- 179
Latest driver brings updated vulkan runtime and driver support for it, very big reduction in CPU overhead, 5-10% performance gains it seems
Alkaladur
Limp Gawd
- Joined
- Apr 9, 2016
- Messages
- 179
I know right ? Basically 1/4 of what it was lol, impressive stuff. Titan X owners will be overjoyed I'm sure
cybereality
[H]F Junkie
- Joined
- Mar 22, 2008
- Messages
- 8,787
CPU times! Wat!!!!
Shintai
Supreme [H]ardness
- Joined
- Jul 1, 2016
- Messages
- 5,677
D
Deleted whining member 223597
Guest
This is a bit off topic but fuck those graphs. Why would you use the same color with almost indistinguishable lines to show different API's/Settings? It does look like Vulkan now helps a lot at lower resolutions, less at higher resolutions.
cybereality
[H]F Junkie
- Joined
- Mar 22, 2008
- Messages
- 8,787
When I was testing at 1440P Surround (7680 x 1440) I was actually getting better performance from OpenGL.
- Joined
- Nov 22, 2008
- Messages
- 6,617
Vulkan doesn't support mgpu yet iirc. Were you using sli in opengl?
cybereality
[H]F Junkie
- Joined
- Mar 22, 2008
- Messages
- 8,787
I had SLI enabled, yes, but I was under the impression that DOOM didn't support it either way. That could have made the difference if SLI was working in OpenGL mode.
- Joined
- Nov 22, 2008
- Messages
- 6,617
I believe it was added a while ago, couple months. There's many articles referencing the sli update.
Ieldra
I Promise to RTFM
- Joined
- Mar 28, 2016
- Messages
- 3,539
Gentlemen, I am benchmark DOOM using the latest drivers to see how it fares vs OGL now the vulkan runtime is updated. I have a slight problem... OGL runs like crap, I'm talking 12fps. CPU times above 80ms, gpu is basically idle. Anyone encounter this ? it was fine earlier
Ieldra
I Promise to RTFM
- Joined
- Mar 28, 2016
- Messages
- 3,539
This is at 1440p borderless fullscreen, the only setting I changed was shadows from ultra to nightmare
I'll test 1080p later tonight, 1080p should yield gains.
Ieldra
I Promise to RTFM
- Joined
- Mar 28, 2016
- Messages
- 3,539
1080p
defaultluser
[H]F Junkie
- Joined
- Jan 14, 2006
- Messages
- 14,398
Yeah, it's pretty clear from all these tests (both leidra and Snabbtest) that the Nvidia GPUs are CPU-limited at 1080p, which is why Vulkan makes such a positive difference on the top-end Nvidia parts, but does nothing for the 1060 and lower.
And at 1440p the results become more GPU-limited for Nvidia.
The game can obviously use more cores in Vulkan mode. This especially helps performance of the AMD cards, which are all CPU-limited at 1080p. It seems to be an efficiency percentage barrier, not some hard frame-rate barrier like we've seen in the past. The improvement is higher the more powerful the card, so this definitely points to a soft "efficiency barrier."
280X = 25% faster
RX 470 = 28% faster
RX 480 = 35% faster
390X = 40% faster
Fury X = 45% faster
I'm pretty sure the majority of these performance improvements are the CPUs improvement, with an increasing amount of async as you go up the chain.
And then once we jump to 1440p, my theory is : only the 390x and the Fury X have enough memory bandwidth to make use of the async compute (more compute is bandwidth-intensive), which is why they continue to see benefits at higher resolutions.
So the jury is still out as to the benefits of async on the RX 480 versus the 1060. AMD's previous cards prior to the 285 all had a shit-ton of extra bandwidth.
I find it funny that the 1060 swaps places with the RX 480 at 1440p. Is this yet-another indicator that 32RPOs was a bad choice for AMD, or is the game hitting some other limit?
And at 1440p the results become more GPU-limited for Nvidia.
The game can obviously use more cores in Vulkan mode. This especially helps performance of the AMD cards, which are all CPU-limited at 1080p. It seems to be an efficiency percentage barrier, not some hard frame-rate barrier like we've seen in the past. The improvement is higher the more powerful the card, so this definitely points to a soft "efficiency barrier."
280X = 25% faster
RX 470 = 28% faster
RX 480 = 35% faster
390X = 40% faster
Fury X = 45% faster
I'm pretty sure the majority of these performance improvements are the CPUs improvement, with an increasing amount of async as you go up the chain.
And then once we jump to 1440p, my theory is : only the 390x and the Fury X have enough memory bandwidth to make use of the async compute (more compute is bandwidth-intensive), which is why they continue to see benefits at higher resolutions.
So the jury is still out as to the benefits of async on the RX 480 versus the 1060. AMD's previous cards prior to the 285 all had a shit-ton of extra bandwidth.
I find it funny that the 1060 swaps places with the RX 480 at 1440p. Is this yet-another indicator that 32RPOs was a bad choice for AMD, or is the game hitting some other limit?
Ieldra
I Promise to RTFM
- Joined
- Mar 28, 2016
- Messages
- 3,539
AMD users should compare their performance hit from TSSAA (async) vs FXAA (no async) in OGL and compare to Vulkan. That should give us an idea of how much async affects things.