Hi guys,

I'm looking for people who are familiar with D3D11 and the new shader resource types which allow GPU/CPU access to the resource (ComputeShader type resources). I am trying to create a 1D texture resource which both the CPU and GPU can access for read/write operations. I am aware that the usage for this kind of a texture must be D3D11_USAGE_STAGING however I'm having issues getting the device to create for me the resource. My D3D11_TEXTURE1D_DESC looks like this:

D3D11_TEXTURE1D_DESC td = {};
td.Width = 3;
td.ArraySize = 1;
td.MipLevels = 1;
td.Format = DXGI_FORMAT_R32_UINT;
td.Usage = D3D11_USAGE_STAGING;
td.CPUAccessFlags = D3D11_CPU_ACCESS_WRITE | D3D11_CPU_ACCESS_READ;
td.BindFlags = D3D11_BIND_SHADER_RESOURCE;

My intention that the texture would look something like this in memory:

unsigned int tex[] = {0, 0, 0}

The texture desc structure works when the usage is changed to D3D11_USAGE_DEFAULT and the CPUAccessFlags is changed to 0. This however breaks what I am trying to acheive as it removes any hope fo the CPU getting access to the modified data in the shader.

Has anyone been able to successfully use a 1DTexture as a resource type for CPU read/write access? I would be binding this to the pixel shader by the way. Thanks for any help you can provide!

Thanks for the reply!

I understand what you are saying and I just got the resource to create based on your suggestions. My reference material is a book titled "Practical Rendering & Computation with Direct3D 11" by Zink, Pattineo and Hoxley and in their chapter on D3D11 resources they have a table where they describe various GPU/CPU access for each usage type. For the staging type they put GPU/CPU access as full read/write. This led me to assume I could bind a buffer with CPU read/write access to the pipeline. However based on what you are saying (and what I just read through again on MSDN) a staging only has CPU read/write and must copy from another buffer (in my case default probably) which can bind to the pipeline. I set my bind flag to 0 and the resource created properly.

Also I'd like to describe my attempted implementation to see if what I am doing can be accomplished more easily another way. I want to implement mouse over detection through my render component for game entities. My assumption is that I need to make this test in the pixel shader after the data has been fully transformed to projection space and passed through the raster state. Since windows has a mouse hot point described by a single pixel I figured I wanted to compare its position against pixels rendered for the entity I am testing against. The data given to the pipeline is the position of the mouse in x,y coordinates with an extra element to use as a bool flag. When the pixel shader detects that it is operating on a pixel which shares its location with the mouse hot point, the shader will set the bool flag to true. I can then detect that the object is moused and perform whatever else I want for the next passes. Does that sound reasonable? I do have a concern for overhead but not so much that it will stop me from an attempted solution (I can optimize later after the engine implements the functionality I desire).

Thanks again!

Thank you for the reply Jason! I realized shortly after I made that post that I was responding to one of the authors! I am very excited to be communicating with the two of you! I have really enjoyed learning from your book. It has been an amazing asset!

After reading what Matt said and re-reading the passage in question (pages 30-31) I see that I did not read carefully/did not understand entirely. The staging usage (pg 31) section clearly describes the concept that a resource must be copied into a staging resource after being manipulated by the GPU. I think my confusion arose from the combination of the table on page 30 (Table 2.1) and the passage about the Staging Usage on page 31. I made the assumption that the same resource would be used for GPU manipulation and CPU access. I see now how that is incorrect.

I really appreciate you guys responding to my post and again I am learning tons from your book!

In response to your question I have created an UAV with a Byte Address buffer resource bound to the output merger. As far as I understand, the Pixel Shader has access to this view and will be able to write to the resource behind it. I've got the resources created, view created, and it binds. I haven't yet mapped memory back into CPU space, however.

Well, the implementation is complete! It works like a charm. Thank you for your input gentlemen. If you are interested I would very much appreciate some critique of my code!

Actually, MJP is the Pettineo and I'm the Zink from your list of authors Can you please specify more precisely where in the book something is unclear about the resource usage? If it would help others, then I can add a mention of something like that on the Hieroglyph 3 codeplex page.

Be honest, you loved saying that :)