Sign in to follow this  
Mathucub

Attempting to debug with PIX, no luck.

Recommended Posts

Is anyone out there successfully using PIX for windows to debug vertex and pixel shaders? I can't get it to work. I've tried the device in HAL/REF i've tried changing between SW/HW vertex processing. PIX by itself isn't stable to me. We use the Rouge Wave/Stingray studio MFC extensions to do our UI. If it is enabled, PIX crashes automatically on my first GDI+ calls. There are a few times I get a valid capture; however, when I got to debug the shader PIX crashes. It will give me the source to the shader in PIX if I tell fxc to compile with symbols--so I know it at least partially works. We've got some really complex lighting shaders and the users can enable and disable lights at will in our scene--so I need to be able to see what the shaders are doing. FXComposer has shader debugging--but there is obviously no way to feed it the runtime information from our scenes. I used to be able to debug in vs2003. Can we start a petition to add shader debugging back to vs2005? Does anyone have any advice?

Share this post


Link to post
Share on other sites
I generally find PIX unstable, though i have had a large amount of success debugging with it. Have you tried any of the following flags as well as software vertex programming?

Look here.

I believe you need to use:

D3DXSHADER_DEBUG
D3DXSHADER_NO_PRESHADER
D3DXSHADER_OPTIMIZATION_LEVEL0
D3DXSHADER_SKIPOPTIMIZATION
D3DXSHADER_SKIPVALIDATION

The reason 2005 doesn't support shading debugging in the IDE is because they want you to use PIX which, although slightly trickier to get started debugging in, is far more powerful.

Share this post


Link to post
Share on other sites
Try to use the most recent DirectX SDK. PIX keeps crashing on me as well, but everytime Microsoft releases a new SDK, there's one point in the changelog called "Improved PIX stability". Well... good luck. I haven't been able to debug shaders in a while now. I know it worked for me some time, but I never managed to repeat it, neither on WinXP64 nor on WinVista32.

Share this post


Link to post
Share on other sites
Quote:
Original post by Schrompf

Try to use the most recent DirectX SDK. PIX keeps crashing on me as well, but everytime Microsoft releases a new SDK, there's one point in the changelog called "Improved PIX stability". Well... good luck. I haven't been able to debug shaders in a while now. I know it worked for me some time, but I never managed to repeat it, neither on WinXP64 nor on WinVista32.


I'm using the pix from the jun sdk. We can't upgrade our codebase to use it.
They 'cleaned up' the d3d9caps.h header and removed a few data structures we have code that points to. Grrr... MS is making my life difficult at the moment.


Quote:
Original post by Dave

I believe you need to use:

D3DXSHADER_DEBUG
D3DXSHADER_NO_PRESHADER
D3DXSHADER_OPTIMIZATION_LEVEL0
D3DXSHADER_SKIPOPTIMIZATION
D3DXSHADER_SKIPVALIDATION



We have to compile our shaders off line. FXC uses the same functions as the dx9 device, so I get the same final code.

I tried:
/Vd (don't validate)
/Op (don't preshader--this is always off, preshaders kill our effects)
/Gec (auto upgrade an 1_x shaders to 2)
/Zi (include symbols)
/D DEBUG=TRUE (enables my uv and normal exploring techniques)
/Od (disable optimization)


I tried the assorted vertex and device modes in the device creation. Only difference is in REF I don't even get an option in PIX to see the shader: it only has the final framebuffer value.



...I think I figured out a sneaky method of debugging the shaders.
I'll post it if it works.

Share this post


Link to post
Share on other sites
My sneaky trick didn't work... tried to connect vs2003 to the application an intercept the D3D calls. CPU usage went to 100%, but both UI's died.

On the brighter side I got PIX to work.

I had to use the reference rasterizer, and set D3DCREATE_SOFTWARE_VERTEXPROCESSING|D3DCREATE_MULTITHREADED as the behavior flags.

Its still about as stable as Charles Manson. I don't get the option to debug the shaders every capture. Its hit or miss. And if I resize the PIX window with the shader debugger window opens it crashes.

Thanks for the input, guys.

Share this post


Link to post
Share on other sites
I have found PIX for Windows to be extremely unstable, but if I refuse to give up and run an experiment 4 or 5 times in a row, switch to the debug directx runtime, et cetera, eventually I will end up with a .PIXRun file that is usable.

Share this post


Link to post
Share on other sites
Hi, I am a tester on the PIX-Windows team. If you are having problems debugging your vertex/pixel shaders and you are using the latest June SDK, I would be very interested in seeing a problematic run file that you are producing.

For the June 2008 SDK, we made several stability improvements, especially around the debugging of shaders. If you can send me a run file that crashes, we may be able to analyze the issue and quickly determine what is causing PIX to crash.

If possible, please send the run file and any questions to matlopatmicrosoftdotcom.

We hope that we can make PIX-Windows stable and reliable for anyone using it. I encourage everyone to try out the latest version of PIX-Windows in the June SDK, as several reliability issues were addressed.

Thanks.

Share this post


Link to post
Share on other sites
Quote:
Original post by matlop
Hi, I am a tester on the PIX-Windows team. If you are having problems debugging your vertex/pixel shaders and you are using the latest June SDK, I would be very interested in seeing a problematic run file that you are producing.

For the June 2008 SDK, we made several stability improvements, especially around the debugging of shaders. If you can send me a run file that crashes, we may be able to analyze the issue and quickly determine what is causing PIX to crash.

If possible, please send the run file and any questions to matlopatmicrosoftdotcom.

We hope that we can make PIX-Windows stable and reliable for anyone using it. I encourage everyone to try out the latest version of PIX-Windows in the June SDK, as several reliability issues were addressed.

Thanks.


I will try to get posting to you as soon as possible. I was already using the newest SDK. It wasn't much better than its prior relatives. Its got lots of 'order of operations' problems where we have to start up out app in a manor that is not typical, then settle into a normal running pattern.

Fighting Ref rast vs. 8800 vs. 7950 having different output problems now. Thanks in advance.

Share this post


Link to post
Share on other sites
I don't quite understand what you mean by "orders of operations" when you are attempting to profile your game under PIX, but if you could elaborate more on this in your email, that would be great.

Please let me know when you send your questions.

Thanks.

Share this post


Link to post
Share on other sites
PIX Crashes our application...
By "Order of Operations" I meant that to make it run, I have to disable large blocks of code.

The current [major] pain is with our shaders. We are using the newest PIX; and are stuck using decembers dx9 sdk.

We have lots of 2d special effects for sports broadcast.
Crossfade, Gradient Wipe, Shine Reveal, etc. [about 30 internal transitions].
We also allow users to load .fx files.

We still have to support fpp only, and shader model 2 only hardware for offline editing. The only real way to see if a particular effect works is to try to validate it with D3DX.

We rip through all our effects with the D3DX CreateEffect functions. With PIX attached after about 3 effects we crash under the hood in D3DX. If I use the "give me time to attach a debugger" option in PIX, then we crash a little later deep in PIXHelper.dll.

Sometimes; it works. Of the times it works, I typically don't get shader debugging information or textures in the frame debugger. It typically takes ~8 times to get a trivial PIXRun that has any practical information without PIX itself giving up and saying it can't read the file.

Hardware, Ref Rast, and even the .net rgbrast software renderer all give simmilar results. Ref rast being the most unstable. Hardware and the sw don't catch shaders/textures so are of no help.


The major issue is that PIX doesn't even work relyably for our trivial cases. [Eg, an NTSC sized scene with a single textured quad with an effect activated]

Some of our 'on-air' scenes have 10+ effects in one template.

Short of breaking out a voodoo doll and threatening the software I've pretty much at the point of having to give up on the tool.

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