Sign in to follow this  
SBOrf

Are there alternatives to PIX for Windows?

Recommended Posts

So Pix for the 360 is pretty awesome, but PIX for Windows seems to be lacking significantly in comparison (at least the version I'm using is.) For me it crashes a lot, and I'm having trouble getting it to work at all for our tools. Our tools use the same game engine as our game, however they use a swap chain as there may be more than one render window in a tool. This is contrary to the game, which renders to the normal backbuffer. I don't know why this would result in PIX not working properly, but it's my suspicion since the only DirectX event logged is the D3D Present call on the swap chain. I need to see the events that happen when composing the frame I'm presenting, in order to track down a bug. I'll have to check tomorrow what version I'm using, but in the meantime, does anyone know any magic I could try to make PIX for windows work better? I tried briefly to setup the user defined events (http://msdn.microsoft.com/en-us/library/bb173087(VS.85).aspx), but they didn't show up (they were probably stuffed along with the rest of the missing info.) If there's nothing I can do to get it to work, is there an alternative app I could try? Thanks in advance, -Orf

Share this post


Link to post
Share on other sites
I don't know of any better tools, but yes, PIX has some irritating bugs. If you can reproduce the issue with a minimal example, it may be worth your while to send a bug report as well as the repro code to directx at microsoft.com. They do fix bugs eventually if they know about them.

PIX works by intercepting D3D calls from your application - it injects a special library that gathers the D3D calls from your program to a capture stream, analyzes the calls and their timing, and reports its findings to you.

If you know how to inject a custom D3D library, the basics of writing such a program aren't so difficult. However, the internal details of D3D calls are largely hidden from the public, so interpreting the captured data of many of the more complex operations (mainly shader stuff) is very difficult. Even though the D3D team obviously has the full specs of the API, this difficulty is the main reason of the bugs in the PIX software itself.

In order to give PIX as much data as possible, be sure to:
-Create the device in debug mode.
-Create all your shaders and effects in debug mode.

Share this post


Link to post
Share on other sites
Depending on what you're trying to debug, NVidia's NVPerfHUD can sometimes help. It's designed for different scenarios than PIX, though (for example, it doesn't do shader debugging)

Share this post


Link to post
Share on other sites
One thing that might help is to run PIX with explicit admin rights, if you're on Vista or 7. It requires some permissions to write to the target directory. In normal development, this is usually not an issue since the projects usually live in your "own documents" directories for which you have full access as standard user anyway.

Share this post


Link to post
Share on other sites
Over the years I've seen PIX do all kinds of wacky things...but I've never seen it swallow events before. That one's new to me.

What sort of capture settings are you using? Have you been messing around with those to see if you get different results?

Share this post


Link to post
Share on other sites
NVPerfHUD is useful as an additional tool but isn't really a replacement for PIX. I don't know of anything else out there that offers similar functionality. A couple of things worth checking though:

- Make sure you're using the PIX from the latest DirectX SDK (it tends to get updates with most SDK releases).

- Make sure you can run without errors (and ideally without warnings) reported under the Debug D3D runtimes with the warning levels cranked up. I've had problems with PIX that have gone away when I fixed warnings in the D3D debug spew.

I'd also suggest using the 64 bit version of PIX if you're on 64 bit Windows (and you really should be for development these days). It has a lot more memory to play with and PIX can be pretty memory hungry when doing captures.

Share this post


Link to post
Share on other sites
This is a almost irrelevant, but you don't have to use multiple swap chains in order to render to multiple windows. I looked into this when I started writing an editor, and I found that rendering the scene separately for each window (viewport) works very well for me without the considerable memory overhead of multiple swap chains (one for each viewport window). Plus, I can resize those windows without having to reset the device.

To do that, initialize the device in windowed mode with a back buffer the size of the desktop area, then when rendering to a window, set the D3D viewport to be the size of the client area of that window, call BeginScene(), render, EndScene(), then Present( hWnd ), where hWnd is the handle of the window being rendered to. But you'll want to disable vsync or your frame rate will be capped to RefreshRate/numWindows.

Share this post


Link to post
Share on other sites
Thanks everyone, for some good responses.

RE: hikikomori-san - I know I looked into removing our swapchain code in our tools a few months ago and found it to not be possible for some reason, I believe it was VRAM related... our postprocessing code requires duplicate surfaces and such. Initializing them to the screen size and bpp ate up vram at an impressive rate, such that they wouldn't work on all our artist's machines. You did actually inadvertanly provide the solution to another bug I had to fix, as the swapchain present call has an hwnd override as well, which is great when you're dealing with rendering to many windows of the same size. One renderer to rule them all. :) So thanks for that!

RE: Niko and mattnewport, I'm actually running WinXP, as are all our devs here. XP still commands the lionshare of the home pc OS market so we need to target our PC release to work on it, so permissions aren't an issue. I agree though, 64bit OS with more ram would be much better to dev on in general. Maybe we'll get Win7 in here.

and finally, RE: MJP - Thanks for pointing out that I haven't tried messing around with the different capture settings. I've been setting my experiment's up to do single-frame capture whenever F12 is pressed... I tried switching it to a replayable d3d call stream, saved to a file. It results in something like a 650mb file for a min and a half of running time, none of the surfaces are recreatable, but it DOES show me the call stream. I can use that to compare it to the PC version of our game and hopefully it'll show why the game properly gives our fog shader the depth buffer texture, and why our tools do not. It's going to be arduous, but I think I can make that work for me.

Thanks again everyone!

Share this post


Link to post
Share on other sites
If people are using windows XP but on a limited access account (non admin) then they will have the same issue faced by Vista/Win7 users - no write access to c:\program files and the root c:

in case you're not aware :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this