[2.1+] possible issue with compute passes Topic is solved

Discussion area about developing with Ogre2 branches (2.1, 2.2 and beyond)
Post Reply
al2950
OGRE Expert User
OGRE Expert User
Posts: 1200
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 76

[2.1+] possible issue with compute passes

Post by al2950 » Wed Mar 13, 2019 7:11 pm

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?
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4077
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 231
Contact:

Re: [2.1+] possible issue with compute passes

Post by dark_sylinc » Thu Mar 14, 2019 12:23 am

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.
0 x

al2950
OGRE Expert User
OGRE Expert User
Posts: 1200
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 76

Re: [2.1+] possible issue with compute passes

Post by al2950 » Thu Mar 14, 2019 9:39 am

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.
0 x

Post Reply