DX12 Performance Discussion And Analysis Thread

[MDolenc]

Overlaps, as one draw call ends and another starts, won't fill the ALUs, in general. The short period of overlap might increase ALU utilisation, but then it'll settle at the level dictated by the new draw call. Utilisation could be worse or it could be better after the overlap has finished.

Overlaps certainly can't be relied upon to improve ALU utilisation.

No it's not just overlap as one draw call finishes and another one starts... Why do you think Andrew commented about my Async Compute test that it could be easily made concurrent even on Intel? Or what sebbbi mentioned here?
Draw calls can run in parallel just fine. You just don't get shared memory.

That depends on whether the blend mode and render targets are commutative, doesn't it? The vertex based shaders are trivial to pipeline or even to execute out of order between drawcalls, but the pixel / fragment shaders can't overlap unless the blend operation itself is independent from order of execution.

Nothing stoping you from rendering to another render target... Or drop the render target altogether and use UAV...

 

[renderstate]

It depends on how state is handled. If you keep state stored in fixed size on chip memory/context and you run out of it you will stall.

 

[Ethatron]

Sorry to be dense, but I don't understand - do you mean that the GPU driver is in some sense a third party that cannot be relied on to run commands submitted to the same queue in parallel?

Correct. And nowadays you couldn't even bully Nvidia to do you the favor, not big enough.

 

[renderstate]

Correct. And nowadays you couldn't even bully Nvidia to do you the favor, not big enough.

Incorrect actually. The API doesn't specify tasks from different queues must be scheduled concurrently. Enforcing it it would make no sense since if a particular workload already nicely fills the GPU co-scheduling other work would cause oversubscription of HW resources, with the risk of impacting performance. Concurrent execution is nice when it can improve performance but using it in the general case is a stupid idea.

 

[Infinisearch]

Incorrect actually. The API doesn't specify tasks from different queues must be scheduled concurrently.

Wasn't he talking about the same queue.

 

[renderstate]

Wasn't he talking about the same queue.

Same story.

 

[3dcgi]

That depends on whether the blend mode and render targets are commutative, doesn't it? The vertex based shaders are trivial to pipeline or even to execute out of order between drawcalls, but the pixel / fragment shaders can't overlap unless the blend operation itself is independent from order of execution.

Pixel shaders can operate in parallel even with blending as blending occurs outside the PS. ROVs change this a little but there's still opportunity for overlap.

CSI PC. You're hung up on studios like DICE. They work on PC titles so they recieve help from AMD. If the knowledge gained or code received can be adapted to consoles great. If a studio only works on consoles they won't receive formal assistance from AMD. AMD visits UbiSoft from time to time because they develop for the PC. A console team may attend meetings and learn something but devrel folks won't contribute code as they might with a PC title.

 

[Jawed]

Draw calls can run in parallel just fine.

Even if they do, there are still performance gains coming from work that uses asynchronous compute.

Question: is it possible to get the gain seen with asynchronous compute when not using it, by careful rearrangement of work in the graphics queue (in games, not a tech demo)? If so, is it harder or easier to use asynchronous compute to get that performance gain?

 

[3dcgi]

is it possible to get the gain seen with asynchronous compute when not using it, by careful rearrangement of work in the graphics queue (in games, not a tech demo)? If so, is it harder or easier to use asynchronous compute to get that performance gain?

Not completely. The draw calls would need to be fairly small. Then you'd need to interleave draws that have different performance characteristics. Unfortunately this changes the state of the chip and this can change a limited number of times before the pipe stalls. If the chip is able to reuse states you may be able to keep the pipeline full but you're limited by the launch rate of the graphics pipe. Async compute should be much easier to use.

 

[Infinisearch]

Pixel shaders can operate in parallel even with blending as blending occurs outside the PS.

I thought modern GPU's implement blending as a shader postfixed to the pixel shader?

 

[renderstate]

I thought modern GPU's implement blending as a shader postfixed to the pixel shader?

Not on discrete GPUs. PowerVR does it IIRC, it's quite a natural fit for TBDRs, although I don't like much the idea of having programs that are not orthogonal to some render states (i.e. a render state change might force a partial or full shader recompile).

 

[Ethatron]

Incorrect actually.

You know very well that Nvidia hasn't blessed me with an API which serves my ideas, instead of theirs.
Edit: I'm talking politics, not some informatics lodge happy convention where all agree which is the obvious solution after some beer, which ofc also doesn't exist. Freedom of choice allows innovation.

Nevermind, I'm sorry, I'm just angry. As a programmer I'm happy that I have the flexibility to test and finalize things by myself in any way I see fit, instead of being forced to work around in.

 

