Can you explain what you mean there?
We use "gamma correction" to mean going from a linear colour space to a curved one, or vice versa.
If the texture is saved in the (curved) sRGB colour space, but we want it to be in a linear RGB space so we can perform math on it, then we need "gamma correction" (meaning, we apply the sRGB->linear curve).
The purpose of "gamma correcting" an albedo texture in Photoshop is to preserve detail in the dark areas which humans are sensitive to
it has NOTHING to do with monitor gamma
This human response curve is "Lightness" which is standardized by CIE as "how a standard human perceives Luminance"
and is the basis for the CIELAB color space
So DCC tools should be "Lightness correcting" to preserve information (avoid banding) according the the CIE transfer function for human perception
They don't have to concern themselves with Monitor gamma at all!
That is taken care of by sRGBWrite (or similar) at the end of the pipeline
HLSL shaders should be doing this:
float3 linear = LightnessDecode(tex2D(s, t));
(a sudden thought)
float3 linear = CIELABDecode(tex2D(s, t));
not this:
float3 linear = GammaDecode(tex2D(s, t));
The difference is probably so minor, nobody would notice
But at least gamma makes sense to me now ...