[PATCH vkd3d 00/41] Add support for DXIL shaders

Hans-Kristian Arntzen post at arntzen-software.no
Wed Jan 29 09:31:07 CST 2020


On 1/29/20 3:09 PM, Rémi Bernon wrote:
> On 1/29/20 2:54 PM, Andrew Eikum wrote:
>> On Wed, Jan 29, 2020 at 12:51:25PM +0100, Hans-Kristian Arntzen wrote:
>>> Hans-Kristian Arntzen (41):
>>>
>>>   16 files changed, 6544 insertions(+), 724 deletions(-)
>>
>> I can't speak to the content of the series, but this is a huuuuuge
>> amount of code to dump all at once. I'd suggest sending series of
>> about 4-5 patches at a time.
>>
>> Andrew
>>
>
> Hi,
>
> I wanted to have a look and the patches don't apply cleanly either (it 
> fails at #02, but later as well).

There seems to have been some commits in-between master and the 
patchset, which caused issue when I tried to apply them to clean master. 
Doesn't seem like there is much of a mood for getting another 41 commits 
on the ML, so just uploading a tarball instead if that's okay. 
Alternatively, a branch is here: 
https://github.com/HansKristian-Work/vkd3d/tree/dxil-review.

>
> Also I tried to build dxil-spirv on Debian, and it misses some LLVM 
> include paths in the CMakeLists.txt. Fixing that is easy, but then it 
> also requires another include fix to build with llvm-10. Then I tried 
> several other version and LLVM 8, 9 and 10 seems to build fine, but it 
> starts to fail compiling with earlier versions of LLVM.
>
> In my experience, building a project using LLVM C++ API makes it very 
> brittle, as they tend to change their API quite often. The projects 
> fall behind very quickly as they cannot keep up with LLVM development 
> speed, and it becomes very hard to build.
>
> I'm not sure what's the target but I believe that since the LLVM IR 
> format is advertised as stable since 3.7 -and DXIL format probably 
> even more- depending on some unstable API to parse it goes a bit 
> against it.
>
> A better solution to this, IMHO, would be to have a custom parser for 
> DXIL. Although it's a bit more work, the project would be more self 
> contained and much more portable.

Yes, that's the ideal solution. I am aware of this problem, but I had 
hoped to defer this. Writing a good BC parser from scratch is likely 
another several man-months of work on top unless someone have made 
useful progress on that already.

Cheers,
Hans-Kristian

>
> Cheers,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vkd3d-dxil.tar.gz
Type: application/gzip
Size: 137338 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20200129/c71a7c2d/attachment-0001.gz>


More information about the wine-devel mailing list