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. > >
