Like I said magic, you haven't done any DX programming so you really have no clue about what you are talking about.
Which is why it should have an LOD system.
Object so far away, its simply at dot = 1 draw call (assumption need someone with more experience to confirm),
Multiple identical objects= batched draw call,
Objects so far away = forget about motion blur.
It looks like oxide is running the same draws on each object despite them being identical objects that are very far away (like independently revolving turrets on a dot). Also objects seem to be rendered, even if they are occluded by an explosion.
Like I said magic, you haven't done any DX programming so you really have no clue about what you are talking about.
BF4 is. Repi's tweet says they are supporting it. Repi's slides say the only major roadblock is "performant drivers". Nvidia had the "performant" drivers problem solved since driver release 270, as shown by the sudden and confusing massive Civ V FPS improvement.
I find it sad that so many here think that developers trying to sell a platform will tell them the whole truth.
Hi everyone
There has been some confusion about Star Swarm, Mantle, performance on various hardware, and other topics that wed like to clear up. Here are the best answers we can give to some of the most common questions and complaints weve seen since Star Swarm launched to the public yesterday:
Q. Where is the Mantle support you promised?
A. AMD has delayed the Mantle driver beta release to an unspecified date. As soon as it comes out, you can download it from AMD here: http://support.amd.com/en-us/kb-articles/Pages/latest-catalyst-windows-beta.aspx. Mantle support is built into Star Swarm, so the demo is ready to go as soon as the driver is available.
Q. Whats with registration for a free demo?
A. Weve heard the complaints about the registration process and have decided to strip out the activation process. A new build of Star Swarm will be uploaded to Steam shortly, or very possibly will already be available by the time this message is published.
Q. Why are you calling this a benchmark? I get different results every time I run it.
A: Star Swarm is designed as a total game engine test, not just a graphics test. As such, we have complete AI, flocking, physics, etc. being simulated instead of a pre-canned demo. We believe this adds an important real-world component, and any data gathered from the stress test displays a true game result.
In addition, adding completely deterministic behavior to any engine will create artificial results and stress points, which is something we feel is important to avoid.
However, we are putting together a guide for people interested in getting more consistent numbers. Stay tuned. In the meantime, use the Follow scenario for benchmarking purposes the Attract scenario was built to provide random views of the battle.
Q. This is just a marketing tool for AMD; youve obviously crippled the DirectX version!
A. We really havent; to be perfectly honest weve spent more time optimizing for DirectX than we have on Mantle. The fact is that DirectX is conceived and implemented as a single-threaded API, and so a lot of the more significant gains we see thanks to the Nitrous engines aggressive multithreading are badly limited by API overhead when were using it.
We obviously cant prove this to the satisfaction of everyone on the Internet, but understand that our primary goal with Nitrous is to make the best engine we can so that we can open the door to the new kinds of games that we want to make (and play ourselves!). An awful lot of the gamers we hope to entertain dont and wont have access to Mantle-enabled hardware any time soon, so wed be making a huge mistake as entertainers and as businesspeople by not supporting or poorly supporting non-Mantle hardware.
Q. Why is my CPU usage imbalanced when running Star Swarm on DirectX?
A. One of the issues we are trying to help Microsoft and their partners with DirectX work on is the serial nature of the DirectX API. The imbalance you are noticing is directly related to this issue. When running an API such as Mantle, which is designed to allow scalability across multiple cores, this issue will disappear. For a more in-depth answer, please see Oxides APU 13 presentation regarding this subject: http://www.youtube.com/watch?v=QIWyf8Hyjbg
Q. Why is my GPU utilization not at 100% on DirectX?
A. DirectX and the driver are responsible for interpreting the graphics input from the application and converting that to commands that the GPU can process. Under the current DirectX API, this can be a very CPU-intensive process. If the CPU cannot generate commands faster than the card can process them, then your GPU will not be fully utilized. For a more in-depth answer, please see Oxides APU 13 presentation regarding this subject: http://www.youtube.com/watch?v=QIWyf8Hyjbg
Q. Are games using Nitrous going to have the same DirectX performance as Star Swarm?
A. No. We are working closely with all partners involved with DirectX to improve its performance going forward. Star Swarm is intended as a stress test, to ensure that games built on Nitrous will have an opportunity to efficiently use all the hardware available and not be artificially limited by the platform it is running on. In addition, all games will tailor their graphics settings to allow for optimal performance on each platform. Since Star Swarm is a stress test, it makes no distinction between DirectX and other platforms.
Q. Is Star Swarm unfairly targeting DirectX?
A. No. In fact our performance under DirectX is quite good. With a high-end CPU with excellent single-core performance and a high-end GPU, Nitrous can push up to 30,000 batches at 30 frames per second. We believe this number to be quite competitive with any other engine out there. We have also made additional optimizations specific to the DirectX version which are not required on other platforms.
Q. What about deferred contexts? Dont those help multithreaded applications in DirectX?
A. Until the very latest drivers, we saw equal or even worse performance using deferred contexts in Nitrous. The newest drivers, however, have seen performance gains and so the latest build of Star Swarm can be set to use deferred contexts. Users can enable deferred contexts by modifying the line EnableDeferredContexts=FALSE to =TRUE in their settings files (for more information on customizing settings, see the link below). We have seen some stability issues with deferred contexts enabled, so change the setting at your own risk.
Q. How can I customize Star Swarm with different settings?
A. See this post.
You are welcome to look at one of repi's twitters from two days ago, where he states that it is "fundamentally broken". That sounds like a far range from your claim about Nvidia solving it since the 270 drivers (which also were available before the release of BF3)
Repi could withhold parts of the truth, but his claim is further strengthened by the absence of DX11 games using multithreaded rendering.
Added DeferredContexts flag to ini files (disabled by default - use at your own risk)
Metro LL, Civ V, BF4, Crysis 3, and AC3 (this one didn't need it lol) come to mind immediately. Why would a rushed console port need DX11 CL in the first place?
Like I said magic, you haven't done any DX programming so you really have no clue about what you are talking about.
Actual graphics programmers however, the guys who make their living making the engines, apparently do think a better solution is needed, and a few of them are even prepared to support a whole different API.
Are these identical runs? The variation is massive.Average FPS: 29.91
Second Run
Average FPS: 35.83
Third Run
Average FPS: 33.46
Fourth Run
Average FPS: 46.16
Fifth Run
Average FPS: 28.30
Yes. The benchmark is dynamic, so I don't think you can get fully reproducible results.
I did see that a forum poster over there managed to get between roughly 13.58 and 32.16 Average FPS depending on the settings. His system:Frogboy
Sent Yesterday, 11:58 AM
I think some of them are not understanding the point of a stress test benchmark. If a 2014 stress test didn't push their hardware, what would be the point? It would be like people complaining about a 2003 stress test because the app used a lot of lighting and shadows, features that weren't common back then, and saying it shouldn't try to use those features.
The assets do have LOD and such in them. The reason it's slow on DirectX is because, by default, it has per-object motion blur (it's not a post processor effect like you get in a typical FPS). So it's literally rendering every object off-screen many times in order to create a more realistic scene.
AMD is scheduled to release Mantle imminently and what it brings to the table (and for us, it's the main thing) is that its platform is very multi-core friendly. The reason (and the main reason) Star Swarm demo is slow on DirectX is because even DirectX 11 isn't very good in dealing with a multi-core engine.
Now, on the games that are using Nitrous, those games are very aware of what the installed base has on them and as a result optimize their experience for that user base. But that's not what Star Swarm is supposed to do. It's *supposed* to hammer the user's system so that they can see, especially over time as Nvidia, Intel (and of course AMD's Mantle) improve their multi-core rendering support.
The goal here, imo, is that someone running Star Swarm today should go "eGads, that's slow!" and yet a year from now, when the drivers (not the hardware but the software that controls the hardware) are improved you'll be able to run the same demo and see a big benefit.
You can repost this, I won't have time to head over there.
Are these identical runs? The variation is massive.
DX is not messed up. How could anyone with any sense make a comment like that, when PC games have never looked or performed better!?
We have the Witcher 3, a game that will feature no loading screens at all, and have no chapters. It's completely open World from beginning to end.
And it's DX11 native. A game like that would not even be possible on DX9 without serious sacrifices. And your precious Mantle uses HLSL, a DX11 feature to work btw..
Right, almost 50% is "minimal." But when Mantle claims 45% improvement it's all of a sudden spectacular!
You're way behind the times there dude. Mantle aside, after multiple patch and driver updates, BF4 does not work better on AMD hardware. It actually runs faster on NVidia, especially in multiplayer where the CPU plays a bigger role in performance.
Read the latest reviews at GameGPU, HardOCP, PClabs.pl or any website that reviews using MP, and you'll see that NVidia now has the lead.
You can think what you like, but Project CARS has tons of youtube channels devoted to it. Also, it's the biggest multiplatform racing game for next gen, that alone will make it a success.
The problem with DX11 multithreading, is that it's performance is wholly contingent on the drivers. It's the drivers that are responsible for deferred context thread creation and recording to the command list for upload to the immediate context..
Thing is though, this is a mammoth undertaking to implement. It took NVidia almost 2 years I think to finally implement it (and they're still refining it), and AMD still hasn't done so yet.
As the drivers improve, so will the DX11 multithreading performance. That link I posted on the previous page showed a GTX 660 getting roughly 55% faster frame rates than a 7850 in Project CARS, a game that uses driver command lists:
GTX 660 vs 7850 in Project CARS
55% is very significant. AC III used it as well, but the gains were less as the game isn't very CPU bound. But still, it allows NVidia to edge out AMD in that title:
These are GPU limited settings, but the most CPU limited card, the Gigabyte GTX 780 Ti GHz is 28% faster than the Asus 290x DirectCU II.
You might want to read up and or watch the interviews with the Oxide devs on what their goals were with their engine, how its engineered, and what is actually going on that you are looking at.
The short is that they were going for a render engine that is exactly like what Hollywood uses in movies only it's real time. Everything on the screen is an independent entity with full physics and AI were applicable.
http://forums.anandtech.com/showthread.php?t=2361756
https://www.youtube.com/watch?v=VC8RWntPRvI
Oh come on now...
I think the writing is on the wall at this point.
Repi said yesterday that DCL is fundamentally broken in DX.
Yesterday.
== Results ================================================
Test Duration: 99 Seconds
Total Frames: 6072
Average FPS: 60.76
Average Unit Count: 3636
Maximum Unit Count: 5400
Average Batches/MS: 746.74
Maximum Batches/MS: 2130.22
Average Batch Count: 14166
Maximum Batch Count: 79900Test Duration: 99 Seconds
Total Frames: 3237
Average FPS: 32.41
Average Unit Count: 3703
Maximum Unit Count: 5345
Average Batches/MS: 739.74
Maximum Batches/MS: 1500.26
Average Batch Count: 28048
Maximum Batch Count: 151054Test Duration: 360 Seconds
Total Frames: 15948
Average FPS: 44.30
Average Unit Count: 4418
Maximum Unit Count: 5952
Average Batches/MS: 838.57
Maximum Batches/MS: 4511.59
Average Batch Count: 20080
Maximum Batch Count: 132196Test Duration: 360 Seconds
Total Frames: 12145
Average FPS: 33.73
Average Unit Count: 4065
Maximum Unit Count: 5383
Average Batches/MS: 614.70
Maximum Batches/MS: 1786.21
Average Batch Count: 19289
Maximum Batch Count: 114370You post a thread with the title "Flaws on Oxide" - (And i guess you mean "Star Swarm" that is the engine, not Oxide that is the name of the company)
Yet you dont know the most basic about this test and engine, as this question shows. Next time take some time to try to understand and read about the subject, or post it as questions.
Since you apparently know the basics about this test and engine, please explain why their "revolutionary" engine has inferior CPU utilization compared to CryEngine 3, Civ5, 4A Engine, and Frostbite 3 in CPU-bound situations. Hey look, they all use deferred context, token+replay, or command lists to make their engine efficient.
Edit:
How did you guys get DC working?