Re: [PATCH 1/2] wined3d: Handle texture types via ps/vs_compile_args
On 10 April 2013 13:39, Stefan Dösinger <stefan(a)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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRZVvQAAoJEN0/YqbEcdMwyYEP/1Ez745CKD3CxnYK7WNuG2L3 0MEqi0IcepR917nZXXg7Azq7gssVRsepusxgU6RxTaY2HjmgBZ5a4d/XWBOiWnsl Z3rf4HMtHGQVunE1Nr8jQs0J01Ak0/pdp/po856Fy6BYJVQWx773glj3xa7RK5LP GRm8U4sD9SirC0vIdOnKlU9pBrCRtWC6c5TjJm57WFaGEujIt6q8SL7bqe1Sct+0 lKR4WO+66iUfNwCYsbLUT/mt5zwdVeiqmi5CtRYRMvTn972cKpYh1Lsyd3Xr45Ok ZZSQ4iQn3g6l2i9A5kSJw0tiVjNTKdc4+S9UhOuQsSXusXr1lvkrl9wrwgG+sXK0 Dt4cKdjNh3TIt+OcQ2R1jvqU3dkQlD8wj3aBtXJf6U0OQTSjc/0iCXy00yyoNwsM ZrVlT7DoLQ5+fMAbWy6RdXqONpEbEF6wxN/UCMJtyC+UUns4oyp5ndygKVoub1l0 PmkWQEX8GbsKu4q81OjIp4cdouEsIkkrVanDy+keYvX+ykxRGq0qg2+lVltYz3RJ 6Lb5SeK+Ky9TLJNL3mo0Xi0fQ0VCXti3t+5X4MwlDQ7gqLoEqGCBvC/coSInFuJO zlOaK8Jan/sh8uwH2WKcfa8HK2vI2d1MBtMd1om2SWGH2SlMVML2D4tVXZjlMzC1 Je8PniI9/LVi/UXE6Asn =eFtc -----END PGP SIGNATURE-----
On 10 April 2013 14:32, Stefan Dösinger <stefan(a)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(a)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-----
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(a)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(a)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-----
participants (4)
-
Henri Verbeet -
Matteo Bruni -
Stefan Dösinger -
Stefan Dösinger