DirectX 12: The future of it within the console gaming space (specifically the XB1)

[chris1515]

You still haven't convinced me of anything that GNM has all these features or won't need them because of it's low level nature.

Are you claiming that 30,000 draw calls competes with 4.5 Million draw calls? Or that we'll never need more than 30,000 draw calls? Because that's the change that could happen.

An 8 Core jaguar @ 1.6Ghz vs a 4 core 3.3 Ghz processor seems fair if all those cores are going to be used.

I've posted 3DMark.

So now the Ubisoft slide is out because you don't care to admit that as evidence. Sure so now we're comparing 3DMark (4.5Million per second) vs Infamous Second Son numbers (900,000 per second).

While I'm unsure as to the application of this for games, or even performance, you see the two numbers do not line up, and to suggest 4.5M and 900K are equivalent is wrong. Therefore, it is in my strong opinion that GNM does NOT have multithreaded rendering in the same way that DX12/Vulkan does.

How much a PS4 with GNM can do in a benchmark. It is a real game.

2,3,4 millions we don't know...

 

[iroboto]

And about draw call on consoles it is an old subject. You can use the search function and PS3 and Xbox 360 were better than PC for a long time.

On Infamous presentation they gave the number of drawcall for the title on PS4 using the Jaguar CPU it is approximately 30000. Ahead of what I have seen on DirectX 11 for better CPU than the Jaguar...

No, they said 30K. For their game they instanced the draw calls down to 10K. Please read carefully. Not saying it wouldn't be higher as a dedicated test, but it will need to make up 3.6 million draw calls somewhere in there.

And DirectX11 has Multi-threading as well. Just not done right.

 

[DrJay24]

That puts GNM about 50% better than DX11 Single Threaded/ Multithreaded. About 1/5 the performance of DX12 multithreaded.

You are comparing a real shipped game with a synthetic benchmark. You seem to have your mind made up about something, despite expert feedback.

 

[Shifty Geezer]

Are you claiming that 30,000 draw calls competes with 4.5 Million draw calls?

These latest benchmark scores of millions of drawcalls are pretty daft, like raw poly drawing numbers. PS2 can draw ~70 million triangles per second - but not in game where those triangles do something. Likewise, 4 million drawcalls a second doesn't mean 4 million things per second in game, and a GPU that can now handle 9 million drawcalls a second in DX12 where it was 900k in DX11 isn't going to be 10x faster in games.

The drawcalls represent one of the processing costs in getting pretties on screen. Improving the drawcall efficiency means this aspect of the rendering is improved, but the GPU still needs to draw stuff, and the CPU still needs to calculate other stuff and can't spend all its time just creating drawcalls.

So the 30k is an in game count. It is reportedly having very little CPU overhead, and at the same time the CPU is doing those other reasonably demanding jobs. We'll likely never get a raw benchmark for how many drawcalls PS4 can perform per second because no-one would bother creating one. As long as the drawcalls necessary for your graphics workload are having neglegable impact on your CPU in the profiler, you'll just ignore the drawcall performance as a non-issue.

 

[chris1515]

I heard the number of 100k drawcall in real game with GPU generated command on PS4 and Xbox One.

 

[iroboto]

You are comparing a real shipped game with a synthetic benchmark. You seem to have your mind made up about something, despite expert feedback.

I haven't made up my mind on the performance of how many draw calls can be made with PS4.

I am baffled by the truth fact statement that GNM implements better features or has equivalent feature such as multithreaded rendering comparable to Vulkan and DX12 - given the evidence I have put forward it at least puts in some doubt to his claim.

If at the least I prefer that we stop talking as if it is fact PS4 is capable of these things without definitive proof of it. At least reserve some room for doubt.

 

[iroboto]

These latest benchmark scores of millions of drawcalls are pretty daft, like raw poly drawing numbers. PS2 can draw ~70 million triangles per second - but not in game where those triangles do something. Likewise, 4 million drawcalls a second doesn't mean 4 million things per second in game, and a GPU that can now handle 9 million drawcalls a second in DX12 where it was 900k in DX11 isn't going to be 10x faster in games.

The drawcalls represent one of the processing costs in getting pretties on screen. Improving the drawcall efficiency means this aspect of the rendering is improved, but the GPU still needs to draw stuff, and the CPU still needs to calculate other stuff and can't spend all its time just creating drawcalls.

So the 30k is an in game count. It is reportedly having very little CPU overhead, and at the same time the CPU is doing those other reasonably demanding jobs. We'll likely never get a raw benchmark for how many drawcalls PS4 can perform per second because no-one would bother creating one. As long as the drawcalls necessary for your graphics workload are having neglegable impact on your CPU in the profiler, you'll just ignore the drawcall performance as a non-issue.

