Nvidia publicly bashing Stardock developer over an ALPHA level game

Semantics said:
Not all DX12 games will care so much about draw calls like aots or 3dmark both use way more calls then your avg console game, which like it or not is what games tend to start out as first. It's like a game with heavy tessellation or geometry favors nvidia a game with heavy amount of calls favors amd's arch.
Click to expand...

That's why AMD should push for games that feature such advantages. Not just Stardock, maybe even Blizzard/Valve/EA to push new IPs/reboots.
 
Or maybe we should keep both tessellation and draw calls at reasonable levels so that we don't have to flip video card brands for each game we play.
 
TaintedSquirrel said:
Or maybe we should keep both tessellation and draw calls at reasonable levels so that we don't have to flip video card brands for each game we play.
Click to expand...
Or Nvidia could just release a gpu that keeps it's best in show performance for tessellation and geometry but increase the amount of draw calls the arch can hit before bottlenecking. Just like AMD could just release cards that can do heavy tessellation better instead of saying they do enough and nvidia's gameworks is the problem. Work in the system instead of blaming shortcomings on competitors. Fury and 285 showed they can increase tessellation still no where near nvidia's dedication to geometry crunching but quite improved over previous generations.
 
These new APIs weren't designed to maximize draw call efficiency, they were designed to reduce/remove the overhead from GPU - CPU synchronization which is a factor in pretty much every call to the API you make.

Draw calls are just invoked the most, and game devs do their best to batch them together (instancing, etc) in order to reduce the synchronization as much as possible.
 
jwcalla said:
Draw calls are bottlenecked on the CPU, not the GPU.
Click to expand...

I think scheduling throughput is the right word, not raw draw call throughput. AMD wins because they parallelise scheduling, while NVIDIA doesn't, at least that's my understanding from the links.

Maxwell 2 HyperQ is thus potentially bottlenecked at the Grid Management and then Work Distributor segments of its pipeline. This is because these stages of the Pipeline are "in order". In other words HyperQ contains only a single pipeline (Serial not Parallel).

AMDs Asynchronous Compute Engine implementation is different. It contains 8 Parallel Pipelines working independently from one another. This is why AMDs implementation can be described as being "out of order".
Click to expand...
 
trandoanhung1991 said:
I think scheduling throughput is the right word, not raw draw call throughput. AMD wins because they parallelise scheduling, while NVIDIA doesn't, at least that's my understanding from the links.
Click to expand...

Yeah, maybe I should have said more like GPU utilization. All in all, devs should have no problems getting the # of drawcalls they need for their games on these new APIs, and going forward we'll probably continue to see that for newer games and higher resolutions, the GPU is still going to be the bottleneck (i.e., running at full utilization).

As we saw with the official independent Mantle benchmarks, there were scenarios where there were large improvements and scenarios with no improvements. The former were CPU-limited parts of a game, or games run on lower-end CPUs, or games with a lot of draw calls. The latter scenario occurred with the GPU-limited cases.
 
jwcalla said:
Umm, it shouldn't be the same. You seem to think that the only room for improvement is increasing draw call count. You know there is a whole world out there beyond just draw calls.

It is true that this benchmark seems to be all about draw calls and that's it. Which gives credence to nvidia's argument that it is not a good representation of what DX12 can do.
Click to expand...

The performance lies in the amount of cores that can talk to the GPU. with DX11 there can only be 1 core at a time to talk to the GPU with DX12 this number limited by the number of cores on the cpu.

Nvidia is just talking out of their ass when it comes to Oxide Nitrous engine. They pretend that they have intricate knowledge of everything related to every engine, while they signed on for DX12 where the game developers themselves are doing the hard work without the driver getting in the way. For them to comment in the way they did just shows that Nvidia does not care about gaming just about Nvidia ....
 
Last edited:
cocdod said:
These new APIs weren't designed to maximize draw call efficiency, they were designed to reduce/remove the overhead from GPU - CPU synchronization which is a factor in pretty much every call to the API you make.

Draw calls are just invoked the most, and game devs do their best to batch them together (instancing, etc) in order to reduce the synchronization as much as possible.
Click to expand...

Those are 2 different things.

Part of the new API's is making everything as cheap as it can possibly be by doing as much work up front as possible. That's why you're doing more than ever _before_ draw time, like compiling your giant state block. They want as little done at draw time (validation, etc) as possible.

