Overclock.net banner

[DSOG] Microsoft introduces tool that analyzes the performance of DX12 games.

2K views 16 replies 14 participants last post by  dragneel 
#1 ·
Source

Quote:
Thanks to its main modes, PIX can debug and analyze the performance of Direct3D 12 graphics rendering, offer captures to the developers for undestanding the performance and threading of all CPU and GPU work carried out by their game, and provide insight into the memory allocations made by their game.
Quote:
The good news is that PIX supports both UWP and Win32 applications (however it is limited to 64-bit apps only).
Hopefully this improves the quality of future DX12 titles, they've been a bit of a letdown (there are a couple exceptions) so far.
 
#2 ·
That source article fails to mention the limitations (aside from only supporting 64-bit):

http://wccftech.com/microsoft-introduces-pix-pc-dx-12/
Quote:
You should also be mindful of the following notes before using the software.

  • PIX only supports capturing D3D12 content, not D3D11 or 11on12.
  • PIX only supports 64-bit apps (both UWP and Win32). PIX does not support x86 apps.
  • PIX only captures data from the specific process that it launched or attached to. It does not support child processes. If your title uses multiple processes, you will need to bypass any client/launcher processes and have PIX launch/attach the main game executable.
  • Counter values other than timing in the event list are not currently rolled up to their parent bundle or marker region.
  • GPU captures are not generally portable between different GPUs or even different drivers on the same GPU. PIX will warn if you attempt to run analysis on a capture whose capture device differs from the current playback device. You can continue past this warning, but be aware there may be compatibility issues that cause it to fail.
  • GPU captures do not currently overlap GPU work on different queues. If your app uses asynchronous compute to execute rendering and compute work simultaneously, it will show up in the timeline as being executed in a non-parallel fashion.
  • PIX does not support multi-GPU enabled apps. You can use it on a machine with multiple GPUs, but PIX will always capture/playback on the primary adapter.
 
#5 ·
Quote:
Originally Posted by GorillaSceptre View Post

Good info, I won't edit the OP as your post is up top anyway..

Quote:
PIX does not support multi-GPU enabled apps.
That won't really make a difference considering the support of CF/SLI these days..
redface.gif
no need for SLI/CF support if dx12 can handle that w/o driver profiles, no?

anyhow looking at the roadmap on MS's site:
Quote:
PIX is far from finished: we have a long list of things we'd like to improve and add. This list is both incomplete and uncommitted, so no guarantee that we'll actually ever do all these! But we wanted to share it anyway, to give you some idea of where we are likely to go next, and to get your feedback about priorities and what we are missing.

  • GPU hardware counters to give richer low level performance information.
  • Dr. PIX experiments provide "what-if" scenario analysis and GPU optimization advice.
  • Roll up event list counter values to their parent bundle or marker region.
  • Graph counter values along the GPU timeline.
  • Warnings to identify common performance problems and API usage mistakes.
  • Shader edit & continue (change a shader directly inside PIX, and immediately see how the rendering output and performance changes as a result).
  • Realtime system monitor displays counters such as framerate, CPU and GPU utilization, memory usage, video memory paging activity, disk and network usage, etc.
  • Tools to help with debugging GPU hangs (aka. TDR).
  • Tools to better understand video memory usage and paging.
  • Tools to artificially simulate running on a GPU with less video memory, TDR, and display changes such as monitor add/remove.
  • Timing captures should show GPU signals/fences and CPU thread names.
  • Better support for the 'bindless' GPU resource access model (displaying what resources are used even when a shader selects them dynamically from an unbounded descriptor heap).
  • Rendertarget visualizers such as wireframe and overdraw modes.
  • API summary statistics (how many draw calls, resource barriers, etc.)
  • View individual sample values within MSAA surfaces.
  • Support multiple GPUs (PIX currently always just runs analysis on the primary GPU).
  • Support launcher processes (where the entrypoint process launches another, and it's the second one that PIX ought to capture from).
  • File IO captures for helping you optimize your title's reads and writes and for identifying inefficiencies in your packaging strategy.
  • Support for optionally collect Performance Monitoring Counters in Function Summary and Callgraph captures.
  • Assembly level instruction tracing to help you identify candidates for micro-optimizations within a function.
  • The ability to take captures programmatically.
the intro page; which has links that are more informative than either DSOG or WCCF . . .

https://blogs.msdn.microsoft.com/pix/introduction/
 
#6 ·
#8 ·
Quote:
Originally Posted by littledonny View Post

Show me a DX12 title that supports multi GPU. If Frostbite doesn't, what will?
 
#9 ·
^to add to that^

this is been around for a year now:



how multi gpu was meant to be done.
thumb.gif
 
#10 ·
Since when was Win32 support in Windows a "feature?"
 
#11 ·
Quote:
Originally Posted by GorillaSceptre View Post

Good info, I won't edit the OP as your post is up top anyway..
That won't really make a difference considering the support of CF/SLI these days..
redface.gif
Which really upsets me because Crossfire and SLI have been a technology for YEARS and it's something that plenty of people would like to use (including myself) but no one wants to program for it. Seriously.
 
#14 ·
So, this tool penalizes AMD's cards for having better async compute by inducing devs to skip it to take advantage of the tool?
Quote:
Originally Posted by motoray
Probably just another way to force ppl to upgrade. Otherwise i can get another fury nano on the cheap and be good for atleast 2yrs.now amd n nvidia can just blame devs and hold no responsibility.
Notice, also, how the trend coincides with AMD not having top-end cards. Nvidia would gladly sell everyone a 1080 for a premium price.
 
  • Rep+
Reactions: LAKEINTEL
#15 ·
Quote:
Originally Posted by superstition222 View Post

So, this tool penalizes AMD's cards for having better async compute by inducing devs to skip it to take advantage of the tool?
Or the current version of the tool can't properly capture async compute yet.

But I'm sure your tinfoil hat theory is more likely.
 
#16 ·
Quote:
Originally Posted by RadActiveLobstr View Post

Or the current version of the tool can't properly capture async compute yet.

But I'm sure your tinfoil hat theory is more likely.
Does aluminum foil make people smart enough to not release something until it's adequately functional?

Async compute is a basic feature of DX12.
 
  • Rep+
Reactions: LAKEINTEL
#17 ·
Quote:
Support multiple GPUs (PIX currently always just runs analysis on the primary GPU)
At least the wording is hopeful. "Currently".

I don't necessarily see it as a bad thing to leave out support for what are essentially non-critical features early on as a bad thing either (As long as they do actually work on them later of course).
That's my take as an average consumer anyway, I don't know anything about game development and therefore have no idea how useful this tool will actually be, but at face value it sounds like a good thing that Microsoft is providing tools like this.
 
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top