Jump to content

  • Log In with Google      Sign In   
  • Create Account


Using the same texture buffer as SRV and UAV simultaneously on the same compute shader


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
11 replies to this topic

#1 meirivry   Members   -  Reputation: 100

Like
0Likes
Like

Posted 26 April 2012 - 10:34 PM

Hi,

I have a 2D texture buffer that I use on a compute shader.

I nead read access to it using SampleLevel method and a write access to it.

Since SampleLevel is defined for Texture2D buffer and not for RWTexture2D - using it as UAV only is not an option.

Can I use the same texture as Unordered Access View and as Shader Resource Views simultaneously on the same compute shader?

Thanks,
Meir.

Sponsor:

#2 DementedCarrot   Members   -  Reputation: 417

Like
0Likes
Like

Posted 26 April 2012 - 11:01 PM

Per http://www.gamedev.n...compute-shader/, it doesn't look like you can.

You'll probably have to create your mipmaps yourself, save them to separate UAV's, and if you're drawing with them later to use texture arrays.

Or just load the same texture in twice as a UAV and SRV, whilst reading on one and operating on the other.

#3 meirivry   Members   -  Reputation: 100

Like
0Likes
Like

Posted 26 April 2012 - 11:45 PM

So, what you're saying is that it is possible to load the same texture in twice as a UAV and SRV at the same time.
Right?

#4 meirivry   Members   -  Reputation: 100

Like
0Likes
Like

Posted 26 April 2012 - 11:56 PM

BTW, my Texture was created with MipLevels = 1.
I call SampleLevel method with level=0 and I think I don't have to worry about mipmapping.

#5 BlueWanderer   Members   -  Reputation: 122

Like
0Likes
Like

Posted 27 April 2012 - 12:04 AM

I think one resource cannot be input and output at the same time.

If an overlapping resource view is already bound to an output slot, such as a render target, then the method will fill the destination shader resource slot with NULL.


Guess you will need put the result in the shared memory and do the filtering yourself.

#6 meirivry   Members   -  Reputation: 100

Like
0Likes
Like

Posted 27 April 2012 - 12:32 AM

OK.

What if I create 2 textures and I run my compute shader several times:

First time texture#1 is passed as SRV, and texture#2 as UAV.
Second time texture#1 is passed as UAV, and texture#2 as SRV.
Third time texture#1 is passed as SRV, and texture#2 as UAV.
and so on... every call the compute shader I switch the two texture roles.

Will that work?

#7 Hornsj3   Members   -  Reputation: 191

Like
0Likes
Like

Posted 27 April 2012 - 01:04 AM

You can't bind the same resource to an SRV and UAV at the same time.

If you want to read to and write from a UAV in a Compute Shader, try using the RWTexture2D in your shader code instead of Texture2D. Is there some reason you need SampleLevel?

You can do two dispatches, as you suggest. You will need to bind the SRV, dispatch, bind the SRV slot to a NULL SRV (I guess technically an unbind, and it is required), then bind the UAV, and dispatch again.

#8 DementedCarrot   Members   -  Reputation: 417

Like
0Likes
Like

Posted 27 April 2012 - 03:22 AM

So, what you're saying is that it is possible to load the same texture in twice as a UAV and SRV at the same time.
Right?


I literally mean to load the texture two separate times, and set one as a UAV, and one as an SRV.

#9 Bacterius   Crossbones+   -  Reputation: 8158

Like
0Likes
Like

Posted 27 April 2012 - 03:37 AM

I literally mean to load the texture two separate times, and set one as a UAV, and one as an SRV.

Yes, of course, as said in the quote, you can duplicate the texture and use it both as an SRV and a UAV, the idea is that you can't use the same resource (object). You can use two textures because they are different resources even if they happen to contain the same data.

But why would you want to? You can read from an UAV. I can't think of a situation where you would need the same texture in both places (rather, I can imagine when you'd need to have a read-only version of the texture as SRV and a blank UAV to write your results).

If you need to chain compute shaders multiple times you can swap the SRV and UAV at each step, but it needs to be done properly (if you don't unbind stuff in the right order the runtime will screw it up and leave you with one texture bound and the other dangling).

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#10 meirivry   Members   -  Reputation: 100

Like
0Likes
Like

Posted 27 April 2012 - 04:41 AM

But why would you want to? You can read from an UAV.


I don't need to read a pixel value at a descrete location but rather to sample at a relative location (in the same manner TEXCOORD is used in VS and PS).

Is it enough to unbind the SRVs and UAVs after each iteration or do I need to dispose them and create new ones each time?

#11 Bacterius   Crossbones+   -  Reputation: 8158

Like
0Likes
Like

Posted 27 April 2012 - 04:54 AM

Is it enough to unbind the SRVs and UAVs after each iteration or do I need to dispose them and create new ones each time?

Yes, you can unbind them and reuse them (I used to just swap them after each iteration if I need to chain multiple iterations in a feedback fashion). Just make sure you unbind them in the right order (or just to be sure, unbind them both first, them bind them back).

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#12 meirivry   Members   -  Reputation: 100

Like
0Likes
Like

Posted 27 April 2012 - 05:19 AM

Thanks a lot.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS