This will allow us to replace the GLSL FFP pipes, and is useful for testing
the FFP HLSL backend before the Vulkan backend is mature enough in other
respects.
This patch introduces the d3d setting "ffp_hlsl", set to a DWORD value.
It is disabled by default, and only has an effect on the GL renderer.
In most cases, it is possible to construct a D3D shader which behaves
identically to a given FFP pipeline.
There are two exceptions, related to fog and texture transforms, where the FFP
pipeline has special behaviour that cannot be emulated with shaders, and we
handle those here by checking whether our shader is actually an FFP replacement
shader.
We only compute ffp_frag_settings and stash that in the shader byte_code.
The HLSL shader will be compiled to sm2 bytecode on the CS side, and then parsed
and interpreted by the shader backend (and all other code) as if it were a real
shader.
In theory, we could take the extra step of retrieving the settings from this
shader in the GLSL backend, instead of from the current state.
This however requires changing a number of places which currently check
"state->shader[WINED3D_SHADER_TYPE_PIXEL]" to also check "is_ffp_ps", and it
also means we need to handle some more states (shade mode, fog, etc.) as part of
ffp_frag_settings. Both of these will go away as soon as the GLSL backend can
simply consume the generated HLSL shader.
The idea is that we will have wined3d_shader objects that represent shaders
not yet in d3d form (specifically, in HLSL form or containing only an FFP
settings struct.) Hence we need to make it possible to delay d3d shader parsing,
but still keep the rest of shader_init().
NVidia and WARP clamp before interpolation in the oFog case; AMD clamps only
after interpolation (which we also do).
On the other hand, test_fog() proves that clamping should not be done before
interpolation in the FFP case, for any driver.
In order to emulate an FFP vertex shader with a real compiled shader, we need to
avoid clamping before interpolation, choosing the AMD behaviour here.
The previous commit ensures that the WTPACKET fields align between
32-bit and 64-bit architectures, so now we can use the same
tablet_get_packet without needing another thunk.
WTPACKET's structure is never directly exposed via the API; it's
internal to Wine. The HCTX value is only used on the wintab32 side,
not the driver side, and it is used as an integer rather than a
pointer, so this should be safe to do.
This eliminates the need to have a wow64 thunk for tablet_get_packet.
This matches with native. It's needed to ensure that mountmgr is started
before other services that use functionality provided by it. Fixes
Autodesk Desktop Licensing Service that uses GetVolumeInformationByHandleW.
Uri_DISPLAY_IDN_HOST makes the hostname in Uri_PROPERTY_ABSOLUTE_URI, Uri_PROPERTY_DOMAIN and
Uri_PROPERTY_HOST appear in punycode or Unicode as it would appear in the Uri_PROPERTY_DISPLAY_URI
property. IDNs appears in Unicode on some Windows version and in punycode on others. Wine chose to
display Unicode for Uri_PROPERTY_DISPLAY_URI. So no need to add special handling for
Uri_DISPLAY_IDN_HOST at the moment because they already display in Unicode.
MSDN documents a way to 'touch' a file in CMD.EXE with:
COPY /B file.ext+,,
(and actually the /B switch doesn't matter).
Signed-off-by: Eric Pouech <epouech@codeweavers.com>
