[2.1+] possible issue with compute passes Topic is solved
-
- OGRE Expert User
- Posts: 1227
- Joined: Thu Dec 11, 2008 7:56 pm
- Location: Bristol, UK
- x 157
[2.1+] possible issue with compute passes
So a Compute pass specifies UAVs and a compute job, the compute pass then updates the compute job on instantiation with the relevant UAVs. The problem arises if 2 different compute passes use the same compute job. The last compute pass will setup the compute job creating an invalid state for the first compute pass. Does that make sense?
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [2.1+] possible issue with compute passes
CompositorPassUav does nothing on creation due to this reason.
If a CompositorPassUav runs "MyJob" with certain params, CompositorPassUav::execute will set those params and run the job.
If another CompositorPassUav runs "MyJob" too, with different params, CompositorPassUav::execute will set the necessary new parameters so the job runs correctly.
That also includes setUavStartingSlot and co. You'll notice that compute passes override those settings (and will not restore them).
There are no race conditions either (i.e. modify data for the 2nd run while the 1st one is still using it). However races can happen if the job reuses Const/Tex/UavBufferPacked and they get modified from C++ while the compute job is running.
But you would only be able to do that if you modify those buffers from a listener; script-guided passes do not allow you to modify those buffers.
If a CompositorPassUav runs "MyJob" with certain params, CompositorPassUav::execute will set those params and run the job.
If another CompositorPassUav runs "MyJob" too, with different params, CompositorPassUav::execute will set the necessary new parameters so the job runs correctly.
That also includes setUavStartingSlot and co. You'll notice that compute passes override those settings (and will not restore them).
There are no race conditions either (i.e. modify data for the 2nd run while the 1st one is still using it). However races can happen if the job reuses Const/Tex/UavBufferPacked and they get modified from C++ while the compute job is running.
But you would only be able to do that if you modify those buffers from a listener; script-guided passes do not allow you to modify those buffers.
-
- OGRE Expert User
- Posts: 1227
- Joined: Thu Dec 11, 2008 7:56 pm
- Location: Bristol, UK
- x 157
Re: [2.1+] possible issue with compute passes
Thanks the response. And sorry I somehow completely missed the fact pass::execute calls setResourcesToJob every frame. I got caught up in the fact it was called on initialisation, which may not be needed, and that on initialisation it directly modifies the compute job, but that call only ensures there is enough UAV units available in the job.