On 10 April 2013 13:39, Stefan Dösinger stefan@codeweavers.com wrote:
This patch only changes the way the texture types are fed into the shader generation code. Generating the proper shader code (hardcoded values instead of relying on the dummy textures) is a task I've left for Matteo, who worked on this problem before.
This patch originates from my work-in-progress command stream work. It is one of the few that I think makes sense on its own.
Why do you need the sampler type for anything other than SM1 pixel 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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-04-10 14:28, schrieb Henri Verbeet:> Why do you need the sampler type for anything other than SM1 pixel
shaders?
I'm not sure what you mean exactly. There are 3 problems related to the sampler type:
*) RECT vs 2D samplers *) Shader declares a 2D sampler but e.g. a cube texture is bound *) SM 1 pixel 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.
Furthermore, we may have to recompile the shader if the app switches texture types, thus we want this in the compile args.
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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-04-10 15:13, schrieb Henri Verbeet:
On 10 April 2013 14:32, Stefan Dösinger stefan@codeweavers.com wrote:
*) Shader declares a 2D sampler but e.g. a cube texture is bound
Yes, but we have the "dummy" textures for that.
My understanding was that we don't want to use the dummy textures for this purpose, but I'm not sure about the reason - probably because we have to re-bind the dummy texture every time the texture type is changed. Matteo, do you remember the details about this?
If the dummy textures are the preferred way to handle incorrectly bound textures, most of this patch is moot.
I guess it depends on what happens in D3D when the sampler type declared in the shader and the type of the texture bound to that sampler disagree, and it really matters only if all the current drivers have the same behavior in that regard. unbound_sampler_test() doesn't check what happens with mismatching texture and samplers and I don't think there is any test for that already (nor I remember if I wrote such a test previously).
On current D3D drivers, sampling from NULL textures gives you black, where in the past there was no consistent behavior among driver vendors (with wined3d you would sample white most of the times). Applications started to depend on sampling black from NULL textures, so we introduced NULL-texture handling via black dummy textures. The current wined3d code "works fine" in that it behaves nicely from the OpenGL point of view and it doesn't cause bugs with D3D games, as far as I know, so I don't think there is any pressing reason to change that. Unless proved otherwise, of course...
2013/4/10 Stefan Dösinger stefandoesinger@gmail.com:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-04-10 15:13, schrieb Henri Verbeet:
On 10 April 2013 14:32, Stefan Dösinger stefan@codeweavers.com wrote:
*) Shader declares a 2D sampler but e.g. a cube texture is bound
Yes, but we have the "dummy" textures for that.
My understanding was that we don't want to use the dummy textures for this purpose, but I'm not sure about the reason - probably because we have to re-bind the dummy texture every time the texture type is changed. Matteo, do you remember the details about this?
If the dummy textures are the preferred way to handle incorrectly bound textures, most of this patch is moot.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRZWtoAAoJEN0/YqbEcdMwCvUP/1dUCAz4VGdGBMoJLCY19rlr yW9EXVuthizZXuoBueNPdBZtMj/NIh22WRr33aObWsMkvdL5vwuWklwMkHW/Pjzh xTQitfeu4wfI4DV9inCQaKiTWYxf9h+kAZxoaEnixGZHk5EkVUroic7n6hbGvPs+ e/kCwPyO+aYioxTFqvF2o4WANdzu0UF3MExz6GQiwqSzhNnlZhHy+hEDrOcbGbeS Eg9jgTutgFSEQu7+FDOHi8mNHQ7LCeBg09/OiUZVm00lTqS2FWFTg/7l1javKsdr FwKg6D7/CqdFmYSEv9aXzU+HaaDifNWI5P991qWb6k0i+IljpUnJHwy03vOcImHm VSQGTTHpFpWMAwDglbbBMU8cImhtd7EW9DmTH5kSIJ39ONCoYQRVZtXxGT+ducGa CbHDfgBbGBsP145+KtD35nAahf2+le9QwHMruBJ/Di53JcBUUuBYDIgNpJWz/wvK 7f1EcuMC05lMKxy6RE9dEE1CNrUpLz1IXVgHa3gDHl+cJRpBkWSV7uL0NDO7STS3 04PhDiQOwrnh7K48kMt7JztcKbG+obvdiOfv7Wj2kNPeRllMrQUN+AEaFKG3YQEP KeKsts6BBkjQkqYTYLCAm/vxCnJ9rWHmKdjjl355Il1aDocJb+mT48zZA5JBEzz9 flE2jibstgLp6Qzm7Wj1 =S7yF -----END PGP SIGNATURE-----
-
Henri Verbeet -
Matteo Bruni -
Stefan Dösinger -
Stefan Dösinger