Thanks for the responses... I was writing this up and found the issue and have resolved it... still not certain why its an issue.. maybe the clamping issue you spoke of "Dancin Fool"... I've included the shaders I was using incase anyone is able to give me any more insight.

While writing this post I saw the differences in my shaders in the use of the depth : TEXCOORD0 parameter in the struct and being used in the poly shader.
For the point clouds I figured since I only need points I shouldn't use a pixel shader thats why the 2nd shader only uses a vertexShader.

I've switch the struct used to the one in the poly shader and added the same pixelShader and now I have proper depth.

As a test I also tried switching the poly shader to write to color.w in the vertex shader and left out the color.w = depth from the pixelShader, and sure enough even the polys were then clamped at 1.

Any one know why this extra step is necessary?, Why can't a vertex Shader write floating values to the screen? And does the VertexFormat used while passing the draw codes matter once the data is pushed to the gfxCard? (I would think not since my VertexFormat Struct in Slimdx doesn't even have texture coordinates in the first place)

From shader-model 3.0 an onwards, you can't just use a vertex-shader by itself, it always needs to be paired with a pixel shader.

In your case, where you're not supplying your own pixel shader (and using shader-model 2.0), you're asking the driver to automatically write one for you and I wouldn't trust it to do the right thing, especially when it comes to advanced features like floating-point render targets.

Anyway, as Dancin_Fool said, the issue is that you're trying to pass your floating-point value through a colour register. As this page says: "Color registers ... have lower precision than most registers, guaranteed to have 8 bits of unsigned data in the range (0, +1)."

You should be using a tex-coord register to pass your floating point value to the pixel shader.