For example, you can do a pretty good job of hurting performance in the new API's by doing stuff like not buffering resources. If you locked / mapped a resource in the older DX versions with the DISCARD flag, the driver would probably do it for you behind the scenes so you don't hit a sync point (assuming you had enough free memory). You're on your own now.

Pieter3dnow said:
The performance lies in the amount of cores that can talk to the GPU. with DX11 there can only be 1 core at a time to talk to the GPU with DX12 this number limited by the number of cores on the cpu.
Click to expand...

You could try in DX11, the concept was there but the execution is another story.

The new stateless design makes a lot of sense, and you elegantly stomp a lot of problems adhering to it - even for other API's.
 
What if developers aren't willing to manage all that? Would they just stick to DX11, then?
 
So basically, nVidia and AMD need to talk with devs so they can change their code to suite each GPU, since DX12 driver optimizations won't matter as much as < dx12 games?
 
umeng2002 said:
So basically, nVidia and AMD need to talk with devs so they can change their code to suite each GPU, since DX12 driver optimizations won't matter as much as < dx12 games?
Click to expand...

Developers use tools which show where the bottlenecks are , if developers run into trouble they can and should ask for help. This however is not that uncommon even with DX11/9 nothing changes.
 
umeng2002 said:
So basically, nVidia and AMD need to talk with devs so they can change their code to suite each GPU, since DX12 driver optimizations won't matter as much as < dx12 games?
Click to expand...

Yes, which is why companies like Oxide are working directly with all companies:

Being fair to all the graphics vendors

Often we get asked about fairness, that is, usually if in regards to treating Nvidia and AMD equally? Are we working closer with one vendor then another? The answer is that we have an open access policy. Our goal is to make our game run as fast as possible on everyone’s machine, regardless of what hardware our players have.

To this end, we have made our source code available to Microsoft, Nvidia, AMD and Intel for over a year. We have received a huge amount of feedback. For example, when Nvidia noticed that a specific shader was taking a particularly long time on their hardware, they offered an optimized shader that made things faster which we integrated into our code.

We only have two requirements for implementing vendor optimizations: We require that it not be a loss for other hardware implementations, and we require that it doesn’t move the engine architecture backward (that is, we are not jeopardizing the future for the present).
Click to expand...

Nvidia has had the source code for this game for over a year and even helped contribute to it.

They have a very optimized DX 11 engine and working on making their DX12 even better.

They acknowledged that drivers from all companies will improve in their blog from the OP, but many people aren't reading it..

Immature drivers are nothing to be concerned about. This is the simple fact that DirectX 12 is brand-new and it will take time for developers and graphics vendors to optimize their use of it. We remember the first days of DX11. Nothing worked, it was slower then DX9, buggy and so forth. It took years for it to be solidly better then previous technology. DirectX12, by contrast, is in far better shape then DX11 was at launch. Regardless of the hardware, DirectX 12 is a big win for PC gamers. It allows games to make full use of their graphics and CPU by eliminating the serialization of graphics commands between the processor and the graphics card.

I don’t think anyone will be surprised when I say that DirectX 12 performance, on your hardware, will get better and better as drivers mature.
Click to expand...
 
WOW, looking back at Brad Wardell's odd Tweet was in fact quite serious :

Brad Wardell
Brad Wardell &#8211; &#8207;@draginol

@NVIDIAGeForce @nvidia tread lightly. @OxideGames.
9:51 a.m. - 16 Aug 2015
Click to expand...

https://mobile.twitter.com/draginol/status/632957839556874240

While at the same time still showing restraint, earned respect points from me. Cause at this point I think it safe to say all parties involved knew what was going on.
 
That was 1 day before the NDA lift on AotS, which means by then everyone involved had access to Nvidia's statements about "MSAA bugs" and "not indicative of DX12 performance".
Looks like any of AMD's arguments with GameWorks devs, tbh.
 
The reality is the MSAA code follows the DX11 path, it has nothing to do with DX12.

Nvidia later acknowledged it was a bug in their driver.

That was just oxide reminding Nvidia to stay on point.

It was pretty ballsy wagging a finger at the "Graphics Mafia" however.

lol
 
Last edited:
You must log in or register to reply here.
Back
Top