Battlefield 1 Open Beta is live and supports DX12

[Carfax83]

What are you talking about really? narrower? wider? deeper? huh? The 1080 clocks high enough to be faster, end of story.

So you're implying that clock speed is the only factor why the GTX 1080 wins, in a game that uses an engine designed to be as parallel as possible?

Right. I'm not a GPU designer, and neither are you, but I'm pretty sure that clock speed isn't the main reason why the GTX 1080 is whooping the R9 FuryX in Ashes of the Singularity.

 

[Azix]

So you're implying that clock speed is the only factor why the GTX 1080 wins, in a game that uses an engine designed to be as parallel as possible?

Right. I'm not a GPU designer, and neither are you, but I'm pretty sure that clock speed isn't the main reason why the GTX 1080 is whooping the R9 FuryX in Ashes of the Singularity.

what do you mean by parallel? There is no async compute in dx11, so you must mean something else. GPUs always do work in parallel on the thousands of cores. GPU performance is very dependent on clock speed. Its either more cores or more clock speed. I don't see a problem with a 1080 that reaches up to 10 teraflops at 2Ghz beating a 8.9 teraflops fury x even in dx12,.

 

[Carfax83]

what do you mean by parallel? There is no async compute in dx11, so you must mean something else.

I'm talking about AotS in DX12 mode which does make heavy use of asynchronous compute.

GPUs always do work in parallel on the thousands of cores. GPU performance is very dependent on clock speed. Its either more cores or more clock speed. I don't see a problem with a 1080 that reaches up to 10 teraflops at 2Ghz beating a 8.9 teraflops fury x even in dx12,.

Higher clock speeds are of more help in serial workloads, which is why CPU cores run at much higher frequencies than GPU cores. Parallel workloads benefit the most from more execution units..

Anyway, if you saw who I was originally quoting, then you'd understand why I said what I said. The person I originally quoted implied that since NVidia have engineered their GPUs primarily for a serial API (aka DX11), then Battlefield 1's DX12 implementation was put on the backburner which hurt AMD GPUs in the end.

But of course GPUs are by their nature, as well as by necessity highly parallel devices so implying that NVidia hardware designs are somehow more serial than AMDs is ridiculous..

 

[Shmee]

Guys, lets not make this into an AMD vs Nvidia thread plz. Stay on topic, and be civil.

 

[DamZe]

So bad my old HD5850 just died, i could have gived it a try.

Trust me it's better that way the HD5000 series is pre GCN (TeraScale), so it would perform like complete garbage in this title.

 

[IEC]

Game runs great on my Fury @ 3440x1440 75Hz

 

[Headfoot]

If you test with an overpowered CPU Dx12 will always be slower then dx11 and because of the splitting up of the work it adds an element of synchronization where things could go wrong and produce more stutter.

100% false. Where are you coming up with this crap? Of course there is synchronization overhead ... which also exists in multithreaded DX11 games just with the added benefit of even more overhead. But you do realize that splitting work to many worker units (e.g. threads) increases total throughput and thus makes it go faster as long as the overhead doesn't exceed the capacity added. Which it doesn't because DX12 reduces overhead compared to dx11...

How about folks who've never programmed at all, much less in both high and low level languages, stop trying to comment on what exactly is different between dx11 and 12.

 

[2is]

100% false. Where are you coming up with this crap? Of course there is synchronization overhead ... which also exists in multithreaded DX11 games just with the added benefit of even more overhead. But you do realize that splitting work to many worker units (e.g. threads) increases total throughput and thus makes it go faster as long as the overhead doesn't exceed the capacity added. Which it doesn't because DX12 reduces overhead compared to dx11...

How about folks who've never programmed at all, much less in both high and low level languages, stop trying to comment on what exactly is different between dx11 and 12.

Do you just chime in with "100% false" anytime you read something you may not agree with? It doesn't sound like you have any actual counter argument.

 

[Headfoot]

Do you just chime in with "100% false" anytime you read something you may not agree with? It doesn't sound like you have any actual counter argument.

I chime in with 100% false when people make totally unsubstantiated claims that are outright, factually wrong. Read his claim and come to your own conclusion.

