[PATCH] d3d9/tests: Add more tests for shader validator.

Alexandre Julliard julliard at winehq.org
Tue Jan 12 05:58:32 CST 2021


Henri Verbeet <hverbeet at gmail.com> writes:

> On Tue, 12 Jan 2021 at 12:20, Alexandre Julliard <julliard at winehq.org> wrote:
>> Henri Verbeet <hverbeet at gmail.com> writes:
>> > On Mon, 11 Jan 2021 at 20:15, Paul Gofman <pgofman at codeweavers.com> wrote:
>> >> On 1/11/21 21:18, Henri Verbeet wrote:
>> >> > On Mon, 11 Jan 2021 at 19:02, Paul Gofman <pgofman at codeweavers.com> wrote:
>> >> >> As soon as there is just one game known so far which happens to depend
>> >> >> on this validation, and we are unlikely to see more of such, I thought
>> >> >> of implementing only the minimum checks required in place (based on how
>> >> >> that is done in d3dx9 for, e. g., D3DX9GetShaderSemantics()). I've
>> >> >> attached some draft patches to the bug here:
>> >> >> https://bugs.winehq.org/attachment.cgi?id=69101. Do you think that is a
>> >> >> possible way to go? Or are there any plans for d3d compiler to use d3d9
>> >> >> shader validator, the same way as native maybe does?
>> >> >>
>> >> > The long-term plan is for pretty much all of the d3dx9 and d3dcompiler
>> >> > shader handling code to be implemented in vkd3d-shader. For new code
>> >> > it probably makes the most sense to implement it there in the first
>> >> > place, instead of moving it over later.
>> >>
>> >> I will check that but I am pretty sure doing the actual check in the end
>> >> through vkd3d_shader_scan() should do for this bug. I am not sure which
>> >> is the best way to interface that d3d9, should we add a helper to
>> >> wined3d for vkd3d_shader_scan()?
>> >>
>> > I'm not sure there's much of a point to going through wined3d for
>> > this; as far as I'm concerned it would be fine to call
>> > vkd3d_shader_scan() directly from d3d9.
>>
>> You'd need a PE build of vkd3d-shader then...
>>
> We do support PE builds of vkd3d, but I was under the impression we
> would be able to interface with host libraries using the
> __wine_init_unix_lib() mechanism.

We could of course, but it would be better to avoid it, especially for
libraries that we control. The more Unix interfaces we have, the more
trouble we'll have down the road.

-- 
Alexandre Julliard
julliard at winehq.org



More information about the wine-devel mailing list