- Joined
- Nov 22, 2008
- Messages
- 6,617
It's hilarious that they only used old blocks all with 100K already on the odometer, then they aged them even more reportedly by pissing on them lol. That m10 block started life in a slug.
![[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.
It's hilarious that they only used old blocks all with 100K already on the odometer, then they aged them even more reportedly by pissing on them lol. That m10 block started life in a slug.
Bandalo
2[H]4U
- Joined
- Dec 15, 2010
- Messages
- 2,657
Maybe we should do that with old video card PCBs...
N4CR
Supreme [H]ardness
- Joined
- Oct 17, 2011
- Messages
- 4,944
Don't get me wrong their solution works great for now, but I'm meaning just like the P4 Northwoods were all good, the Presshotts were not. Future for 'brute force' is well trodden path and that's the best example I could use. Nvidia will have to eventually go AMD style (e.g. Core2) in future.
I'd more say AMD is the lazy v8 that doesn't do much unless it's at full load in a truck/van or tweaked for a car - just like an LS V8. Under right usage scenario it's also very efficient but not with improper loading (heavy vehicle = shitty drivers).
Intel is the high revving, high strung IL4 that does the same thing with half the cylinders/die size.... but it can only go so much further ahead of that V8 before thermodynamics (electrical engineering) says nope.
Haha yeap! Seen those blocks in the flesh in Germany being reconditioned. Thick as hell cast Iron cylinders, basic as hell design with little to go wrong. They do a few modifications to them to make it all wok but all in all, the block is pretty much as is... quite impressive.
Last edited:
JustReason
razor1 is my Lover
- Joined
- Oct 31, 2015
- Messages
- 2,483
WRONG at least for the most part. IT ISNT ASYNC (COMPUTE + GRAPHICS) THAT IS GIVING AMD ITS PERFORMANCE IN DOOM IT IS ASYNC SHADERS (COMPUTE SHADERS). For the love of God and all that is holy learn this. Watching bickering over async when it is the shader used for AMD that makes the lions share difference is getting old.
- Joined
- May 11, 2005
- Messages
- 7,502
No, I'm correct. When you say "async shaders"' thats just the amd optimized rendering path. Stop putting the word "async" in everything, it makes no sense.
Async means you're doing out of band work, such as compute work in a graphics pipeline. That's the asynchronous part. When you're doing graphics processing, there's nothing async about it. It's called running shaders. Amd has provided ones which are optimal for their hw.
Ok just a hint (well definitions aside), the problem itself.....
Not to be a ego buster but Doom Vulkan runs better on AMD hardware because the path for AMD hardware is more optimized, we have to wait and see if the developers can do better optimizations for nV hardware to equalize the parity. Lets leave it at that, cause the path for nV's hardware is doing some things it shouldn't be......
Not to be a ego buster but Doom Vulkan runs better on AMD hardware because the path for AMD hardware is more optimized, we have to wait and see if the developers can do better optimizations for nV hardware to equalize the parity. Lets leave it at that, cause the path for nV's hardware is doing some things it shouldn't be......
Factum
2[H]4U
- Joined
- Dec 24, 2014
- Messages
- 2,455
I don't care for PR...you want a slower solution, I want the fastest, fair enough.
It's like calling the Fury for "a technical better" solution and declaring it a winner and in the same time ignoring the SKU's beating it with no use of HBM.
There is a reason Async Shaders not are a part of the DirectX12 specifications, as it adresses an AMD purely problem.
It's always the same with you guys...
The amd livecast was a bit of a bust, but Robert did touch on a bit of that here
at around the 18:10 mark.
It sounds like it's just inherently more difficult to get truly multithreaded functionality. As to why and how nvidia tended to fare better than amd cards, I suspect that has to do in part with how the chips were designed on top of any additional driver team resources.
On the opposite end, some dx11 games seemed to perform well on everyones hardware, the frostbite 3 engine comes to mind from DICE, they seem to know what the fuck they are doing as devs, and were able to construct an engine that could tap more performance, even with the constraints of dx11.
On the video I linked above, Robert said the biggest impact of dx12 in his view is probably multi threaded command buffer recording as opposed to async (the latter of which could not be tapped at all in dx11).
If you amd had the same resources and driver team and time that nvidia had to optimize dx11 performance, I don't think they would have been able to do as well on gcn in dx11 as they have on their cards, I think part of the additional constraint is based on how gcn is constructed. I don't know how much, just a hunch.
JustReason
razor1 is my Lover
- Joined
- Oct 31, 2015
- Messages
- 2,483
Not a hunch it is in fact... a fact. It was in a video they released before DX12, but later became a DX12 video. The video was part of Mantle and explained in simple terms the multithread aspect necessary for GCN which DX11 didn't allow. After DX12 there was an article on Anandtech that went into some detail as to GCNs architecture and the difference between DX11 and DX12.
AMD Dives Deep On Asynchronous Shading
It explained that DX11 was never gonna fully utilize GCN but DX12 would have that ability and that is why there is such a huge jump with DX12/Vulkan. Now you add the consoles and devs getting experience with this Low Level Access and you see a lot of performance transferring to AMD PC hardware.
yeah that video is fed up, AMD's marketing team simplified it too much and took out necessary portions.....
Also console program optimizations do not translate to PC optimizations EVEN NOW. So please refrain from saying AMD has an advantage because of their consoles, they don't. LLA is different in consoles than it is in PC API's, MUCH different! And this isn't even talking about async. With async its even more different!
Also console program optimizations do not translate to PC optimizations EVEN NOW. So please refrain from saying AMD has an advantage because of their consoles, they don't. LLA is different in consoles than it is in PC API's, MUCH different! And this isn't even talking about async. With async its even more different!
Err its not what the hell they are doing, it takes much more work and optimization to get around AMD DX11 driver overhead (it wasn't really know either till Mid 2015 that AMD had this problem), that is what Dice did good for them, unfortunately, their isn't the only engine out there (and not even that wildly used either) and not to mention, you can see how much work nV put into their Dx11 drivers so devs didn't need to worry about this.
- Joined
- May 11, 2005
- Messages
- 7,502
We're actually agreeing on the core: AMD's drivers could not saturate the GCN cores sufficiently with directx11 and opengl. The question is why.
They are heavily casting that as "well, the api didn't let us".
That's partially true. It's also true their drivers never have done a very good job of decomposing rendering to a degree which fills the shaders for max efficiency. When this work is pushed out of their driver, iD (for example) is able to fill those arrays with work.
A contention is they can do so because of async input queues. This seems highly unlikely, and requires radically different code to accomplish versus the existing opengl renderer.
What is more likely is that the vulkan path does not do much async, but simply is smarter and better about distributing its workload to the gcn cores than their opengl driver did. This is a straightforward assumption, and I find occam's razor to hold true more often than not.
If I worked for AMD (well, actually I have, just not now), I'd say it was an API problem too, rather than say my drivers weren't very good.
They are heavily casting that as "well, the api didn't let us".
That's partially true. It's also true their drivers never have done a very good job of decomposing rendering to a degree which fills the shaders for max efficiency. When this work is pushed out of their driver, iD (for example) is able to fill those arrays with work.
A contention is they can do so because of async input queues. This seems highly unlikely, and requires radically different code to accomplish versus the existing opengl renderer.
What is more likely is that the vulkan path does not do much async, but simply is smarter and better about distributing its workload to the gcn cores than their opengl driver did. This is a straightforward assumption, and I find occam's razor to hold true more often than not.
If I worked for AMD (well, actually I have, just not now), I'd say it was an API problem too, rather than say my drivers weren't very good.
Its not an API problem, its an AMD hardware/driver related issue, we saw their poor Ogl performance for many many years, and then this "driver overhead" issue started in 2015,
Quite frankly what it has been from AMD, its been a shit show for the last two generations of graphics cards.... and along with that of crap drivers. looks to me is if AMD doesn't do the work, things turn out fine lol, Well that isn't the case actually instead of having a competent driver team they need a competent dev rel team to push dev's to "do async right". We saw how that turned out......
Quite frankly what it has been from AMD, its been a shit show for the last two generations of graphics cards.... and along with that of crap drivers. looks to me is if AMD doesn't do the work, things turn out fine lol, Well that isn't the case actually instead of having a competent driver team they need a competent dev rel team to push dev's to "do async right". We saw how that turned out......
JustReason
razor1 is my Lover
- Joined
- Oct 31, 2015
- Messages
- 2,483
I think I liked your absence better. Stop taking posts out of context and being so bitter. It is GCN in consoles and GCN in PC, ergo what they learn from one CAN be applied to the other, although maybe not exactly the same way as in console to pc. Come on man you know better.
Its way different, I can't go into it cause I'm not allowed to,but its not even close, just look over at B3D, we touched upon it a few times!
Only a person that is naive (or just doesn't know what the hell they are talking about, or following AMD marketing) would say things like you do....... yeah we know which one is you.
Only a person that is naive (or just doesn't know what the hell they are talking about, or following AMD marketing) would say things like you do....... yeah we know which one is you.
JustReason
razor1 is my Lover
- Joined
- Oct 31, 2015
- Messages
- 2,483
How convenient. I love how some of you won't bother quoting me I guess hoping I won't see that you posted. Either way you are wrong and like usual taking too literal a stand as to obfuscate the topic at hand. The gcn architectures are similar/same so the simple over view is yes one to the other, console to pc. And yes there is a difference as pc hs differing gcn versions and core counts and buses and VRAM. But that requires only tweaking on pc side, not the overhaul you allude to.
Its not just a simple tweak. And no, I'm not obfuscating anything. You want to do a google search be my guest, you will find out some things. Too much stuff to do this morning to point out your errs on this. Yeah its closer but not much closer....
How different is programming on a console dev kit as compared to programming for the Windows platform? - Quora
This is exactly why no one can talk about the specifics of the differences between console vs. PC programming cause anyone that has access to the Dev Kits are under NDA and we aren't allowed to.
JustReason
razor1 is my Lover
- Joined
- Oct 31, 2015
- Messages
- 2,483
You are talking software I am talking hardware. Use compute for example. Before it wasn't used much esp in pc games. Now with gcn consoles these same devs are seeing the benefits on weaker than pc hardware. And that is transitioning to pc. I in no way said coding between the 2 were exactly the same, likely similar.
So talking about async isn't software, now its a hardware only thing? Its not even similar lol, that's the why I stated what I did..... Yeah its closer than it ever was before but still its still different from a programming point of view (optimization)
Who is misdirecting now?
Yeah if you want to make this personal, PM me, you might learn a thing or two instead of the same rhetoric that has been posted here for the past year and half by the same people over and over again.....
Who is misdirecting now?
Yeah if you want to make this personal, PM me, you might learn a thing or two instead of the same rhetoric that has been posted here for the past year and half by the same people over and over again.....
Last edited:
Hi, first time posting here. I came to HardOCP to look at benchmark numbers with VR but I chanced upon this conversation and felt I had to chime in.
Firstly, anyone who says that AMD benefits by having all the consoles and therefore will dominate on the PC is in for a rude shock. If you assume that it is that simple really, then be prepared for more releases like Batman Arkham Knight on the PC. Developing on the consoles and porting that to the PC requires a lot of work. Some development teams have to either divide themselves onto console teams and PC teams, or outright outsource the PC port to another company due to the lack of expertise. It is really not as trivial as people think it is. As I work in software testing and debugging, it's too common to see something work fine on the console and completely wrong on the PC. And I'm talking the same shader running on an AMD Radeon. Same GCN right?
Secondly, call me old but I am probably old enough to remember that DirectX was Microsoft's attempt at a thinner API to allow games developers to bypass the thick HAL on the Windows platform. But it is still a common API for everyone. With DirectX12, we seem to be going back to the metal and coding to a particular platform again. This smells almost like the old days of coding for Glide, Redline, etc, albeit under the grand name of DirectX12. I see it in my own development teams. With DirectX9/11, it is inherently harder to code for 1 particular hardware and the hardware vendors can tailor their drivers to optimize the shaders anyway. With DirectX12, it is becoming apparent that people will need AMD and Nvidia paths in their code.
I don't really want to get into this "AMD/Nvidia who is better" argument. However, in the DirectX11 world, it is very easy to fully utilize the Nvidia core. You will find that AMD's core tend to be underutilized a lot and to be able to better utilize the AMD core, you need to read their documentation(don't laugh!) and have their hardware in mind as you write your code. It's not like you don't have to code to Nvidia's hardware, you can really ruin AMD's day if you tailored your code to Nvidia's hardware but in general, there is a lesser need to because somehow some magic happens in the Nvidia driver and you don't have to do that extra work anyway. AMD's hardware has a serious load of untapped horsepower and it's really a case of software failing to use the hardware to AMD's disfavor.
Edit: I am aware this thread is more about Vulkan than DirectX12, but same shade of API really.
Firstly, anyone who says that AMD benefits by having all the consoles and therefore will dominate on the PC is in for a rude shock. If you assume that it is that simple really, then be prepared for more releases like Batman Arkham Knight on the PC. Developing on the consoles and porting that to the PC requires a lot of work. Some development teams have to either divide themselves onto console teams and PC teams, or outright outsource the PC port to another company due to the lack of expertise. It is really not as trivial as people think it is. As I work in software testing and debugging, it's too common to see something work fine on the console and completely wrong on the PC. And I'm talking the same shader running on an AMD Radeon. Same GCN right?
Secondly, call me old but I am probably old enough to remember that DirectX was Microsoft's attempt at a thinner API to allow games developers to bypass the thick HAL on the Windows platform. But it is still a common API for everyone. With DirectX12, we seem to be going back to the metal and coding to a particular platform again. This smells almost like the old days of coding for Glide, Redline, etc, albeit under the grand name of DirectX12. I see it in my own development teams. With DirectX9/11, it is inherently harder to code for 1 particular hardware and the hardware vendors can tailor their drivers to optimize the shaders anyway. With DirectX12, it is becoming apparent that people will need AMD and Nvidia paths in their code.
I don't really want to get into this "AMD/Nvidia who is better" argument. However, in the DirectX11 world, it is very easy to fully utilize the Nvidia core. You will find that AMD's core tend to be underutilized a lot and to be able to better utilize the AMD core, you need to read their documentation(don't laugh!) and have their hardware in mind as you write your code. It's not like you don't have to code to Nvidia's hardware, you can really ruin AMD's day if you tailored your code to Nvidia's hardware but in general, there is a lesser need to because somehow some magic happens in the Nvidia driver and you don't have to do that extra work anyway. AMD's hardware has a serious load of untapped horsepower and it's really a case of software failing to use the hardware to AMD's disfavor.
Edit: I am aware this thread is more about Vulkan than DirectX12, but same shade of API really.
skeeder
[H]ard|Gawd
- Joined
- Jul 9, 2004
- Messages
- 1,316
It almost seems the old days when AMD was pushing 64bit and X2's and Intel released the Extreme Pentium 4 single core. I feel like that is the current role with NVIDIA. Their graphic cards are fantastic and will be more utilized in gaming atmospheres, but AMD's will eventually catch up and NVIDIA will have to change (like Intel did) to bring in the new world of graphic processors. AMD keeps trying new things, but they are hugely limiting themselves. Most testers confirm that the RX480 does not overclock well. It's a brand new chip with hardly a ceiling above it. That's not good news for buyers or Third Party Manufactures who often use Overclocks to market cards. (this is at least on the reference boards, not sure about custom PCB's as of yet).
Has NVIDIA's pipeline really changed much since the 2006 launch of 8800 series?
Anarchist4000
[H]ard|Gawd
- Joined
- Jun 10, 2001
- Messages
- 1,659
So sharing code paths between console and PC for Doom isn't relevant? The upcoming release of SM 6.0 looks to be GCN-centric. I'm sure the goal there is unifying development between console and PC. I wouldn't call that insignificant, even if we aren't quite there yet.
I see the whole DX11 vs DX12/Vulkan argument as one between coding in java/python/C# and C/C++. Sure it takes more work, but generally faster and far more efficient. IMHO DX11 was also holding back development because of features that weren't practical. Consoles leveraging compute power of GPUs I feel will be a significant stepping stone to increase the complexity of current games. Physx being reliant on Cuda as opposed to DX/OGL would suggest that.
I don't work for the company that developed Doom, so I cannot comment on it.
However, as far as unifying development between consoles and PC are concerned, it really depends on how you define unified development. Right now, I still see specific console development teams and PC development teams. The console development teams will be trained with their specific target platform and their respective SDKs. There is some cooperation but they tend to be code that is not platform specific(ie PS4 or Xbone system APIs).
Some of these shareable code may be shaders but my experience says even right now shader code is not 100% shareable even though they are all GCN. In the past, there have been similar situations, like PS3 with the Nvidia GPU, but we sure as heck couldn't just copy&paste shader code wholesale into the PC port.
Now on the DX11 vs DX12 development, while it's fun to argue the advantages that DX12 bring us, the problem is right now there is very little library code developed in DX12. Very few developers have a large library base to work with at the moment. Nobody likes to invent the wheel twice. As it stands right now, game development budgets are increasing at an exponential rate and it is getting harder each day trying to meet the budget while delivering a stellar product.
And we can in essence come up with 2 types of DX12 code, one that is "we just render it right and done", the other being coding it specific to the 2 different platforms and getting the most efficiency out of the hardware. I assure you, unless you have a genuine top engineer in your development team, chances are most development teams are just going to render it right. And if that's the goal, DX11 has a vast library of software code waiting for us to use. I'm not saying developers are lazy, it's that we have so much work, so little time, so little budget, we have to compromise.
Those companies trailblazing with their DX12 attempts right now, they are doing the right thing or have the money to invest in the future. At the very least, they are building up their software library. For many companies, this is not a luxury they have.
By the way, anyone who thinks I'm in anyway disparaging either hardware vendor, think about this. If games development is so easy, or even the idea of unified development is easy, feel free to pick up the SDKs and have a go just building a little app for the 3 platforms. It may start easy, but as complexity grows and when you start to need to optimize for the platform, those dreams disappear.
It's crazily difficult trying to hire 3D engine developers, especially those who want to work in the games industry, and for damn good reason.
Yep... said that when Mantle was announced and some here were ready to burn me at the stake.
There are some nice improvements like better multithreading and DX11 was way behind OpenGL at the time of Mantle's announcement, but targeting specific architectures isn't going to end well. The industry could have addressed the specific deficiencies of DX11 without going full retard... but, here we are.
I don't deny that it requires a certain intelligence and skill set but part of the problem is that when you divide the hours worked into the salary received and adjust for the cost of living of the job site... let's just say that good software developers have far better opportunities out there.
Its always better to target optimizations for multiple platforms but the need to optimize for specific platforms will never disappear, maybe able to minimize it some, but console shelf life is long, much longer than typical GPU and CPU lifelines, and this is why it will never change. Consoles are limited to certain performance constraints, so for experienced dev's, to get the most out of the hardware they will do tricks or learned optimizations overtime. And this is an extension of what ChrisC is talking about with building their software libraries. AMD doesn't help console developers as much on Consoles as they do with PC, nV didn't do it either when they were in PS3.
This is the norm. First off the team to get access to the API and Dev Kits need a certain amount of experience just to be accepted into the console dev program. MS has less restrictions than Sony. So the team must be very experienced in making AAA games to begin with. Even at this point that specific team is focused on the console side of things only, to share resources (man hours or money) over two or more platforms, isn't very feasible with one team and this is why many PC ports are outsourced or come out later.
Anarchist4000
[H]ard|Gawd
- Joined
- Jun 10, 2001
- Messages
- 1,659
The shaders I'd say are definitely coming with SM6.0. In the case of Doom some of the intrinsics they used should be widely available under SM6. That at least saves devs from having to rewrite most of the effects. At for submitting jobs, DX12 and Vulkan are at least similar allowing the calls to be wrapped up between platforms. Even Apple's Metal should be roughly compatible. I know there was a Vulkan project over Metal that should have performed well. There are also tools for converting shaders between the various APIs.
True, but in the case of Doom they stated that the newer APIs actually make their asset pipeline easier. Yes they had to make some new tools, but once complete it was ultimately a time saver. These APIs are already used on consoles which constitute a large percentage of the games out there. Many of these workflows they have been using for years now. So while the PC gaming ecosystem might be lacking tools, they do exist and are improving. It sounds like we're less than a year away from exclusive DX12/Vulkan games being released. Once that shift occurs hopefully it makes development easier for everyone. All IHVs and developers seem to see the logic in this direction, even if it currently benefits some more than others. For developers that can't hire the best engineers, the current engines out there should be sufficient in addition to GPUOpen and Gameworks. I just wish Gameworks was a bit more open. Same could be said for Physx.
have ya ever tried using those tools? Better rewrite your shaders then use those tools
, code translation just isn't that good. If something isn't hard to do it probably isn't worth while doing lol.The PC ecosystem doesn't lack the tools to do anything that console ecosystem has. Its the time to shelf and the quick turn around time of PC components that change the landscape for PC much faster in development setting that makes it harder to do these things.
Its not the ability to hire the best, there is a limited pool of experienced developers to choose from.
Anarchist4000
[H]ard|Gawd
- Joined
- Jun 10, 2001
- Messages
- 1,659
Can't say I've had an overwhelming need to try converting HLSL to SPIR-V. My hope with SM6 would be shaders written for console actually compile for PC and can be submitted in a similar fashion. At least that way all the functionality can be wrapped up in a similar way.
The problem with your talking points is that you keep taking a baseball bat to the dead horse of terrible amd drivers, which is why I posed the hypothetical of your divinely gifted nvidia driver team with similar nvidia resources tackling the same optimization task for dx11 on gcn. Would they have been able to get gcn performing as well as it does in frostbite 3 in an engine like UE3/UE4?
I don't think so. And if that's the case then SOME of the differential performance we are seeing is related to hardware design and the intrinsic capacity of apis to extract performance.
It might be that engines could have been constructed to get around many of the constraints of dx11, like frostbite 3 did because they are competent devs, but most engines behave more like UE/UE4.
UE devs: Does it perform well on nvidia? K, we're Done!
Frostbite devs : Does it perform well on all hardware? No? Then get back to work.
To those who just use nvidia and don't care, take note that the latter design attitude leads to releases with performance like doom in vulkan, star wars battlefront in dx11, and less like AC unity, Batman Arkham where performance is a total shit show. Higher on Nvidia? Sure, but still terrible, Lord of the flies, congratulations.
This has definitely been a major problem for amd, frostbite only handles EA games, which does have two large rpg franchises I am into along with popular shooters, but third parties can't leverage that engine.
The landscape for smaller less experienced devs seems to be to go UE4, likely due to more hand holding by the engine guys, but there are signs of upcoming games breaking away from such reliance.
ashes was based on the nitrous engine
hitman was based on glacier 2 which works well for amd cards
deus ex mankind divided is apparently based on the dawn engine, which is a heavily modified glacier 2 engine, so that will probably perform well on amd cards as well as nvidia
The shift to more dx12 seems to be bringing a bit more of a shift away from the (does it run well on nvidia? k we're done) engine UE4, but the demarcation seems to be triple A titles vs smaller games. The biggest I know of on UE4 seems to be gears of war, but most of the other big titles are on other engines, wrong?
Hopefully cdpr jumps onto a more modern engine, and hell, maybe UE will actually start giving a damn about more than just their nvidia performance (not holding my breath).
Of the major 3rd party engines:
UE4
Unity 5
CRYENGINE
I'm not sure if any of them have put in the same sorts of work to make sure that gcn runs as smoothly as it does on engines like frostbite 3 and some of the new dx12 focused engines. And even then, I'm not sure where the onus on the engine devs ends, and the game devs begins that are using the engine.
But I'm sure Razor does. AMD inferior drivers / inferior hardware is the only place to look.
I'm not a game dev obviously, but I'm sure the fact that the memory on consoles is shared between the gpu/cpu allows for much different behaviors relating to how to handle where resources are stored and how much copying is required between gpu and system memory on pcs.
Which is why...
We need some way to get some advanced optical interconnects to allow both the gpu/cpu in pcs to access a larger low latency pool of memory. This may be impossible unless it's all sold on the same package, but if it's not impossible, it needs to be looked into.
I do know much more about engines and these engines you are talking about, and I wouldn't place Frostbyte at the level of UE4 let alone even CryEngine. Its tools aren't as good as either of those two engines. Unity, never been a fan of, even though its tools are great, I don't like how they lock in their subscribers and their payment plans.
I have been using UE4 for my project and have used Cry Engine in previous projects and have used Unity as well for demoing a sample project. I have had exposure to Frostbyte not at the level as UE4 or Cry Engine, but I can tell you it was no where near at the level of UE4 or Cry Engine when I did test it out, that was close to 8 months back. Lets not even get into Oxide's failed attempt at making a good game engine, its engine is only good for one type of game for now, RTS's. You can't compare them to any of the engines we are talking about here.
PS Square Enix is making quite a few games on UE4
just fyi, so I suggest looking stuff like that up first....... easy to find.As much as you want to deny it, AMD did have inferior DX11 drivers when looking at driver overhead (not stability), complaints are well documented over the internet about their DX11 driver overhead for close to a year or a year and half now. There is and was no way AMD didn't see this problem coming. And right now AMD is way behind in power consumption for the performance you get, its not even close its like 30% difference? The same gap that we saw with Maxwell 2 with GCN 1.1 and 1.2?
I'm sorry its 69% at higher resolutions, so its worse......
Last edited:
hmm that isn't where the changes would be. Those are things that are done automatically at driver level, and developers just have to be aware of limitations and where they spend their computing and memory resources to avoid that, this is actually quite similar to your IGP.
Last edited:
I do know much more about engines and these engines you are talking about, and I wouldn't place Frostbyte at the level of UE4 let alone even CryEngine. Its tools aren't as good as either of those two engines. Unity, never been a fan of, even though its tools are great, I don't like how they lock in their subscribers and their payment plans.
I have been using UE4 for my project and have used Cry Engine in previous projects and have used Unity as well for demoing a sample project. I have had exposure to Frostbyte not at the level as UE4 or Cry Engine, but I can tell you it was no where near at the level of UE4 or Cry Engine when I did test it out, that was close to 8 months back. Lets not even get into Oxide's failed attempt at making a good game engine, its engine is only good for one type of game for now, RTS's. You can't compare them to any of the engines we are talking about here.
PS Square Enix is making quite a few games on UE4
As much as you want to deny it, AMD did have inferior DX11 drivers when looking at driver overhead (not stability), complaints are well documented over the internet about their DX11 driver overhead for close to a year or a year and half now. There is and was no way AMD didn't see this problem coming. And right now AMD is way behind in power consumption for the performance you get, its not even close its like 30% difference? The same gap that we saw with Maxwell 2 with GCN 1.1 and 1.2?
I'm sorry its 69% at higher resolutions, so its worse......
Frostbyte is nowhere near the level of UE4/Cryengine in what way? Support and documentation? Advanced rendering? Performance? On the last performance on nvidia only is all some may care about but I consider that a failure.
It would actually be interesting to read/listen to someone who has deep and up to date knowledge of all of these engines, and perhaps the new upstarts too to talk about the strengths and weakness of them and what they are working to improve on. But such a person probably does not exist or is as rare as a unicorn, or worse, muzzled from speaking openly about the internal workings of such things.
I stated it, Its tool set.
Tools is what sells engines, not their raw performance or visual fidelity (Raw performance matters as does visual fidelity but either of these can be achieved if they need it at a later date). This is why UE3 did so well over Idtech and Cry Engine 1. Both both the later were better visually and even capabilities of their needs.
Actually a good example of how long it takes developers to create good low level code for engines for consoles, is Crysis and Cry Engine 2 and 3. Why do you think Crysis was never released for consoles till Cry Engine 3 came out? Cry Engine 2 and 3 don't have that many visual differences if you look at from broad overstrokes, but if you look at what Crytek did for consoles, they had to learn all that after Cry Engine 2 was done and they were able to get dev kits.
Tools is what sells engines, not their raw performance or visual fidelity (Raw performance matters as does visual fidelity but either of these can be achieved if they need it at a later date). This is why UE3 did so well over Idtech and Cry Engine 1. Both both the later were better visually and even capabilities of their needs.
Actually a good example of how long it takes developers to create good low level code for engines for consoles, is Crysis and Cry Engine 2 and 3. Why do you think Crysis was never released for consoles till Cry Engine 3 came out? Cry Engine 2 and 3 don't have that many visual differences if you look at from broad overstrokes, but if you look at what Crytek did for consoles, they had to learn all that after Cry Engine 2 was done and they were able to get dev kits.
Did you work for an EA studio?