Re: Bug#1033733: vkd3d: new upstream release 1.11
On Friday, 31 May 2024 05:14:41 CDT Giovanni Mascellani wrote:
> Hi,
>
> I'm a vkd3d upstream developer. Unfortunately I haven't had a lot of
> time for Debian for a few years, but I'm happy to help here if needed.
>
> Il 28/05/24 19:36, Simon McVittie ha scritto:
> > Since then there have been several more upstream releases and it is
> > currently at v1.11.
>
> And now v1.12, just yesterday.
>
> >>> I need .deb packages of this version for a work project, so I've been
> >>> looking at updating the packaging used for Debian as a starting point
> >>> for that
> >>
> >> Please consider merging this:
> >
> > Updated version at:
> >
> > https://salsa.debian.org/smcv-guest/vkd3d wip/1.11
> >
> > Once again I used `uscan --download` to get the orig.tar.* I used for
> > test-builds.
> >
> > debian/patches/fixes/byte-comparison.patch no longer applies; I dropped
> > it for now (and the package builds successfully in my environment), but
> > if it's still necessary for other build environments, it will need some
> > adjustment. It would be ideal if this issue could be reported upstream
> > and fixed there.
>
> compare_uint() and compare_color() are now in tests/utils.h. I don't
> really understand in which cases that patch is supposed to help, but
> it's true that vkd3d assumes every now and then that the architecture is
> one of i386, amd64, arm or arm64 (i.e., the architectures meaningful for
> Windows). So it's totally possible that a little endian assumption has
> trickled in somewhere, though it's not immediately clear to me how
> endianness should break something here.
Despite what the name kind of implies it's not a LE assumption. Unless
I'm misreading it, It's rather letting comparisons wrap (e.g. treating
0x00 as "close" to 0xff), presumably in an attempt to fix failing
tests, but those failures are probably legitimate.
> For the failing tests, as you might already have noticed, most vkd3d
> developers use AMD GPUs. I'm slowly trying to clean up the tests on
> llvmpipe, Intel and NVIDIA GPUs (and also more exotic Vulkan
> implementations, like MoltenVK and mobile GPUs), but that tends to be
> relatively low priority.
>
> Gio.
>
>
Reply to: