Oxide: Star Swarm benchmark to be released on Steam this month!

[DaZeeMan]

Join Date: Nov 2010 Posts: 1,835 Default I want to see how this engine stacks up against another proper DX11 engine like Firaxis's Lore Engine, which can do 15 to 20K draw calls in a frame with DX11 multithreading.

Firaxis has several seats at the table with Oxide. Dan Baker, Mark Meyer, and Brian Wade are all Firaxis alums. Tim Kipp has worked with Firaxis on Civ 5 as well.
http://www.oxidegames.com/about

So I'd imagine that Nitrous performance will easily be on par with, or more likely significantly exceed, the Lore Engine's capabilities. Of course, we will all just have to wait for the Star Swarm benchmark to be released, hopefully sometme later this month as Brad teased, before we can draw any practical comparisons.

Are there any Lore Engine benchmark demos that aren't directly Civ related? It'd be nice to have that handy for side by side comparisons.

The comment I found more interesting was Brad mentioning Oxide far exceeding the engine Stardock has built for GalCivIII (which is essentially at the early alpha stage at this point). That is a telling remark in of itself, as the GalCivIII engine is designed to take advantage of DX11 multithreading, and also 64 bit computing exclusively. We've been told on the Stardock forums that GalCivIII will be 64 bit only...

And yeah, benchmark performance isn't the same as in game performance, so I'll be interested to see which titles sign on with Oxide/Nitrous. We are many months away from a Nitrous game release, based on Brad's comments.

 

[krumme]

The central pieces to understand the new oxide engine is here:

Oxide presentation at apu13
http://www.youtube.com/watch?v=QIWyf8Hyjbg

Q&A with oxide at apu13
http://www.youtube.com/watch?v=sSY2KXBoro0

And from another developer perspective
Johan Andersson (DICE), presentation of FB3 and bf4 at apu13
http://www.youtube.com/watch?v=tDPgJB2x7dQ

 

[Imouto]

Now, now. Are you trying to circumvent the closure of the Mantle thread?

 

[Silverforce11]

Seriously people stop rehashing the same lame arguments 1000x times already, the other thread is full of it. Nobody has a clue, wait and see.

 

[krumme]

Is it me or does it sound like an event driven framework with an eventloop per core?

Parallelism and concurency?

Interesting. But how do you synchronize events??? (yeaa concurency- but how does it actually work?)

 

[DaZeeMan]

Here's another quote from Brad in his initial post:
http://forums.elementalgame.com/451041/page/1

The rendering system would be different as well. Since we were starting from scratch with multiple cores, 64-bit and DirectX 11 as basic requirements, the team could design an engine that rendered the same way that CGI in movies are rendered except in this case, in real-time. As a result (and you really have to see it to believe it) the actual visuals look…different than what you may be used to seeing in a game. Even in the Star Swarm demo, which is a very simple, quickly made example, the movement, the lighting, etc. look like a movie scene rather than a computer game. There is no particle effect system. Instead, every laser blast, every light, every effect is an object.

 

[krumme]

So you have a huge pool of unique true object and perhaps parallel concurrent events using those objects? But that mean each core must be its own engine or what? lol

 

[Pottuvoi]

Seriously people stop rehashing the same lame arguments 1000x times already, the other thread is full of it. Nobody has a clue, wait and see.

Indeed.

Especially as the engine does things that no other engine I know does, even in it's dx11 mode.
Decoupled shading is a big thing for renderer, would love to hear specifics of their implementation.

 

[zlatan]

I want to see how this engine stacks up against another proper DX11 engine like Firaxis's Lore Engine, which can do 15 to 20K draw calls in a frame with DX11 multithreading.

Then I want to see how good the Mantle path is :biggrin:

Lore Engine has some limitations. SWARM will help here so we may see better resource utilization in Nitrous. After all Dan Baker working on this, and he wrote the Lore Engine.

Comparing the D3D11 codepath with Mantle is not fair. Mantle is a true multi-threaded API with the ability to re-use command buffers. And also with Mantle there are no hidden driver threads. These will kill the performance on D3D11.

 

[dacostafilipe]

Interesting. But how do you synchronize events??? (yeaa concurency- but how does it actually work?)

I'm not a 3D engine expert, but I would think that there are a lot of cases, where you don't need synchronisation.

Like, instead of having a method where you process the waypoints of all your peons, the peons Themselves battle with the eventloops for processing time and execute the waypoint algo.

Or, if you want to grab all your peons that are around an area, instead of having an array where you sync the actual position of your peons, you just trigger an event and ask the peons if they are around. Here the peons execute the "search" code in a free eventloop spot and response to the event or not. This is where the concurrency comes in

Just basic ideas here

 

[Borealis7]

sorry for going slightly OT...but the Mantle thread is closed (let the circumvention begin).

can someone post GPU usage graph during BF4? i didn't find anything i could use.
i want to know whats the typical GPU usage during BF4 heavy action. if it's high, then how much can MANTLE help by making even more Draw calls to an already loaded GPU?
if it's low (50% and below) then i can understand how there is room for better GPU utilization.

 

[DaZeeMan]

sorry for going slightly OT...but the Mantle thread is closed (let the circumvention begin).

can someone post GPU usage graph during BF4? i didn't find anything i could use.
i want to know whats the typical GPU usage during BF4 heavy action. if it's high, then how much can MANTLE help by making even more Draw calls to an already loaded GPU?
if it's low (50% and below) then i can understand how there is room for better GPU utilization.

This thread on Overclock.net has BF3 and 4 GPU usage graphs.
http://www.overclock.net/t/1432337/...-and-battlefield-4-mp-on-64-person-servers/20

That being said, you are referring to the Frostbite engine, and this thread is supposed to be about the Star Swarm Benchmark, and recent news about the associated Nitrous engine. May I suggest a new Frostbite thread...

 

[stahlhart]

sorry for going slightly OT...but the Mantle thread is closed (let the circumvention begin).

No, and this will be the only warning. No further Mantle discussion in this forum until a launch date is officially confirmed.
-- stahlhart

 

[Paul98]

Since you have been keeping up on info about this, do you have any other interesting Oxide links?

 

[cytg111]

Interesting. But how do you synchronize events??? (yeaa concurency- but how does it actually work?)

No friggin idea, sounds almost too good to be true. If true then the BIG thing here is not mantle or otherwise, it is the MC scaling capabilities.

http://www.youtube.com/watch?v=QIWyf8Hyjbg

Go into 36:00 -> 36:55, he specifically says that synchronization (naive) is not going to work in this scenario. Other than that "he cant talk about it".

Multi Core Scaling Galore .. gonna wanna see it to believe it.

 

[krumme]

I'm not a 3D engine expert, but I would think that there are a lot of cases, where you don't need synchronisation.

Like, instead of having a method where you process the waypoints of all your peons, the peons Themselves battle with the eventloops for processing time and execute the waypoint algo.

Or, if you want to grab all your peons that are around an area, instead of having an array where you sync the actual position of your peons, you just trigger an event and ask the peons if they are around. Here the peons execute the "search" code in a free eventloop spot and response to the event or not. This is where the concurrency comes in

Just basic ideas here

Then remember to shut down your computer when you are done gaming, or the peons continue to game on, constantly negotiating who did come first - or some just wanders around getting no attention because nobody likes them.

And if the game crashes, a huge blame game starts when you reboot !

...i am not a programmer, you should take this to b3d forums. lol.

 

[DaZeeMan]

Since you have been keeping up on info about this, do you have any other interesting Oxide links?

(snip - upon further reading, this comment wasn't correct)

I just came across Mohawk Games announcing that they would be using the Nitrous Engine. Soren Johnson (of Civ IV fame) is the founder of Mohawk Games.
http://www.gameinformer.com/b/news/...nds-mohawk-games-announces-first-project.aspx


I did see another recent article over at mygaming.co.za, but it was focusing on the Mantle side of the Oxide engine, so I'll refrain from posting the link for now. It did mention that the more recent demo we've seen ran on an FX-8350 and an R9-290X. Baker also stated that the demo was entirely GPU bound, and that even if they dropped the CPU to 2 GHz, it would still be GPU bound, with no perceivable drop in performance. Mainly, I just wanted to point out the hardware combo used.

I'll keep my eyes posted, as I'm sure others are doing as well. January 14th can't come soon enough (chompin' at the bit for Kaveri stuff), so I have to keep myself amused somehow! :whiste:

 

[Piroko]

http://www.youtube.com/watch?v=QIWyf8Hyjbg

Go into 36:00 -> 36:55, he specifically says that synchronization (naive) is not going to work in this scenario. Other than that "he cant talk about it".

The question was multiplayer synchronization, which is a problem of its own with so many unique objects.

I suspect NeoLuxembourg is on the right track here. First thought that crossed my mind was SimCity, with each worker as 'independent AI'. No need to directly synchronize them, just manipulate the global ruleset that they work with and let them redefine their goals by themselves. Only this time with a multicore compiler flag *cough cough*

 

[krumme]

No friggin idea, sounds almost too good to be true. If true then the BIG thing here is not mantle or otherwise, it is the MC scaling capabilities.

http://www.youtube.com/watch?v=QIWyf8Hyjbg

Go into 36:00 -> 36:55, he specifically says that synchronization (naive) is not going to work in this scenario. Other than that "he cant talk about it".

Multi Core Scaling Galore .. gonna wanna see it to believe it.

I thought that remark was specific about synchronization in relation to a naive multiplayer implementation using the engine?

Or was that wrong interpreted?

 

[krumme]

As Tim from oxide says they can not synchronize all the object. Makes sense now we know eg every little beam is an object. And as Neoluxembourg notes there is probably a lot of stuff they dont have to syncronize.

What is weird though imo is they say at apu13 they have only been working with xxxxxx for 2 months. The engine can then only be made for dx11 and then adapted for xxxxxx or what?

Its no like you can change the programability in such a short time eg really using you are not drawcall limited ? - making what i would asume would be a far simpler and more clean programming.

 

[Gloomy]

I'm not a 3D engine expert, but I would think that there are a lot of cases, where you don't need synchronisation.

Like, instead of having a method where you process the waypoints of all your peons, the peons Themselves battle with the eventloops for processing time and execute the waypoint algo.

Or, if you want to grab all your peons that are around an area, instead of having an array where you sync the actual position of your peons, you just trigger an event and ask the peons if they are around. Here the peons execute the "search" code in a free eventloop spot and response to the event or not. This is where the concurrency comes in

Just basic ideas here

That sounds a lot like an operating system. Basically you have the kernel that schedules CPU time. And the units in the game are the apps. This seems like it could get complicated pretty fast.

Correct me if I'm off the mark

 

[krumme]

If luxembourg asumption is correct about objects beeing more independant a huge possitive effect is not only speed and huge worlds but also adding big time to the the dynamics and how unpredictable the game is.

We all know from rts how gaming can feel line beating the stupid computer and how objects and processes feels predictable. And when the unpredictable happens it feels planned in a way normal world doesnt.

If the object negotiates for eventloops, in a world with more than the usual meager 80 soldiers so to speak, the end result is probably less predictable? It will then radically change how the game is experienced.

 

[krumme]

Tim - about how you debug 60k batches:
"Because of the true mt implementation there is a lot of message passing"
That means there is a lot of context data when it happens.

 

[dacostafilipe]

That sounds a lot like an operating system. Basically you have the kernel that schedules CPU time. And the units in the game are the apps. This seems like it could get complicated pretty fast.

Correct me if I'm off the mark

You are right! Johan (DICE) event said so in the APU24 presentation. 3D Engines are more and more like a small OS running in an OS ... OSception :biggrin:

Its no like you can change the programability in such a short time eg really using you are not drawcall limited ? - making what i would asume would be a far simpler and more clean programming.

You should still have a command manager in the engine, so in DX you send the commands to a single queue and in other API's you could send it directly to the driver. But this is just a guess.

 

[stahlhart]

What is weird though imo is they say at apu13 they have only been working with xxxxxx for 2 months. The engine can then only be made for dx11 and then adapted for xxxxxx or what?

Just can't help yourself, can you?
-- stahlhart