What he wrote was not an opinion but an assertion of fact, which is incorrect.

Or do you actually believe that dx12 WILL ALWAYS be slower than dx11 as he claimed?

My "argument" is right there if you'd bother to take the time to read it.

Of course there is synchronization overhead ... which also exists in multithreaded DX11 games just with the added benefit of even more overhead. But you do realize that splitting work to many worker units (e.g. threads) increases total throughput and thus makes it go faster as long as the overhead doesn't exceed the capacity added. Which it doesn't because DX12 reduces overhead compared to dx11...

You know, in the third of 5 total sentences...

And it's not an argument. It's a statement of the facts of parallel programming known as Amdahls law (posited in the reverse but the same law nonetheless)

 

[2is]

I chime in with 100% false when people make totally unsubstantiated claims that are outright, factually wrong. Read his claim and come to your own conclusion.

What he wrote was not an opinion but an assertion of fact, which is incorrect.

Or do you actually believe that dx12 WILL ALWAYS be slower than dx11 as he claimed?

My "argument" is right there if you'd bother to take the time to read it.


You know, in the third of 5 total sentences...

And it's not an argument. It's a statement of the facts of parallel programming known as Amdahls law (posited in the reverse but the same law nonetheless)

How do you know it's 100% false? He didn't claim that DX12 will always be slower. You just have a reading comprehension issue. Read it again, if that's what you still think he said, read it yet again. Repeat this process until you figure out what he actually said. You didn't offer up an explanation, you said "dx11 needs to sync too" he went into far more detail which seems like you have no where near the knowledge to refute in any way shape or form other then to say "100% false" because for some reason, you just didn't like what you heard.

 

[Headfoot]

He didn't claim that DX12 will always be slower.

If you test with an overpowered CPU Dx12 will always be slower then dx11 and because of the splitting up of the work it adds an element of synchronization where things could go wrong and produce more stutter.

API overhead does not change based on the speed of a CPU. Whether it is a bottleneck or not may, but that is a totally distinct issue.

Do you say C is slow because somebody wrote a slow program in C?

 

[Headfoot]

And since apparently this must be spelled out (and do try and actually read every word this time)

You must compare like to like. You can't say DX12 adds multithreading synchronization over head. No. It doesn't. MULTITHREADING adds multithreading overhead. You can write a single threaded app in DX12 if you want to.

If you have a program with 2 threads in DX11 and a program with 2 threads in DX12, assuming all else is equal, DX12 will NOT always be slower. Multithreaded synchronization MUST HAPPEN in both cases. It's a matter of which code is more efficient: the handwritten code in DX12 or the compiler/api generated code in DX11.

I've written parallel code before. Have you?

 

[2is]

API overhead does not change based on the speed of a CPU. Whether it is a bottleneck or not may, but that is a totally distinct issue.

Do you say C is slow because somebody wrote a slow program in C?

The part before the bolded part which you ignored, changes it a lot. Sounds like you don't know enough to really argue the point. Anytime I see someone quote partial sentences like you just did, that's the reason "100%" of the time. What exactly did you think you would accomplish by bolding the part you want to cherry pick? Did you think I would ignore the part that came before it like you did?

Looks like it's time for you to read it again, because you still haven't figured out what he said. He didn't say API overhead changes based on speed. He explained how the work is divided in DX11 vs DX12 and how having a powerful CPU can actually benefit DX11 more then DX12 based on how the work is divided.

Now I don't know enough to say if that's true or not true, and it appears like you don't either. But I understood what he was saying and didn't take it out of context.

 

[SPBHM]

Trust me it's better that way the HD5000 series is pre GCN (TeraScale), so it would perform like complete garbage in this title.