I whole heartedly agree. Draw call performance and game performance are not the same and I've written that in my post. But if we are going to be technical about whether a feature supports something to this degree or not at least we should be objective about it.

 

[chris1515]

I haven't made up my mind on the performance of how many draw calls can be made with PS4.

I am baffled by the truth fact statement that GNM implements better features or has equivalent feature such as multithreaded rendering comparable to Vulkan and DX12 - given the evidence I have put forward it at least puts in some doubt to his claim.

If at the least I prefer that we stop talking as if it is fact PS4 is capable of these things without definitive proof of it. At least reserve some room for doubt.

Because you think ICE Team the people doing the PS4 API are a bunch of incompetent there is a reason the 3D industry have very similar solution coming from 2/3 differents API provider Mantle, Vulkan(some cross development with Mantle) and Direct X12.

And DX11 drawcall limit is a regression from console drawcall API... You control everything and have few overhead in console API. DirectX 12 is like console API with a little more abstraction and new great feature like conservative rasterization, ROV and so on...

 

[Deleted member 11852]

I am baffled by the truth fact statement that GNM implements better features or has equivalent feature such as multithreaded rendering comparable to Vulkan and DX12 - given the evidence I have put forward it at least puts in some doubt to his claim.

That is a software concept. Deep Silver (the Metro guys) have clarified how little software API overhead there is in GNM. If you are looking for evidence that GNM allows any/many cores to access and program the GPU command buffers then you're unlikely to find it because it doesn't look at though there is much software sandwiched between game code and the hardware.

You're looking for evidence that a software API problem on PCs doesn't impact PS4 which doesn't use those APIs.

 

[iroboto]

Because you think ICE Team the people doing the PS4 API are a bunch of incompetent there is a reason the 3D industry have the same solution coming from 2/3 differents API provider Mantle, Vulkan(some cross development with Mantle) and Direct X12.

And DX11 drawcall limit is a regression from PS3 drawcall API...

No. It's because we don't have proof of it. Yet you keep claiming that your are right about it.

 

[chris1515]

http://www.bit-tech.net/hardware/graphics/2011/03/16/farewell-to-directx/2

PS3 and 360 are capable of 10k to 20k drawcall in real game. The 30k of Jaguar in a game is not very impressive because PS4 and Xbox One are GPU centric console. You need to let the GPU feeding themselves.

But it's still very hard to throw tremendous variety into a PC game. If you want each of your draw calls to be a bit different, then you can't get over about 2-3,000 draw calls typically - and certainly a maximum amount of 5,000. Games developers definitely have a need for that. Console games often use 10-20,000 draw calls per frame, and that's an easier way to let the artist's vision shine through.'

 

[iroboto]

That is a software concept. Deep Silver (the Metro guys) have clarified how little software API overhead there is in GNM. If you are looking for evidence that GNM allows any/many cores to access and program the GPU command buffers then you're unlikely to find it because it doesn't look at though there is much software sandwiched between game code and the hardware.

You're looking for evidence that a software API problem on PCs doesn't impact PS4 which doesn't use those APIs.

Yes. I agree with that. So if you want your own multithreaded renderer on the GPU side of things you need to code it yourself?

That's technically equal or better, but also very inaccessible.

 

[chris1515]

Yes. I agree with that. So if you want your own multithreaded renderer on the GPU side of things you need to code it yourself?

That's technically equal or better, but also very inaccessible.

In Direct X12, developer need to do more work too. Less overhead more control for developer...

 

[chris1515]

http://m.neogaf.com/showthread.php?t=1020211

From CDPROJET game designer and related to The Witcher 3 game. Not true for all developper.

Damien Monnier, Senior Games Designer at CD Projekt Red, confirms the Witcher 3 resolution on XB1 + PS4 and talks about DX12 for XB1 on Twitter:

900 vs 1080p for ps4. The game is the same.

i think any resolution changes would require a much bigger change from Microsoft than dx12 upgrade to be honest.

 

[Deleted member 11852]

Yes. I agree with that. So if you want your own multithreaded renderer on the GPU side of things you need to code it yourself?

Not an entire API but you would need to manage synchronicity between the cores feeding the GPU and manage loading of the GPU. But this kind of management and scheduling isn't a new problem, it's a very old problem. All that's changed necessitating this change in DirectX12 is that computer processing, which has increasingly been growing wider (parallelism) instead of cores getting faster, has become an impediment to feeding the GPUs.

 

[Shifty Geezer]

I whole heartedly agree. Draw call performance and game performance are not the same and I've written that in my post. But if we are going to be technical about whether a feature supports something to this degree or not at least we should be objective about it.

Fair enough, but I'm not sure we'll ever have that objective data. The only reason we know all about DX12's benchmarks is MS are currently pimping it. Drawcalls have always been a non-issue on consoles, and only now if interest if they have a PC-like overhead on XB1.

Not an entire API but you would need to manage synchronicity between the cores feeding the GPU and manage loading of the GPU.

Is that even that important? As in, we have in this thread, IIRC, mention that PS4 literally pokes some values to the GPU to issue a drawcall. Managing simultaneous writes would be an issue transparently handled by the memory systems, so I can see a situation where you have cores generating different workloads and each submitting to the GPU.

What even is the benefit of multicore drawcalls? Being able to batch them faster, so a smaller slice of ms from the frame-time budget?

 

[Deleted member 11852]

Is that even that important? As in, we have in this thread, IIRC, mention that PS4 literally pokes some values to the GPU to issue a drawcall. Managing simultaneous writes would be an issue transparently handled by the memory systems, so I can see a situation where you have cores generating different workloads and each submitting to the GPU.

It's important because you don't want core A begin writing data to the command buffers only to have core B or C overwrite some/all of those values before Core A has finished setting the GPU up, let alone before the GPU has even had a chance to execute the command.

If the memory system manages this automagically, it's the first I've read of it.

 

[iroboto]

Fair enough, but I'm not sure we'll ever have that objective data. The only reason we know all about DX12's benchmarks is MS are currently pimping it. Drawcalls have always been a non-issue on consoles, and only now if interest if they have a PC-like overhead on XB1.

Is that even that important? As in, we have in this thread, IIRC, mention that PS4 literally pokes some values to the GPU to issue a drawcall. Managing simultaneous writes would be an issue transparently handled by the memory systems, so I can see a situation where you have cores generating different workloads and each submitting to the GPU.

What even is the benefit of multicore drawcalls? Being able to batch them faster, so a smaller slice of ms from the frame-time budget?

Well draw calls can be batched to be even less draw calls. So in some games it's going to be entirely pointless.

I think you would need multithreaded draw calls to ensure that the game isn't being serialized. 1 thread doing shadows while the other thread operating on the rest.

Or you need more draw calls if you want individuality to things like exploding walls and debris all acting on its own each piece affected by its own physics everywhere.

Or if you want tons of different objects each with their own material and shaders.

Or if you want to just ramp up performance faster, like being able to fill a command queue quickly if it gets empty.

This is all that I've read about it so far. There is also to a degree fine grained culling.

 

[Scott_Arm]

All DX12 is going to do is bring Xbox One closer to parity with PS4 in terms of API performance, not overall system performance. The gaps in overall hardware is still there. I wouldn't expect every game to suddenly be 1080p. The ESRAM is still the same size, and it still has the same number of CUs. I think it just might provide some more flexibility for different rendering approaches, and maybe help remove some system bottlenecks to stabalize framerates. Just a guess, but I think it's more reasonable than the expectations of some Xbox fans.

 

[iroboto]

It's important because you don't want core A begin writing data to the command buffers only to have core B or C overwrite some/all of those values before Core A has finished setting the GPU up, let alone before the GPU has even had a chance to execute the command.

If the memory system manages this automagically, it's the first I've read of it.

I think this is something that DX12 does handle for you; hence the effort to place it into the API and call it a feature.

Command queue overview
Direct3D 12 command queues replace hidden runtime and driver synchronization of immediate mode work submission with APIs for explicitly managing concurrency, parallelism and synchronization. Command queues provide the following improvements for developers:

• Allows developers to avoid accidental inefficiencies caused by unexpected synchronization.
• Allows developers to introduce synchronization at a higher level where the required synchronization can be determined more efficiently and accurately. This means the runtime and the graphics driver will spend less time reactively engineering parallelism.
• Makes expensive operations more explicit.

These improvements enable or enhance the following scenarios:

• Increased parallelism - Applications can use deeper queues for background workloads, such as video decoding, when they have separate queues for foreground work.
• Asynchronous and low-priority GPU work - The command queue model enables concurrent execution of low-priority GPU work and atomic operations that enable one GPU thread to consume the results of another unsynchronized thread without blocking.
• High-priority compute work - This design enables scenarios that require interrupting 3D rendering to do a small amount of high-priority compute work so that the result can obtained early for additional processing on the CPU.