At a later stage I might disallow calling set_shader when we don't need the shader.
How does the caller know when a shader is needed?
In the end set_shader will only be called by blit_shader->blit_surface.
The main issue I'm facing is p8 uploads which are completely broken right now (a regression). At the beginning of the week I wanted to add BLIT_OP_COMPLEX_UPLOAD to fix this but Henri didn't like that. This 'fixed' the bug where d3dfmt_get_conv was not allowed by blit_supported to offer the 8-bit shader. This fix would only apply to the LoadLocation part which is where the 8-bit upload takes place.
The suggested direction was to fix blit_supported to allow 8-bit blits under 'special circumstances'. Such a change would not only allow 8-bit uploads but also allow 8-bit -> 8-bit Blt/BltFast (blit_supported can't distinguish between the two uses since it has too vague information). Allowing the 8-bit -> 8-Blt/BltFast led to these changes (I'm not that happy about allowing those).
At this point BltOverride (and some of the other helpers derived from it) blindly call set_shader when it is not needed which wouldn't work here. The set_shader call at this point lacks the knowledge (it has only one of the surfaces) to not apply the shader in this case. I don't think I can add the missing surface because not all places which call set_shader have it. For this reason I wanted to take the texture target activation out of 'set_shader' and lift this to 'blit_surface' which the current callers are supposed to become at some point. Some places (e.g. swapchain_blit) imply that that the shader is needed when a complex source fixup is detected and the same for blit_to_drawable, so in BltOverride/arbfp_blit_surface I can just not call set_shader.
Right now I don't know anymore how it should be fixed at this stage without re-adding the ugly extension checks which existed before in d3dfmt_get_conv or other or other hacks like checking for 'is_complex_fixup' in d3dfmt_get_conv :(
Roderick