having tested the game with an HD 5850 @ 925MHz IMO the biggest problem is lack of support, not performance.
the game achieves decent framerates using low settings (and still manages to look ok), but, the game requires a driver version to launch which doesn't support the legacy cards, so you have to start by editing registries to fool the game about the driver version, and on my card I get some visual glitches similar to what I got on Battlefront (but didn't on Hardline and older DICE games), some weird squares (which I couldn't capture on screenshots), not sure what's going on but the card runs fine on other games (and it's nothing to do with OC I tested it).

if the card was supported it would probably run even better, not have the bug and need to edit the registry, oh well, I can't complain, it's really an old card, but, at the end of the day it's a DX11 card and a DX11 game, nothing absurd to expect it to work, even if it's 7 years old (which is pretty amazing to be honest, time flies...)

 

[Headfoot]

The part before the bolded part which you ignored, changes it a lot. Sounds like you don't know enough to really argue the point. Anytime I see someone quote partial sentences like you just did, that's the reason "100%" of the time. What exactly did you think you would accomplish by bolding the part you want to cherry pick? Did you think I would ignore the part that came before it like you did?

Looks like it's time for you to read it again, because you still haven't figured out what he said. He didn't say API overhead changes based on speed. He explained how the work is divided in DX11 vs DX12 and how having a powerful CPU can actually benefit DX11 more then DX12 based on how the work is divided.

Now I don't know enough to say if that's true or not true, and it appears like you don't either. But I understood what he was saying and didn't take it out of context.

Dude what is so hard about this? THE DX12 API IS NOT SLOWER THAN THE DX11 API, PERIOD - that is the design goal. A powerful CPU DOES NOT CHANGE THE API OVERHEAD. If we are talking about how fast an API is, OVERHEAD IS THE MEASUREMENT. Ergo how fast the CPU only matters when considering something else entirely - e.g. whether an entire code base is bottlenecked by the CPU

Please read this:
Multi-threading overhead is not caused by DX12.

Stop. Re-read the last sentence.

Multi-threading overhead exists in every program that is multithreaded, regardless of API, programming language, etc

 

[Spjut]

having tested the game with an HD 5850 @ 925MHz IMO the biggest problem is lack of support, not performance.
the game achieves decent framerates using low settings (and still manages to look ok), but, the game requires a driver version to launch which doesn't support the legacy cards, so you have to start by editing registries to fool the game about the driver version, and on my card I get some visual glitches similar to what I got on Battlefront (but didn't on Hardline and older DICE games), some weird squares (which I couldn't capture on screenshots), not sure what's going on but the card runs fine on other games (and it's nothing to do with OC I tested it).

if the card was supported it would probably run even better, not have the bug and need to edit the registry, oh well, I can't complain, it's really an old card, but, at the end of the day it's a DX11 card and a DX11 game, nothing absurd to expect it to work, even if it's 7 years old (which is pretty amazing to be honest, time flies...)

I saw one guy on Sweclockers saying he could run it up to 80 FPS on his GTX 570, which also isn't officially supported by the game. Still supported by Nvidia though.

The game seems to be well optimized for all architectures. It's very nice to see that Kepler seems to perform close to its GCN and Maxwell counterparts, whereas it has fallen behind in other recent games.

 

[Face2Face]

Intel HD in the house...

https://www.youtube.com/watch?v=lTO6GvhC16o

 

[TheELF]

100% false. Where are you coming up with this crap?

How do I?
I didn't!
AMD came up with this crap,the folks that created MANTLE which then became Dx12.
In case you missed the giant pictures previously,here they are again,together with a few highlights.

• In dx11 the driver is high level meaning it is a separate thread that,if you have enough cores,will not influence any other thread and,if your cores are fast enough,will drive any GPU without bottleneck.
• In dx12 the driver is low level meaning it becomes part of every thread,this means that the low level driver will always influence every other thread.
• Since the main thread (game code) determines the FPS and since with dx12 it will have to run the additional low level stuff within the main thread it will be slower.

Again, because you seem not to read very carefully, only if you have enough cores and only if your cores are fast enough.
http://www.tekgrains.com/best-features-directx-12-vulkan-explained/

 

[Bacon1]

• In dx12 the driver is low level meaning it becomes part of every thread,this means that the low level driver will always influence every other thread.

• Since the main thread (game code) determines the FPS and since with dx12 it will have to run the additional low level stuff within the main thread it will be slower.

Here is what the actual post with those images says:

In addition to modest multi-threading in DirectX® 11, a disproportionate amount of CPU time is frequently spent on driver and API interpretation (“overhead”) under the DirectX® 11 programming model, which leaves lesser time for executing game code that delivers quality and framerates.



In DirectX® 12, however, the command buffer behavior is radically overhauled in five key ways:

1. Overhead is significantly reduced by moving driver and API code to any available CPU thread
2. The absolute time required to complete complex CPU tasks is notably reduced
3. Game workloads can be meaningfully distributed across >4 CPU cores
4. New “bandwidth” on the CPU allows for higher peak draw calls, enabling more detailed and immersive game worlds
5. All available CPU cores may now “talk” to the graphics card simultaneously

Much like going from a two-lane country road to an eight-lane superhighway, the shift to DirectX® 12 allows more traffic from an AMD FX processor to reach the graphics card in a shorter amount of time. The end result: more performance, better image quality, reduced latency, or a blend of all three (as the developer chooses).

https://community.amd.com/community/gaming/blog/2015/05/12/major-new-features-of-directx-12

 

[Hitman928]

How do I?
I didn't!
AMD came up with this crap,the folks that created MANTLE which then became Dx12.
In case you missed the giant pictures previously,here they are again,together with a few highlights.

• In dx11 the driver is high level meaning it is a separate thread that,if you have enough cores,will not influence any other thread and,if your cores are fast enough,will drive any GPU without bottleneck.
• In dx12 the driver is low level meaning it becomes part of every thread,this means that the low level driver will always influence every other thread.
• Since the main thread (game code) determines the FPS and since with dx12 it will have to run the additional low level stuff within the main thread it will be slower.

Again, because you seem not to read very carefully, only if you have enough cores and only if your cores are fast enough.
http://www.tekgrains.com/best-features-directx-12-vulkan-explained/

What you're saying makes no sense. Being high level versus low level does not mean what you think it means. There is nothing stopping DX12 code/driver/api from being "isolated" to a single thread and this is NOT an advantage. You do realize in the above pictures that core 1 is the main thread and that the longer the bars the worse the performance, right? If everything is running on the main thread and not distributed, you get worse performance. Yes, if your cores are fast enough, you can mitigate the advantage of going low level and distributing the work, but even with the fastest CPUs this has a limit, which is what the API draw call tests are all about. If a developer wanted to, they could destroy any cpu in DX11 with draw calls and keep it smooth in DX12 on much inferior hardware but needing that many draw calls isn't very realistic right now and no developer would do that as they need their games to still run well on DX11 hardware for at least a few years yet while people slowly transition over to capable GPUs.

 

[AtenRa]

• Since the main thread (game code) determines the FPS and since with dx12 it will have to run the additional low level stuff within the main thread it will be slower.

Ehm no,

what is the additional low level stuff ??

 

[TheELF]

Here is what the actual post with those images says:



https://community.amd.com/community/gaming/blog/2015/05/12/major-new-features-of-directx-12

It says the exact same thing I am saying.

Overhead is significantly reduced by moving driver and API code to any available CPU thread

Any available CPU thread equals all game code threads,which does include the main thread,the main thread now has to run the game code + api/driver stuff which means that it has to sacrifice game code execution time.

 

[TheELF]

What you're saying makes no sense. Being high level versus low level does not mean what you think it means. There is nothing stopping DX12 code/driver/api from being "isolated" to a single thread and this is NOT an advantage. You do realize in the above pictures that core 1 is the main thread and that the longer the bars the worse the performance, right?

I don't know if there is anything stopping it from happening but any article and any game until now shows that it's not "isolated" but becomes part of the (rest of the) threads.

Yes on draw calls I do agree and that's a basic limitation of dx11,but even on ashes that is overloaded with draw calls there's no real benefit to dx12 on fast machines with fast GPUs.

 

[TheELF]

Ehm no,

what is the additional low level stuff ??

It's additional to the game code,it might be less work in total than dx11 and spread over more threads but instead of having one core run only the main game code thread now it also has to run some of the api/driver stuff.

 

[Bacon1]

Any available CPU thread equals all game code threads,which does include the main thread,the main thread now has to run the game code + api/driver stuff which means that it has to sacrifice game code execution time.

What? It was already executing on the main thread, now it can be easily moved off into other threads in DX12.

Look at the red and blue lines, instead of being stuck on the main core with the bulk of the game code, they are moved to the other cores as well.