Wavesize issue in GetWaveBroadcastSourceLaneIndex on AMD affecting motion blur

Development Rendering
, ,
1

Hi,

We would like to report about an issue we faced when using motion blur + TSR, where the edges of our player object (center of the screen, third person camera) were bleeding into blocky/floaty garbage pixels around them on AMD Radeon RX 9070 XT (this is UE 5.4.3). After investigation:

  • The garbage around the edges of our player object came from the output of TSRDilateVelocity.usf, which contained the blocky artifacts (ClosestDepthOutput、VelocityFlattenOutput, all looking clean on Nvidia but with blocks on the edges on AMD, using DumpGPU). This in turn confused MotionBlur’s TileClassification and made the artifacts visible in MotionBlurApply.usf when motion blur was enabled (we can see the difference in tile classification by enabling MotionBlurCommon.ush’s DEBUG_MOTION_BLUR_OUTPUT and using vis Debug.MotionBlur.FilterTileClassify).
  • The reason appears to be that TSRDilateVelocity.usf uses InitWaveXorButterfly/WAVE_BROADCAST_GCN_SWIZZLE/GetWaveBroadcastSourceLaneIndex, and if we are not mistaken it seems the code around there wasn’t written with 64 wavesize in mind (WaveGetLaneCount() returns 64 on AMD Radeon RX 9070 XT whereas on Nvidia it is 32).
  • We did a couple of tentative quick fixes to the intrinsics wrapper code and InitWaveXorButterfly to support 64 wavesize, they seemed to be effective, but we decided that setting WAVESIZE(32) on TSRDilateVelocity.usf (in a way other platforms are not affected) was the safest and simplest way to deal with the issue. Because we know that is what Nvidia is already doing anyway, so nothing should change there. And platforms with WaveGetLaneCount() 64 should now work as intended.
  • We think that TSRDecimateHistory.usf and MotionBlurApply.usf are also candidate for WAVESIZE(32) workaround as they use InitWaveXorButterfly and don’t seem to use WAVESIZE(32), CFLAG_Wave32, or the other alternatives (unless we missed/misunderstood something).

For TSRDilateVelocity.usf we had to take action since motion blur was affected visually.

For TSRDecimateHistory.usf and MotionBlurApply.usf we don’t have any visible issue or anything reported on AMD yet, but we feel that preemptively use WAVESIZE(32) on them is safer (at the very least, nothing should get worse). We would appreciate some confirmation on that (even if just as an opinion).

Best Regards.

[Attachment Removed]

2

Hi Jerome,

Thanks for the report and yes. This is an issue on AMD card that supports 64 wavesize. Please keep your fix and we will submit a fix to Main as well.

Thanks,

Tiantian

[Attachment Removed]