On 10 April 2013 14:32, Stefan Dösinger <ste...@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.
