HdLight::Sync may pass HdChangeTracker::DirtyVisibility in dirtyBits

[marktucker]

Description of Issue

Given the existence of HdLight::AllDirty, it seems like only bits in HdLight should even show up in the dirtyBits passed to HdLight::Sync. But HdDirtyBitsTranslator::SprimLocatorSetToDirtyBits can add HdChangeTracker::DirtyVisibility to the dirtyBits for an HdLight. I would expect an HdLight-specific dirty bit for visibility, or at least a clearer indication that the Sync call may receive non-HdLight dirty bits? This seems to be new in 21.11 (I believe this bit wasn't being set in 21.08).

Steps to Reproduce

1. Use hydra to render a USD scene with a disk light prim.
2. Output the dirtyBits passed to the Sync call.

Package Versions

USD 21.11

[spiffmon]

I can't comment on Hd specifically, @marktucker , but earlier this year (I think) we affirmed that general UsdImageable visibility should be the first-order gate on whether a light emits, so by that reasoning it makes sense to me that it would receive and respond to visibility dirtiness.

[marktucker]

Yep, that totally makes sense. I was only complaining about the mixing and matching of dirty bit enum sources. It's just luck that HdLight didn't already have a dirty bit that would conflict with the value of HdChangeTracker::DirtyVisibility and ruin this update mechanism.

[spiffmon]

Ah that makes sense, and great point!

[jilliene]

Filed as internal issue #USD-7091