This is assuming all the content is sRGB, which is not a safe assumption especially if you care about color management to begin with.

I know just from writing graphics hacks that you get significantly better results if you do the correction in the HDR color space before you produce the 24-bit, 8-bits-per-component pixels shipped to the GPU.

If by "video LUT" you mean something at the CRTC or even after it on some external device, if the software producing the visuals has already reduced the pixels down to 8-bits-per-component before they hit the LUT, then you've lost accuracy particularly in the small values.

This is why it's desirable to do one of the following:

1. inform the software of the LUT and let it perform the transform before it packs the pixels for display

2. change the entire system to have more bits per color component all the way down to the framebuffer, then the per-component LUTs at the CRTC can profitably contain > 256 entries.

I'm not an expert in this field at all, just play with graphics hacks. But this is what I've come to understand is the nature of the issue.

edit:

To clarify, the reality implied by the need for correction is that some areas of the 0-256 range of values are more significant than others. When you do a naive linear conversion of whatever precision color the application is operating in down to the 24-bit rgb frame buffer, you've lost the increased accuracy in the regions that happen to actually be more significant on a given display. So you'd much rather do the conversion before throwing away the extra precision, assuming the application was working in greater than 24-bit pixels.

Not necessarily. After calibration your monitor displays as accurately as it can sRGB (or any other profile you calibrated for). It still may miss or shift parts of sRGB though.

Thus your software has to know what your display is capable of. It can use this information to show you which parts of the photograph you edit are not shown accurately.