On 10 April 2013 14:32, Stefan Dösinger stefan@codeweavers.com wrote:
I'm not sure what you mean exactly. There are 3 problems related to the sampler type:
*) RECT vs 2D samplers
Yes, but in principle you can get that from the existing np2_fixup field.
*) Shader declares a 2D sampler but e.g. a cube texture is bound
Yes, but we have the "dummy" textures for that.
*) SM 1 pixel shaders
Yes, but those are limited to 6 or so textures, which you could encode in 2 bytes instead of 64. (Compared to the current structure size of 48.) Even if you store the type for all 16 (currently) possible samplers you only really need 4 bytes, as long as you limit the possible values to 1D, 2D, 3D and CUBE. I don't think there should ever be a reason for this for vertex or geometry shaders.
Also, while in principle I'm all for not accessing wined3d_state from the shader backend, I don't think there should be anything in the command stream patches that would prevent that.
Correct. But accessing the stateblock to access the state is a problem.
Yeah, we never want to access the stateblock.
Furthermore, we may have to recompile the shader if the app switches texture types, thus we want this in the compile args.
For SM1 pixel shaders, sure.