[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: