I am using a pixel shader to put some data into a texture. Typically, with a float4 formatted texture, you would output RGBA color data to the texture where each color component is a 0.0 - 1.0 float value. I'm trying to use the pixel shader to store non-color data. This texture is not meant for display. Instead, once the texture is filled, I convert the texture texels to a different binary format using a compute shader (due to the nature of the data, it makes sense for me to output this data with a pixel shader). When outputting to the texture from my pixel shader, I would like to store some uint values instead of floats in the Y, Z, W components. So here is an example of how I'm trying to return from the pixel shader:
[source lang="cpp"]
return float4(floatValue, asfloat(firstUintValue), asfloat(secondUintValue), asfloat(thirdUintValue));
[/source]
I do this because I don't want to cast the uint values to float, but rather maintain their binary equivalent.

However, when I read from the texture using my compute shader and convert these values back to uint using the asuint(texel.Y) function, they do not seem to be the same value I attempted to store in the first place. Actually, most the time I seem to get ZERO values out of this.

I know that I have supplied my compute shader with the texture as a shader resource properly, because I am able to retrieve the X component of the texels, which you'll notice above was a regular float (between 0.0 and 1.0).

Does the pixel shader require output to be 0.0 - 1.0 floats and do automatic adjustments otherwise?

Thanks you for your time and assistance.

In your case anything except for a 32-bit FLOAT format will mess up your values, because conversions will happen.

What kind of conversions? I just figured that since I was using the asfloat() function to store my UINT values, the texture would accept it as a float - how would the texture know the difference that it is actually a binary representation of a UINT? Unless the texture requires that the value be a value color-component value between 0.0 and 1.0.

Have you considered writing to a UAV in your pixel shader?

I'll have to think about this. The reason I'm doing it this way is because I actually am storing graphical data - I still take advantage of the way the pixel shader projects the data onto my texture using transformation matrices, and I also need it to take care of depth buffering and resolution. However, I don't care about color - instead I have other data to keep track of, which is why I was trying to use the color-component values to store other information.

Okay. The values I'd like to store consist of one float and 3 uint values. Think using DXGI_FORMAT_R32G32B32A32_TYPELESS instead of DXGI_FORMAT_R32G32B32A32_FLOAT would prevent unexpected conversions from occurring?

Well, after trying a few other ways to do this, I put it back to how I had it and... now it works! Magic. I have no idea what changed since my first attempt, but is now working as I'd originally expected. I apologize, as I feel like I wasted your time with this question. But now using a DXGI_FORMAT_R32G32B32A32_FLOAT texture, I'm able to store UINT values using asfloat() and asuint() to convert back and forth between Pixel and Compute shaders.