* Rereading patch 4/10, should we just forbid creating multisample NPOT textures in the first place? Sadly I'm sure nobody has a GPU of that era to test with...
Then again, if we're accepting this during code freeze (and I think it's reasonable) then the more targeted fix is probably better.
* One alternate approach for 7/10, which may be more declarative, is to replace the logic in init_format_texture_info() with something like
``` srgb_write = fragment_caps.srgb_write && (!shader_caps.ps_version || (shader_caps.wined3d_caps & WINED3D_SHADER_CAP_SRGB_WRITE)); ```
* Wrt 10/10, since the relevant logic is very much restricted to the ARB shader backend, should we try to handle this case closer to there as well? E.g. add STATE_VDECL, STATE_SHADER(WINED3D_SHADER_TYPE_VERTEX), STATE_RENDER(WINED3D_RS_CLIPPING), STATE_RENDER(WINED3D_RS_CLIPPLANEENABLE) handlers, and have them set context->shader_update_mask. This seems like the "usual" way to handle cases like this, e.g. glsl_fragment_pipe_vs(), and I at least am inclined to prefer keeping that logic a *bit* closer to its counterpart.