[PATCH 1/2] dlls/d3d12: Fix D3D12SerializeVersionedRootSignature.

[Sveinar Søpler]

On 24.11.2019 17:40, Zebediah Figura wrote:
>
> On 11/24/19 10:00 AM, Sveinar Søpler wrote:
>> On 24.11.2019 16:24, Zebediah Figura wrote:
>>> On 11/23/19 9:57 AM, Hans-Kristian Arntzen wrote:
>>>> On 11/23/19 4:47 PM, Sveinar Søpler wrote:
>>>>> On 18.11.2019 10:55, Henri Verbeet wrote:
>>>>>> On Sun, 17 Nov 2019 at 00:11, Sveinar Søpler <cybermax at dexter.no> wrote:
>>>>>>> Ok. Tested as follows:
>>>>>>>
>>>>>>> Wine-staging-4.20
>>>>>>>
>>>>>>> vkd3d git HEAD at da68980fdc0e549174ce0a9c1f7859f2f388a907
>>>>>>>
>>>>>>> World of Warcraft crashes upon loading with a "Error #132 Fatal
>>>>>>> Exception!"
>>>>>>>
>>>>>>> Added the following patch to wine-staging-4.20:
>>>>>>> https://www.winehq.org/pipermail/wine-devel/2019-October/152356.html
>>>>>>>
>>>>>>> WoW now loads, and can zone in. Textures are flashing ref.
>>>>>>> https://bugs.winehq.org/show_bug.cgi?id=46410
>>>>>>>
>>>>>>> The bug: https://bugs.winehq.org/show_bug.cgi?id=47471 can be closed as
>>>>>>> this seems fixed with a recent commit.
>>>>>>>
>>>>>> Ok, so the regression from commit
>>>>>> c002aee119b638d30eeb7cdc91099449ccafeafc is independent of bug 46410,
>>>>>> correct? Does the attached patch fix the regression?
>>>>> Yes, the bug 46410 is independent of this regression. I made an
>>>>> attempt at reposting a fix for that particular bug here:
>>>>> https://source.winehq.org/patches/data/174234 but i borked some
>>>>> formatting, so i dunno if that applies...
>>>>>
>>>>> Your attached patch for vkd3d fixed the regression. I tested this with
>>>>> a clean unpatched wine-staging-4.20.
>>>>>
>>>>> It does seem as the patch just forces things back to
>>>>> root_signature_1.0 tho? Would it not be better to implement the Fix
>>>>> D3D12SerializeVersionedRootSignature patch to wine?
>>>>>
>>>>> Sveinar
>>>> I think the problem is that D3D12SerializeVersionedRootSignature
>>>> implementation depends on latest vkd3d to be able to compile, it cannot
>>>> compile against vkd3d 1.1 (latest release, from January), which does not
>>>> implement RS 1.1. Ideally wine master would depend on vkd3d master so we
>>>> can expose RS 1.1 support.
>>> This isn't really a sustainable way to release libraries. It requires
>>> that anyone distributing libvkd3d distribute the git master, and it also
>>> requires that libvkd3d be distributed in lockstep with Wine in case its
>>> API does change in a non-backwards-compatible way.
>>>
>>> The ideal solution is that the libvkd3d 1.2 API be reviewed and fixed,
>>> and that 1.2 be released.
>> Does this mean that supporting D3D12 root signature 1.1 requires a API
>> change to libvkd3d_1.2? How would the testbot pick up the new package?
>> Would it be much different than "releasing" libvkd3d_1.1-2 or something
>> as a intermediate "release"?
> libvkd3d 1.2 hasn't been released. Exporting
> vkd3d_serialize_versioned_root_signature() is itself an API change from
> libvkd3d 1.1. The API change corresponds (if I understand correctly) to
> a convention in version naming: the minor version is incremented for
> changes which are backwards-compatible, the major version for those
> which are not.
>
> I'm not sure how libraries are installed on testbot machines, but I
> suspect they go through distribution packages.
I think so too. Kinda like how buildbots do it i guess.
>> Would doing some configure check be possible? If the local libvkd3d-dev
>> package have the function compile WITH
>> D3D12SerializeVersionedRootSignature, and if not, do not use this
>> function? I mean if it is necessary for a distro to pick up this new
>> release when that happens, will leave us in a state like the libFAudio
>> library is now, and i do not think that is much more preferable...
> Once libvkd3d 1.2 has been released (and, I suspect, once a reasonable
> amount of time has been given for distributors to update it), Wine will
> either use it conditionally or require 1.2 to compile. See also Wine
> commit 72cf4a99c.
As i said above.. This kinda has not worked very well for libFAudio. But 
sure "given enough time" it will. So if libvkd3d_1.2 is released Q1 
2020, i think atleast for the Ubuntu side, it might make it in time for 
20.04 LTS, or atleast 20.10 later that year.
>> It is kind of a catch 22 this thing, cos you cannot update Wine with
>> this due to missing libvkd3d function, and you cannot upgrade libvkd3d
>> with this, cos Wine does not support it....
> I'm not sure I see how. libvkd3d doesn't depend on Wine at all; that's
> kind of its entire point.

Oh i agree. libvkd3d is a standalone library that do not depend on 
wine... but to my knowledge the only thing using libvkd3d at the current 
time is wine. I am happy to be corrected ofc!

It might be ONLY world of warcraft that have these issues, and in that 
case it is not problematic to say that D3D12 simply does not work with 
current wine. I am interested in finding out if other games that uses 
D3D12 can use libvkd3d GIT version without these patches? Hitman 2? 
Dunno. Feedback welcome :)

But it is probably equally unproblematic to just revert patches too, and 
wait this one out a bit longer, as World of Warcraft seemed to work with 
Henri's patch a few posts up. The same question there too tho - Does 
reverting the root_signature_1.1 thing cause any problems? If not, sure, 
the easiest solution for the time being is just to go back to root_sig_1.0.

Philip: Any opinions about whether root_signature_1.1 is needed for 
games you have tested, or for that matter if you need this 
(wine)D3D12SerializeVersionedRootSignature patch with current libvkd3d 
GIT for other games?

Sveinar

>> Sveinar
>>
>>>> Cheers,
>>>> Hans-Kristian
>>>>
>>>>>>> PS. This "mailinglist" thing is horribly hopeless to keep up to date
>>>>>>> when referring to other patches.. atleast not in a way that i can
>>>>>>> figure
>>>>>>> out other than posting links.. and browsing through various .txt
>>>>>>> archive
>>>>>>> files to figure that out, so when i posted about a vkd3d patch that
>>>>>>> fixed things, it was probably not clear that it ALSO needed wine
>>>>>>> patches, that i think (without once again searching through 100'eds of
>>>>>>> mailthreads) was mentioned earlier in the thread. Sorry.
>>>>>>>
>>>>>> The bug tracker does work better for tracking bugs, yes.
>>>>>>
>>>>>> Henri