🔒 Locked

Without D3DXSHADER_USE_LEGACY_D3DX9_31_DLL shader runs very slow

Started by lubby May 28, 2008 at 12:13 PM 7 replies 3.6k views

Original Post

May 28, 2008 at 12:13 PM

I understand that the #define D3DXSHADER_USE_LEGACY_D3DX9_31_DLL enable the use of the original Direct3D 9 HLSL compiler from Oct 06. But as far as I can tell it only allows the promotion of ps1.3 shaders to ps2.0. So any clue as to why a ps/vs 3.0 would run around slower when not using this compiler flag? I am using the DirectX 9 effects system and D3DXCreateEffectFromFile() with the flags D3DXFX_NOT_CLONEABLE | D3DXSHADER_USE_LEGACY_D3DX9_31_DLL. Once I remove D3DXSHADER_USE_LEGACY_D3DX9_31_DLL it all slows to a crawl. Setting the flag to 0, or adding D3DXSHADER_OPTIMIZATION_LEVEL3 makes very little difference, I also tried different combinations of flow control also with minimal performance increase. D3DXSHADER_USE_LEGACY_D3DX9_31_DLL seems to be the real winner in this case. My pixel shader does use dynamic branching and removing this code does increase performance a lot when not using D3DXSHADER_USE_LEGACY_D3DX9_31_DLL Its not killing me, because I can happily use this define right now, but just very curious as to what is going on.

Namethatnobodyelsetook

May 28, 2008 at 12:52 PM

They completely rewrote the shader compiler, and the new one never got ps.1.x support. As a workaround, until ps.1.x support is added (ie: Never), you can use this flag to use the older compiler.

As it's a completely different compiler, code generation and optimization are going to be different. I had no idea the old compiler was so bad that it had such noticable performance differences.

Perhaps you're best off trying to compile without the flag, and if it fails, try again with the flag. Better yet would be if the HRESULT told you it was an unsupported shader version, and you would retry only in that case.

Promit

May 28, 2008 at 1:15 PM

I'd suggest using PIX and NvPerfHUD to see if those can provide any insights about what's going on.

Adam_42

May 28, 2008 at 1:19 PM

You could try using a profiling tool like the ATI one at http://ati.amd.com/developer/gpusa/index.html to compare the two. It lets you switch between the various D3DX DLLs.

My guess would be that one compiler optimized better than the other one, or the output from the new compiler confuses the optimizer in the drivers. Have you got the latest drivers installed?

lubby

May 28, 2008 at 2:08 PM

Quote:
As it's a completely different compiler, code generation and optimization are going to be different. I had no idea the old compiler was so bad that it had such noticable performance differences.

It is actually the other way around in this case, performance is better when using the old compiler flag. /scratches head.

Quote:
I'd suggest using PIX and NvPerfHUD to see if those can provide any insights about what's going on.

Thanks, will do. My own profiling code is not helping much as it's all going on in the driver.

Quote:
My guess would be that one compiler optimized better than the other one, or the output from the new compiler confuses the optimizer in the drivers. Have you got the latest drivers installed?

I do have the latest Nvidia drivers installed. Thing is, way back in early 2007 in also noticed this performance hit. I notced when I updated to a new DirectX SDK. That is also when I originally changed the flag to use the old compiler. It was quick and easy way to get my framerate back I had forgotten about it until the other day when I was refactoring some code and removed the flag. Suddenly I lost all that frame rate again. I just assumed that it would have 'been fixed' by now. I almost have no doubt I am doing something bad as it is unlikely a bug in the compiler would escape detection this long. Hopefully perfhud/pix will help out.

Demirug

May 28, 2008 at 2:27 PM

Have you compared the assembler output of both compiler versions?

ET3D

May 28, 2008 at 5:05 PM

First of all, setting a few things straight:

The promotion of PS1.x to PS2 is something that the new compiler does (when you compile with D3DXSHADER_ENABLE_BACKWARDS_COMPATIBILITY).

The old compiler can compile PS1.x to PS3 directly.

IIRC the compilers have different defaults for conditions and loops. From what you say I gather you tried [branch] vs. [flatten] etc., but I still suspect that is the major difference.

Demirug's suggestion to compare the assembly code is a good one. It'd show you what the difference is.

lubby

May 28, 2008 at 8:42 PM

Quote:
Original post by ET3D
First of all, setting a few things straight:

The promotion of PS1.x to PS2 is something that the new compiler does (when you compile with D3DXSHADER_ENABLE_BACKWARDS_COMPATIBILITY).

The old compiler can compile PS1.x to PS3 directly.

Thanks, I already completely understand this. Never any doubt in my mind about this promotion as it is documented very clearly.

Quote:
Original post by ET3D
IIRC the compilers have different defaults for conditions and loops. From what you say I gather you tried [branch] vs. [flatten] etc., but I still suspect that is the major difference.

Demirug's suggestion to compare the assembly code is a good one. It'd show you what the difference is.

Going to do this just as soon as I can motivate myself. No I'm not asking anyone else to do it, Just thought that maybe someone had come across this before and knew exactly what it was. Playing with the new compiler flags had no serious impact on the shader speed though. So at a reach my shader is doing something in a way that the HLSL compiler is having issues optimizing. Probably something that as you say can not be unrolled or flattened. I will look into it more soon and post an update.

ET3D

May 29, 2008 at 6:01 AM

Let us know the results of your investigation. I'm sure it'd help others.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.