[PATCH] d3d10: Implement D3D10CompileEffectFromMemory().

[Valentin Gabriel Mitrea]

As MSDN documentation recommends, one should use D3DCompile()
instead of D3D10CompileEffectFromMemory(). So, execution was
forwarded to that function.

This implementation is a possible fix for this bug:

https://bugs.winehq.org/show_bug.cgi?id=36538

At the moment, there are no d3d10 tests written for shader and
effect compilation functions.

Signed-off-by: Valentin Gabriel Mitrea 
---
 dlls/d3d10/d3d10_main.c | 13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/dlls/d3d10/d3d10_main.c b/dlls/d3d10/d3d10_main.c
index f2fbb41..0081e8f 100644
--- a/dlls/d3d10/d3d10_main.c
+++ b/dlls/d3d10/d3d10_main.c
@@ -253,17 +253,14 @@ HRESULT WINAPI D3D10CompileEffectFromMemory(void *data, SIZE_T data_size, const
         const D3D10_SHADER_MACRO *defines, ID3D10Include *include, UINT hlsl_flags, UINT fx_flags,
         ID3D10Blob **effect, ID3D10Blob **errors)
 {
-    FIXME("data %p, data_size %lu, filename %s, defines %p, include %p,"
-            " hlsl_flags %#x, fx_flags %#x, effect %p, errors %p stub!\n",
+    TRACE("data %p, data_size %lu, filename %s, defines %p, include %p, "
+            "hlsl_flags %#x, fx_flags %#x, effect %p, errors %p\n",
             data, data_size, wine_dbgstr_a(filename), defines, include,
             hlsl_flags, fx_flags, effect, errors);

-    if (effect)
-        *effect = NULL;
-    if (errors)
-        *errors = NULL;
-
-    return E_NOTIMPL;
+    /* Forward to d3dcompiler */
+    return D3DCompile(data, data_size, filename, defines, include,
+            NULL, "fx_4_0", hlsl_flags, fx_flags, effect, errors);
 }

HRESULT WINAPI D3D10CreateEffectPoolFromMemory(void *data, SIZE_T data_size, UINT fx_flags,

[Matteo Bruni]

2018-04-20 13:53 GMT+02:00 Valentin Gabriel Mitrea :
> As MSDN documentation recommends, one should use D3DCompile()
> instead of D3D10CompileEffectFromMemory(). So, execution was
> forwarded to that function.
>
> This implementation is a possible fix for this bug:
>
> https://bugs.winehq.org/show_bug.cgi?id=36538
>
> At the moment, there are no d3d10 tests written for shader and
> effect compilation functions.

This is probably okay in principle, for the time being (but adding a
small test would be even better). Did you actually try it with the
application in the bug and native d3dcompiler (our d3dcompiler doesn't
do much yet)?

A couple comments / nitpicks below.
> diff --git a/dlls/d3d10/d3d10_main.c b/dlls/d3d10/d3d10_main.c
> index f2fbb41..0081e8f 100644
> --- a/dlls/d3d10/d3d10_main.c
> +++ b/dlls/d3d10/d3d10_main.c
> @@ -253,17 +253,14 @@ HRESULT WINAPI D3D10CompileEffectFromMemory(void *data, SIZE_T data_size, const
>          const D3D10_SHADER_MACRO *defines, ID3D10Include *include, UINT hlsl_flags, UINT fx_flags,
>          ID3D10Blob **effect, ID3D10Blob **errors)
>  {
> - FIXME("data %p, data_size %lu, filename %s, defines %p, include %p,"
> -
>        " hlsl_flags %#x, fx_flags %#x, effect %p, errors %p stub!\n",
> - TRACE("data %p, data_size %lu, filename %s, defines %p, include %p, "
> -
>        "hlsl_flags %#x, fx_flags %#x, effect %p, errors %p\n",
>        data, data_size, wine_dbgstr_a(filename), defines, include,
>        hlsl_flags, fx_flags, effect, errors);

Period at the end of the TRACE message, please (before the \n, of course).
> - if (effect)
> -
>    *effect = NULL;
> - if (errors)
> -
>    *errors = NULL;
> -
> - return E_NOTIMPL;
> - /* Forward to d3dcompiler */
> - return D3DCompile(data, data_size, filename, defines, include,
> -
>        NULL, "fx_4_0", hlsl_flags, fx_flags, effect, errors);

You probably have to pass a valid entrypoint name. For d3dx9 / fx_2_0
that would be "main", no idea if that also applies to d3d10 / fx_4_0.
The comment isn't necessary IMO, but it doesn't hurt I guess.

[Valentin Mitrea]

Hello Matteo, and thanks for the reply :).
> This is probably okay in principle, for the time being (but adding a
> small test would be even better). Did you actually try it with the
> application in the bug and native d3dcompiler (our d3dcompiler doesn't
> do much yet)?

I haven't tried running the Livestream Procaster application mentioned in
the Bugzilla entry. If needed, I could have a look on it, but maybe there is
someone with a little more experience with this application? I've never
used it before.
> Period at the end of the TRACE message, please (before the \n, of

course).

Ah sorry, I didn't know that I should end TRACE messages with period.
> You probably have to pass a valid entrypoint name. For d3dx9 / fx_2_0
> that would be "main", no idea if that also applies to d3d10 / fx_4_0.
> The comment isn't necessary IMO, but it doesn't hurt I guess.

MSDN says that you have to pass a NULL entrypoint when compiling effects,
because the parameter is not used.
Also, we probably have to give another implementation for the
D3D10CompileEffectFromMemory() function from d3d10_1. At the moment,
that function is just a redirect to the d3d10 one (and, from what I
understood,
the d3d10_1 library should use the fx_4_1 profile).

I can remove that comment. I saw it used for another D3DCompile() call, so I
wanted to be consistent.

I will make these small mentioned changes and submit them either in a new
version of this patch (if it is rejected) or in a new one.