August 2022 - Wine-Devel - list.winehq.org

Re: [vkd3d] Handling object components within the HLSL compiler.

by Francisco Casas

On 31-08-22 14:12, Zebediah Figura wrote: > I don't think I understand the point of splitting uniforms for sm4 but > not sm1. If we need to determine (and potentially store) the actual type > of a uniform per-component anyway, why would we need to do that > differently for structs and arrays? > Well, first, I don't think we should split uniforms completely, only separate the object components as standalone variables. So, if we have, say struct { float4 foo; Texture2D tex[2]; float4 bar; } pou; We would be effectively end up with 3 variables: The original: --- struct { float4 foo; Texture2D tex[2]; float4 bar; } pou; --- and: --- Texture2D "pou.tex[0]"; Texture2D "pou.tex[1]"; --- because we would be adding a store from the "pou.tex[0]" variable to pou.tex[0], and from the "pou.tex[1]" variable to pou.tex[1], copy-prop should replace all derefs to the Texture components to derefs to these new variables. The pou variable no longer has to worry about the register allocation of its Texture fields, because the new variables do that. Generalizing, variables should no longer care about their object components, unless they are objects themselves. I think something similar happens under the hood in SM4, consider the output of the following shader in the native compiler: --- struct { float4 foo; Texture2D tex[2]; float4 bar; } pou; float4 main() : SV_TARGET { return pou.bar + pou.tex[0].Load(int3(1, 2, 3)) + pou.tex[1].Load(int3(1, 2, 3)); } --- --- // Buffer Definitions: // // cbuffer $Globals // { // // struct <unnamed> // { // // float4 foo; // Offset: 0 // float4 bar; // Offset: 16 // // } pou; // Offset: 0 Size: 32 // Textures: t0-t1 // // } // // // Resource Bindings: // // Name Type Format Dim HLSL Bind Count // --------------------- ---------- ------- -------- --------- ------ // pou.tex[0] texture float4 2d t0 1 // pou.tex[1] texture float4 2d t1 1 // $Globals cbuffer NA NA cb0 1 --- Object components are listed separately in the resource bindings, and they are efectively removed (or ignored?) in the definition of pou. Now, regarding SM1, it is not possible to declare objects inside other components, it is only possible to create (possibly multi-dimensional) arrays of single object types: --- sampler sam[3][2]; float4 main() : SV_TARGET { return tex2D(sam[2][1], float2(1, 2)); } --- but they don't appear as different variables in the CTAB section: --- // Parameters: // // sampler2D sam[6]; // // // Registers: // // Name Reg Size // ------------ ----- ---- // sam s0 6 // --- Unlike in SM4: --- // Resource Bindings: // // Name Type Format Dim Slot Elements // ------------------------ -------- ------- ------ ---- -------- // sam[2][1] sampler NA NA 5 1 // sam[2][1] texture float4 2d 5 1 --- (to get this output I used fxc 9 with compatibility mode) So, in summary, my idea is to: - For SM4, separate object components as stand-alone variables that take care of the register allocation of these individual objects. - For SM1, just support (possibly multi-dimensional) object arrays. With this, for both SM1 and SM4, each variable should only care about the allocation of a single type of register, so we can use the register offsets as we do now. In the future we would probably want to remove the "offset" field from the derefs, and make each hlsl_sm*.c compute the register offsets from the derefs in their index path form.

Aug. 31, 2022

Re: RFC: Allow marking unreliable tests as flaky.

by Alexandre Julliard

Francois Gouget <fgouget(a)codeweavers.com> writes: > On Wed, 1 Jun 2022, Rémi Bernon wrote: > [...] >> I think flaky_if should be enough, and then there could be some shortcut >> global variables for `!strcmp(winetest_platform, "windows" / "wine")`, so it's >> not too long to write. > > So: flaky_if( is_windows ) > flaky_if( is_wine ) > and plain flaky() I think flaky_wine is better. I don't see a need for flaky_windows though, there's no reason to enforce that a test should always succeed on Wine if it doesn't on Windows. -- Alexandre Julliard julliard(a)winehq.org

Aug. 31, 2022

