-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-04-07 um 12:17 schrieb Henri Verbeet:
On 6 April 2015 at 00:28, Stefan Dösinger stefan@codeweavers.com wrote:
+#define WINED3D_CKEY_REMOVE 0x80000000 +
It seems unfortunate to define part of the flags in include/wine/wined3d.h and part of the flags in dlls/wined3d/cs.c. You'd probably also want to mask out private flags in wined3d_cs_emit_set_color_key().
There are multiple ways to pass this information. The simplest one is an extra field in struct wined3d_cs_set_color_key, but that seems unfortunate because we have plenty of spare bits elsewhere. I could also define a separate op for unsetting the key. Whatever you prefer.
This one is different in that it operates on a texture, and anything that would need to read the color key would then need to either wait for the texture to become idle, or run from the CS itself.
The color key is currently read by the texture loading code, which is either called by draws (called through the CS) or by blits (which we want to call through the CS at some point). I don't see a clean way to move the read to the main thread.
What we could do is shadow the texture 0 color key in wined3d_state. In this case the command stream op would only be used for changing this mirrored value, and it would be emitted when texture 0 is changed or when texture 0's color key is changed(*). In this case we need a separate way to pass the key to blits (could be a blit op parameter, and passed around between functions), and wined3d_texture_load needs to somehow find out when to read the color key from the state structure.
Note that for GLSL / ARB fragment processing I'll handle color keying with discard / KIL in the shader and the color key becomes more or less a shader constant, and I'll keep track of changes to it with a new state.
The immediate requirement that prompted this change is that setting the key on the texture that's currently bound to texture 0 should invalidate WINED3D_RS_COLORKEYENABLE. The state invalidation must be done through the command stream or wait for all commands to be executed.
(*): Windows drivers disagree on color keying on textures 1-7. dx9+ GPUs apply the color key, at least my Radeon 9000 (dx8) does not, and doesn't seem to have circuitry for more than one key. I think we can safely keep color keying limited to texture 0.