Nvidia publishes DX12 Do's and Don'ts checklist for developers

[HEXUS]

Because the DirectX 12 API "places more responsibilities on the programmer".

Read more.

[Defiant]

Anyone else thing that the list and size of bugs and results of things going wrong are about to explode when developers code poorly?

[Moogly]

This was not written for me so why did I read this?

[shaithis]

Anyone else thing that the list and size of bugs and results of things going wrong are about to explode when developers code poorly?

DX12 means devs have to do more......I am bracing for a bad initial launch of DX12 titles and hope that the proliferation of games on standard engines continue as then at least the engine makers can take the brunt of the work at the engine-level.

[Primey0]

Nvidia be all like

Don't:

* Use async compute. Pretty please.

[DemonHighwayman]

To be honest I don't care about DX12 anymore, I'm rooting for Vulkan and am hoping it gives MS's DX12 a good thrashing.

[MarcelTimmer]

It looks like Nvidia is not ready for dx12. I hear no complaining from AMD about it.

[shaithis]

It looks like Nvidia is not ready for dx12. I hear no complaining from AMD about it.

What makes you think that? These are techniques to help ALL DX12 developers, regardless of the hardware they are developing on.

You could say, shame on AMD for not helping the devs......and if they don't watch themselves we might end up with GamesWork 2.0 thanks to DX12 being harder to write for....which means devs will turn to tools to help them code faster.

[crossy]

This was not written for me so why did I read this?

Probably for the same reasons that I read it - because I was interested in knowing what the heck was going on, and blissfully optimistic that I might even understand some small portion of the information therein.

Nope, no wiser, just more confused and aware of my lack of ability.

[kalniel]

If not in fullscreen state (true immediate independent flip mode) consider using a waitable object swap-chain along with WaitForSingleObjectEx() to generate higher FPS

- Please note that this will lead to some frame never being even partially visible, but may be a good solution for benchmarking

<tin foil> Implicit acknowledgement of FPS chasing regardless of dropped frames? </tin foil>

[HalloweenJack]

https://developer.nvidia.com/dx12-dos-and-donts#dx12

Do's
•Use hardware conservative raster for full-speed conservative rasterization
◦No need to use a GS to implement a ‘slow’ software base conservative rasterization
◦See https://developer.nvidia.com/content...-rasterization

•Make use of NvAPI (when available) to access other Maxwell features
◦Advanced Rasterization features
◾Bounding box rasterization mode for quad based geometry
◾New MSAA features like post depth coverage mask and overriding the coverage mask for routing of data to sub-samples
◾Programmable MSAA sample locations
◦Fast Geometry Shader features
◾Render to cube maps in one geometry pass without geometry amplifications
◾Render to multiple viewports without geometry amplifications
◾Use the fast pass-through geometry shader for techniques that need per-triangle data in the pixel shader
◦New interlocked operations
◦Enhanced blending ops
◦New texture filtering ops

Don’ts
•Don’t use Raster Order View (ROV) techniques pervasively
◦Guaranteeing order doesn’t come for free
◦Always compare with alternative approaches like advanced blending ops and atomics

so yes that's `DO use what we can do well and Don't use other stuff our competition can use well

[Corky34]

It looks like Nvidia is not ready for dx12. I hear no complaining from AMD about it.

Nvidia be all like

Don't:

* Use async compute. Pretty please.

so yes that's `DO use what we can do well and Don't use other stuff our competition can use well

Didn't take long for the AMD fanbios to surface I see.
Shame one doesn't even know async compute isn't a requirement of DX12.

[canopus72]

Typical NVidia thug behaviour. All they have done is gripe about DX12 and the atrocious performance of their beloved 980gtx in the DX12 game 'ashes of singularity'. The harsh reality is that Maxwell (and upcoming pascal) are completely incapable of undertaking Asynchronous Compute. That is the fault of NVidia engineers and nobody else, yet NVidia are laying false accusation at everyone else. Absolutely pathetic, petulant behaviour. I will never buy NVidia again.

[Jimbo75]

What makes you think that? These are techniques to help ALL DX12 developers, regardless of the hardware they are developing on.

You could say, shame on AMD for not helping the devs......and if they don't watch themselves we might end up with GamesWork 2.0 thanks to DX12 being harder to write for....which means devs will turn to tools to help them code faster.

Yes except this time it's AMD providing "ComputeWorks" with any luck.

[Jimbo75]

Didn't take long for the AMD fanbios to surface I see.
Shame one doesn't even know async compute isn't a requirement of DX12.

I'm surprised you even want to talk about async compute after your last laughable rant about it all being down to Oxide and how Fable would be a true DX12 benchmark. How did that one work out?

[watercooled]

https://developer.nvidia.com/dx12-dos-and-donts#dx12

Do's
•Use hardware conservative raster for full-speed conservative rasterization
◦No need to use a GS to implement a ‘slow’ software base conservative rasterization
◦See https://developer.nvidia.com/content...-rasterization

•Make use of NvAPI (when available) to access other Maxwell features
◦Advanced Rasterization features
◾Bounding box rasterization mode for quad based geometry
◾New MSAA features like post depth coverage mask and overriding the coverage mask for routing of data to sub-samples
◾Programmable MSAA sample locations
◦Fast Geometry Shader features
◾Render to cube maps in one geometry pass without geometry amplifications
◾Render to multiple viewports without geometry amplifications
◾Use the fast pass-through geometry shader for techniques that need per-triangle data in the pixel shader
◦New interlocked operations
◦Enhanced blending ops
◦New texture filtering ops

Don’ts
•Don’t use Raster Order View (ROV) techniques pervasively
◦Guaranteeing order doesn’t come for free
◦Always compare with alternative approaches like advanced blending ops and atomics

so yes that's `DO use what we can do well and Don't use other stuff our competition can use well

You know what I was saying about software conservative rasterisation being a thing?

However if I understand their wording correctly, they do at least seem to be asking devs to not squander resources on things like ROVs unnecessarily. Seems like good advice for graphics features in general TBH.

WRT 'async ain't DX12', Nvidia are suggesting that devs 'make use of NvAPI...'. That's really not part of DX12, and not platform-neutral either. As I've said before, not being a requirement of DX12 is pretty much just an academic argument if it's available to use and actively utilised by devs in parallel with DX12 features.

Having done a quick ctrl+f for async, this is about all I found:

Check carefully if the use of a separate compute command queues really is advantageous

Even for compute tasks that can in theory run in parallel with graphics tasks, the actual scheduling details of the parallel work on the GPU may not generate the results you hope for
Be conscious of which asynchronous compute and graphics workloads can be scheduled together

Well yeah, assuming the Maxwell async deficiency is a thing, I'd say that's a round-about way of telling devs to be careful about it? Those 'actual scheduling details' being the crux of the matter.