Re: [vkd3d] Handling object components within the HLSL compiler.

by Zebediah Figura

On 8/30/22 18:05, Francisco Casas wrote: > > Hello, > > I write this update on what I am working on, because I think it > introduces some architectural changes that may be good to discuss, or at > least mention. > > Sorry if this text is a bit dense, I hope to send all this as a merge > request in a couple of days from now. Albeit we may want to avoid > merging before the code freeze ends. > > > More than a week ago, I started trying to implement SM1 resource loads. > For this, in particular, it is necessary to infer each sampler's > dimensions from usage (a use in a tex2D implies that the sampler is 2D, > if not previously declared as such). > This gets complicated when there are arrays of samplers, because each > sampler component can have a different dimension, and yet being part of > the same variable. > > For solving this I tried introducing a field to allow us to store data > for each component within hlsl_ir_var. > But this turned to be a complicated solution. As now, we lost the > component information in the derefs once we start working with register > offsets. > > I also wanted to have per-component data because I realized that, in > general, we are not handling object components properly when they are > part of a larger array/struct. > > But then I thought on an alternative solution: adding a compiler pass to > promote each object component within a large variable to a new > standalone variable, and prepend a store from this standalone variable > to the the original path of the component within the large variable; > relying on copy-prop and dce so that all references that refer to these > components end up pointing to the new standalone variable. > > This allows us to use the fields of the hlsl_ir_var (in particular, the > register allocation) for each object component, which solves the problem. > > While that strategy works, I then realized that we cannot use it when > targeting SM1 profiles, because we wouldn't be replicating the CTAB > (which doesn't introduce a new variable for each component in > multi-dimensional object arrays, just increases its register size). > SM4 on the other hand seems to do this, separating each sampler and > texture as its own variable in the RDEF block. > > My conclusion then, is that it is a good idea to separate each object > component into its own variable in SM4 (as long they are named with the > correct subscripts, like "foo.tex[3]"). > And while we can't do that in SM1, the good news is that SM1 doesn't > allow objects as components of larger types except within (possible > multi-dimensional) arrays. > > Samplers and Textures cannot be components of structs within SM1 > profiles, so we only have to support those cases in hlsl_sm1.c. > > This approach also has the benefit that now, all the component register > allocation information should be representable using the fields in the > hlsl_ir_var struct and the register size data within hlsl_type [1], > since each variable should only care about a single register type now. > Storing register allocation data component-wise should not be necessary. > > So I am implementing a series of patches to ensure that: > > * When targeting SM4 profiles, all object components are separated into > a sole variable. > * When targeting SM1 profiles, it is not allowed to declare objects as > components of structs; so they will either be a sole variable, or belong > to either a (possibly multi-dimensional) array of elements of the same > type, as declared within the shader. > * SM1 resource loads work. I don't think I understand the point of splitting uniforms for sm4 but not sm1. If we need to determine (and potentially store) the actual type of a uniform per-component anyway, why would we need to do that differently for structs and arrays?

Aug. 31, 2022

Re: Puzzling IPrincipal:UserId check in taskschd

by Dmitry Timoshkov

Francois Gouget <fgouget(a)free.fr> wrote: > I would expect all these property getters to work the same way. > So would something like that make more sense? > > hr = IPrincipal_get_UserId(principal, &bstr); > if (hr == S_OK && bstr) > { > hr = write_text_value(stream, L"UserId", bstr); I'd guess the check is supposed to avoid writing an empty UserId, and apparently the check for bstr being NULL is not enough. I don't recall why writing empty UserId is different from other property values. -- Dmitry.

Aug. 31, 2022

Re: RFC: Allow marking unreliable tests as flaky.

by Rémi Bernon

On 8/31/22 18:20, Francois Gouget wrote: > On Wed, 1 Jun 2022, Rémi Bernon wrote: > [...] >> Imho the message should keep the 'Test failed' / 'Test succeeded' prefixes. >> For instance I think it would look more consistent with something like: >> >> Test succeeded inside todo block: > > This is a non flaky todo test which succeeds. > >> Test succeeded inside flaky block: > > The message does not reflect that such a test is both flaky *and* > todo. Mabe something like this would be clearer: > > Test succeeded inside flaky todo block: > > >> Test marked todo: >> Test marked flaky: >> Test failed: >> Test succeeded: > > That can work. > > > [...] >> I think flaky_if should be enough, and then there could be some shortcut >> global variables for `!strcmp(winetest_platform, "windows" / "wine")`, so it's >> not too long to write. > > So: flaky_if( is_windows ) > flaky_if( is_wine ) > and plain flaky() > > I worry that we would risk name collisions but winetest_is_windows would > defeat the purpose. (plus we already have some short potentially > collision-prone names and it worked out so far) > > It's tempting to have things line is_win10 but again that's likely > either too fine grained or not enough which probably makes it useless > (is_win10_2009_or_greater). > Yeah I don't think we need something finer for the most common cases. And I believe we're trying to avoid having tests checking Windows versions in general, using feature checks instead. -- Rémi Bernon <rbernon(a)codeweavers.com>

Aug. 31, 2022

Re: RFC: Allow marking unreliable tests as flaky.

by Francois Gouget

On Wed, 1 Jun 2022, Rémi Bernon wrote: [...] > Imho the message should keep the 'Test failed' / 'Test succeeded' prefixes. > For instance I think it would look more consistent with something like: > > Test succeeded inside todo block: This is a non flaky todo test which succeeds. > Test succeeded inside flaky block: The message does not reflect that such a test is both flaky *and* todo. Mabe something like this would be clearer: Test succeeded inside flaky todo block: > Test marked todo: > Test marked flaky: > Test failed: > Test succeeded: That can work. [...] > I think flaky_if should be enough, and then there could be some shortcut > global variables for `!strcmp(winetest_platform, "windows" / "wine")`, so it's > not too long to write. So: flaky_if( is_windows ) flaky_if( is_wine ) and plain flaky() I worry that we would risk name collisions but winetest_is_windows would defeat the purpose. (plus we already have some short potentially collision-prone names and it worked out so far) It's tempting to have things line is_win10 but again that's likely either too fine grained or not enough which probably makes it useless (is_win10_2009_or_greater). -- Francois Gouget <fgouget(a)codeweavers.com>

Aug. 31, 2022

Puzzling IPrincipal:UserId check in taskschd

by Francois Gouget

So I'm a bit puzzled by this check in taskschd/task.c's write_principal(): hr = IPrincipal_get_UserId(principal, &bstr); if (hr == S_OK && lstrlenW(bstr)) { hr = write_text_value(stream, L"UserId", bstr); What's puzzling to me is the lstrlenW(bstr) check: * write_principal() has no such check for Id, GroupId, DisplayName and RunLevel. Maybe that's because they are guaranteed to be set and non empty but I could not find any documentation saying so and they are not implemented in Wine. * write_registration_info() is very similar but checks bstr, not what is in effect *bstr: hr = IRegistrationInfo_get_Source(reginfo, &bstr); if (hr == S_OK && bstr) { hr = write_text_value(stream, L"Source", bstr); * We don't seem to have tests showing how this works. I would expect all these property getters to work the same way. So would something like that make more sense? hr = IPrincipal_get_UserId(principal, &bstr); if (hr == S_OK && bstr) { hr = write_text_value(stream, L"UserId", bstr); Dmitry: Do you remember if you wrote the lstrlenW(bstr) check because of some test you did? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS

Aug. 31, 2022

Whenever i use wine this message pop up and the application doesn't run please any help

by anthonyuser33

Sent from my Galaxy

Aug. 31, 2022

[vkd3d] Handling object components within the HLSL compiler.

by Francisco Casas

Hello, I write this update on what I am working on, because I think it introduces some architectural changes that may be good to discuss, or at least mention. Sorry if this text is a bit dense, I hope to send all this as a merge request in a couple of days from now. Albeit we may want to avoid merging before the code freeze ends. More than a week ago, I started trying to implement SM1 resource loads. For this, in particular, it is necessary to infer each sampler's dimensions from usage (a use in a tex2D implies that the sampler is 2D, if not previously declared as such). This gets complicated when there are arrays of samplers, because each sampler component can have a different dimension, and yet being part of the same variable. For solving this I tried introducing a field to allow us to store data for each component within hlsl_ir_var. But this turned to be a complicated solution. As now, we lost the component information in the derefs once we start working with register offsets. I also wanted to have per-component data because I realized that, in general, we are not handling object components properly when they are part of a larger array/struct. But then I thought on an alternative solution: adding a compiler pass to promote each object component within a large variable to a new standalone variable, and prepend a store from this standalone variable to the the original path of the component within the large variable; relying on copy-prop and dce so that all references that refer to these components end up pointing to the new standalone variable. This allows us to use the fields of the hlsl_ir_var (in particular, the register allocation) for each object component, which solves the problem. While that strategy works, I then realized that we cannot use it when targeting SM1 profiles, because we wouldn't be replicating the CTAB (which doesn't introduce a new variable for each component in multi-dimensional object arrays, just increases its register size). SM4 on the other hand seems to do this, separating each sampler and texture as its own variable in the RDEF block. My conclusion then, is that it is a good idea to separate each object component into its own variable in SM4 (as long they are named with the correct subscripts, like "foo.tex[3]"). And while we can't do that in SM1, the good news is that SM1 doesn't allow objects as components of larger types except within (possible multi-dimensional) arrays. Samplers and Textures cannot be components of structs within SM1 profiles, so we only have to support those cases in hlsl_sm1.c. This approach also has the benefit that now, all the component register allocation information should be representable using the fields in the hlsl_ir_var struct and the register size data within hlsl_type [1], since each variable should only care about a single register type now. Storing register allocation data component-wise should not be necessary. So I am implementing a series of patches to ensure that: * When targeting SM4 profiles, all object components are separated into a sole variable. * When targeting SM1 profiles, it is not allowed to declare objects as components of structs; so they will either be a sole variable, or belong to either a (possibly multi-dimensional) array of elements of the same type, as declared within the shader. * SM1 resource loads work. My plan for this series, in terms of patches is: * Parse the tex3D() intrinsic. (already made by zf) * Parse the tex2D() intrinsic. (already made by zf) * Validate that object are not components of structs in SM1. * Properly allocate registers for object arrays for SM1. * Infer sampler register dimensions and write declarations in SM1. * Write resource loads in SM1. * Separate objects as standalone variables in SM4. * Lower combined samplers to separate sampler and texture objects for SM4. (already made by zf) * Lower separate sampler and texture objects to combined samplers for SM1. (already made by zf) It remains to check if object arrays are handled properly in the last two [2], or modify these patches accordingly. Best regards, Francisco. --- [1] I know we intend to remove this field later, when we move register allocation to each sm*_write.c, but I think we probably want to replace those precomputed register offset fields with equivalent SM-specific functions that retrieve the register offset for each component. [2] In SM1 profiles, when there are texture arrays and they are used together with samplers, only one variable is created (not one for each pair of components). This is allowed: ``` Texture2D tex[3][2]; sampler sam; float4 main() : SV_TARGET { return tex[0][1].Sample(sam, float2(1, 2)) + tex[1][0].Sample(sam, float2(1, 2)); } ``` This is allowed (but "not yet implemented" in fxc 9 and 10) ``` Texture2D tex; sampler sam[2][3]; float4 main() : SV_TARGET { return tex.Sample(sam[0][2], float2(1, 2)) + tex.Sample(sam[1][0], float2(1, 2)); } ``` This is not allowed: ``` Texture2D tex[3]; sampler sam[4]; float4 PSMain() : SV_TARGET { return tex[1].Sample(sam[1], float2(1, 2)) + tex[2].Sample(sam[0], float2(1, 2)); } ``` gives: ``` error X4581: Cannot use texture arrays on DX9 targets with multiple samplers. ```

Aug. 30, 2022

Wine staging 7.16 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 7.16 (531 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * wined3d: Use wined3d_array_reserve() in wined3d_adapter_create_output(). * dsdmo: Add Echo FX Support * dsdmo: Add Compressor FX Support * ddraw: Don't set HWTRANSFORMANDLIGHT flag on d3d7 RGB device. Added: * None Updated: * none Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

Aug. 29, 2022