On Thu Oct 19 09:51:46 2023 +0000, Nikolay Sivov wrote:
> It does compile, but results are broken. That's what I get on Windows:
> `shader_runner:683: Section [test], line 51: Test failed: Got
> {8.40779079e-045, 9.80908925e-045, -1.#QNAN000e+000, 4.20389539e-045},
> expected {6.00000000e+000, 7.00000000e+000, -1.00000000e+000,
> 3.00000000e+000} at (0, 0).`
> That happens because of the lack of itof conversion on SM3. So ints we
> set are returned as is, after ceil() is optimized away for integers.
I see. So the `probe` part may be deserving of a `todo(sm<4)`.
I made patches for that on the second part of !418, but I think that for now it is okay to leave the requirement.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/417#note_49293
because it's explicitly requested. man machine-id
> ```plaintext
> This ID uniquely identifies the host. It should be considered "confidential", and must not be exposed in untrusted environments, in particular on the network. If a stable unique identifier that is tied to the machine is needed for some application, the machine ID or any part of it must not be used directly. Instead the machine ID should be hashed with a cryptographic, keyed hash function, using a fixed, application-specific key. That way the ID will be properly unique, and derived in a constant way from the machine ID but there will be no way to retrieve the original machine ID from the application-specific one. The sd_id128_get_machine_app_specific(3) API provides an implementation of such an algorithm.
> ```
(looks like /etc/machine-id should never have been user readable, and this is about reducing the exposure)
for the second patch in the serie, the we need to craft missing info (because some DMI fields are only readble by root), do you also recommand to reuse directly machine-id? (it would be better to not tie the values to a given prefix, anticheat vendors will not like it), so the least worst choice is deriving from machine-id.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_49291
We used to have some hack for passing information (mainlyi
module related ones) from dbghelp to WineDbg.
This series:
- reimplements properly the sharing, introducing a Wine
entrypoint to dbghelp (sharing debug formats not handled
by native, no longer decorating module names for sharing
that module was in fact a host module...)
- improves "info share" command in WineDbg with more accurate
information (host module type...)
- improves loading time on MacOs (some system libraries no
longer have their images accessible directly on disk by
standard file operation).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4142
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v2: vkd3d-shader: Add constant folding for 'floor'.
vkd3d-shader: Add a missing entry to instruction debug print helper.
vkd3d-shader: Add constant folding for 'ceil'.
vkd3d-shader: Add support for floor() on SM1-3.
vkd3d-shader: Add support for ceil() on SM1-3.
vkd3d-shader/tpf: Add support for ceil().
vkd3d-shader/hlsl: Parse ceil() function.
tests: Add some tests for ceil().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/417