[CSI PC]

Pixel shaders can operate in parallel even with blending as blending occurs outside the PS. ROVs change this a little but there's still opportunity for overlap.

CSI PC. You're hung up on studios like DICE. They work on PC titles so they recieve help from AMD. If the knowledge gained or code received can be adapted to consoles great. If a studio only works on consoles they won't receive formal assistance from AMD. AMD visits UbiSoft from time to time because they develop for the PC. A console team may attend meetings and learn something but devrel folks won't contribute code as they might with a PC title.

And again what about the games that are console ports that do not utilise the primary development team and can even be outsourced to another studio?
At what point would the R&D team in a large AAA studio be engaged with AMD if the development is initially for console release?
You missed out Square Enix or are you saying their primary development of their game-rendering engine and integral post processing effects is only PC and console ports do not exist
What about Watch Dogs 2 that has the console as primary development focus and already talk that it is heavily optimised for AMD?
I only used Square Enix and Dice because both have mentioned working with AMD in all aspects both PC and console,
But yeah I will drop it even though I have quotes from those studios, and that most of modern AAA multi-platform gaming are console ports.
Cheers

Edit:
To emphasise just as recent as Capsaicin and not using other information I have but still pretty clear.
AMD to both: "Can you explain in particular for PC gamers how the GPU hardware on PC could benefit from what you have today on consoles?"
Dice: "There are a lot of console features that not yet have been exposed to the PC, for example shader extensions, in GPUOpen we get access to the scalar processor and that will allow us to squeeze last bit of performance out of existing hardware".
Square Enix: "PC games are very important to <mentions all their studios>, and we team up with world renowned company called Nixxes to ensure we provide the best solution to our customers.
We are relying upon them that we have the best PC game out there and any bridge and any time those platforms are getting closer it is for the benefit of every gamer".

The two involved were Arne Schober and Jean-Nomand Bucci.
And yes Square Enix does work with AMD directly, no idea about Nixxes.
And this falls into consideration when a game has primary development and focus for consoles followed up by PCs.
Cheers

 

[Razor1]

Guys it depends on the company and the IHV's preference to work with the publisher or if its a marquee title for them, AMD does work with companies that do develop exclusively consoles as well. But the support isn't as great, since the console teams already are well versed in console development, those teams need to have experience even before Xbox or PS dev kits are sent to them (Xbox is less stringent with this requirement but no Publisher will pick up a novice team to work on a console game on the Xbox)/ The experience needed is extensive too we are talking about each team member having 5 AAA titles under their belt before Sony will even give ya a PS4 dev kit.

So in cases of a console teams, the dev support can be minimized, but porting those over to PC's if a secondary studio with less experienced team members are on them, yeah they will push more support (and this is a must), changing code already done always is a bit harder then writing fresh code at least at first and the time given is usually crunched down.

 

[Silent_Buddha]

And yes Square Enix does work with AMD directly, no idea about Nixxes.
And this falls into consideration when a game has primary development and focus for consoles followed up by PCs.
Cheers

Actually Square works more closely with Nvidia than they do AMD. Their console versions of some of their games lack features (Nvidia specific in many cases) that exist on the PC. The most obvious example of this is FFXIV. Also no surprise then that it runs quite significantly better on Nvidia hardware. I don't think Square engages with AMD on PC any more than any other developer.

It'll be interesting to see if FFXV follows this trend or if they actually engaged with AMD at all to improve the situation on PC.

Their Dx12 demo was run in conjunction with Nvidia as well, IIRC.

Thinking about it though, their Eidos branch (NA) collaborated with AMD somewhat on the PC versions, unlike their Japan studios.

Regards,
SB

 

[CSI PC]

Guys it depends on the company and the IHV's preference to work with the publisher or if its a marquee title for them, AMD does work with companies that do develop exclusively consoles as well. But the support isn't as great, since the console teams already are well versed in console development, those teams need to have experience even before Xbox or PS dev kits are sent to them (Xbox is less stringent with this requirement but no Publisher will pick up a novice team to work on a console game on the Xbox)/ The experience needed is extensive too we are talking about each team member having 5 AAA titles under their belt before Sony will even give ya a PS4 dev kit.

So in cases of a console teams, the dev support can be minimized, but porting those over to PC's if a secondary studio with less experienced team members are on them, yeah they will push more support (and this is a must), changing code already done always is a bit harder then writing fresh code at least at first and the time given is usually crunched down.

But part of this is design considerations and constraints.
Due to the way the Northlight engine was designed it is not possible to resolve all the issues seen on PC, you cannot re-write all of the code/game engine.
So any big budget multi-plaftorm game must consider at an early stage what it can do for both primary and secondary platforms, especially if looking to heavily optimise it with specific hardware.
Cheers

 

[CSI PC]

Actually Square works more closely with Nvidia than they do AMD. Their console versions of some of their games lack features (Nvidia specific in many cases) that exist on the PC. The most obvious example of this is FFXIV. Also no surprise then that it runs quite significantly better on Nvidia hardware. I don't think Square engages with AMD on PC any more than any other developer.

It'll be interesting to see if FFXV follows this trend or if they actually engaged with AMD at all to improve the situation on PC.

Their Dx12 demo was run in conjunction with Nvidia as well, IIRC.

Thinking about it though, their Eidos branch (NA) collaborated with AMD somewhat on the PC versions, unlike their Japan studios.

Regards,
SB

Square Enix uses Nixxes for the PC ports although they use the same engine.
But anyway.
Tomb Raider some years ago with TressFX.
Latest Tomb Raider using Pure Hair with also some nifty GFX quality features including the detailed snow even on console (adaptive tessellation), the visual quality of these is not the same on Nvidia HW (less quality) and does not have the snow effects, although this game is using the Foundation engine and does mean Nixxes has added Tessellation related features and some Nvidia specific AO.
Hitman, another game with AMD who said it was the best implementation of DX12 and async compute - well I would say with the latest DX12 Async compute patch that would be RoTR more so than this.

Just because a game has Gameworks does not mean they are working very closely with Nvidia, as I mentioned earlier an example of a studio that does work closely with Nvidia and more so than some of the other large studios is Bethesda, where they technically integrate Nvidia features with their engine and optimisation, Fallout games will never work great on previous gen AMD (Polaris is performing much better though).
Anyway to quote Eurogramer when they analysed Hitman on all platforms:

The Glacier 2 engine delivers attractive visuals that perfectly suit the game, and it's apparent IO Interactive has taken a console-first approach to building its levels - with PC receiving a few neat visual extras at its maximum preset

It is using a newer engine designed for console and PC.

The Tech Demo your thinking of 'Witch' (and yeah it looks like a stunning engine) was using Nvidia hardware (a lot of it) for the demo but it is Luminous Studio 1.5/2.0 that is primarily for now FFXV on consoles.

For me personally I am looking forward to see FFXV on PC as that one is meant to have decent DX12 with the latest Luminous Studio console-PC engine, I wonder if Nixxes will do this port or with the new engine they will take a more hands on approach.
Loved those games all way back to FFVII.

Cheers.

 

[Razor1]

But part of this is design considerations and constraints.
Due to the way the Northlight engine was designed it is not possible to resolve all the issues seen on PC, you cannot re-write all of the code/game engine.
So any big budget multi-plaftorm game must consider at an early stage what it can do for both primary and secondary platforms, especially if looking to heavily optimise it with specific hardware.
Cheers

That is true and this is why man console ports to PC come out like crap cause PC is an afterthought. If the PC version of a game was made or planned to be made and early steps are taken to start actual development around the same time the console version of the game is being made many problems can be averted. But usually PC development starts well after console version is already up and playable or even sometimes given out to another shop as you stated after the console version is nearly done and is into Beta Testing, which at that point the time to rewrite code is so limited because of the learning curve of the new team, problems are unavoidable.

 

[Silent_Buddha]

Square Enix uses Nixxes for the PC ports although they use the same engine.

Only for their Eidos studio ports AFAIK.

Their older FF ports (the recent FFIX PC release, for example) use a studio based out of Singapore. And FFXIV is done in house with assistance from Nvidia. It's not a surprise that the past few FF games have been partnered with Nvidia both on PC and console as prior to this generation the PS3 was the lead platform.

Just because a game has Gameworks does not mean they are working very closely with Nvidia

It also means they can't work closely with AMD as AMD would not be able to help them with anything involving or interfacing with Gameworks not for lack or desire to on AMD's part, but due to the legally binding agreements you have to make with Nvidia.

Regards,
SB

 

[Razor1]

It also means they can't work closely with AMD as AMD would not be able to help them with anything involving or interfacing with Gameworks not for lack or desire to on AMD's part, but due to the legally binding agreements you have to make with Nvidia.

Regards,
SB

Can you tell me those legally binding agreements? Cause I haven't seen a single one that says a team can't work with AMD if they are using gameworks, yeah they can't share gameworks code with AMD, if the team has purchased the source code, but outside of that, there is nothing in there.