January 2024 - wine-gitlab

Re: [PATCH v3 0/4] MR4888: wined3d: Avoid assuming the GL backend in (what can be) common code.
by Stefan Dösinger (＠stefan) 27 Jan '24

27 Jan '24

I just noticed this on wine-gitlab, and I am pretty sure the check was necessary at the time for the (IWineD3DTextureImpl *) stateblock->textures[0] cast. Color keys have since been moved from surfaces to textures, and as Henri mentioned, textures unified. I don't know of a particular design reason why D3DRS_COLORKEYENABLE wouldn't work with cube textures. I don't know of any application that combines them though (the only ddraw thing I know that uses cube textures is a dx7 sdk sample), so I wouldn't be surprised if you hit driver bugs if you try. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4888#note_59255

1 0

Re: [PATCH v3 0/3] MR4857: Draft: gdi32,win32u: Implement D3DKMTEnumAdapters2.
by Zhiyi Zhang (＠zhiyi) 27 Jan '24

27 Jan '24

On Tue Jan 23 10:02:40 2024 +0000, Krzysztof Bogacki wrote: > I'm trying to follow the suggestion to read SetupAPI registry data but > I'm having some difficulties, with the major one being: I'm not actually > sure where that data is. Your sample code doesn't seem to read the > registry and just returns/enumerates an empty device set. What am I > missing here? > On the other hand, I had a look at where win32u writes stores > information when `add_gpu` is called and figured that I can (probably) > use whatever this function writes. This gives me two possible leads: > 1. > `HKML\System\CurrentControlSet\Control\Class\{4D36E968-E325-11CE-BFC1-08002BE10318}\${gpu_id}`. > Although easier to enumerate, this doesn't have the most important piece > of data: GPU LUID, which I'd have to retrieve from the second key anyway > and it doesn't have any links to second keys I could use to open it > directly, so it's not very viable for my purposes here. > 2. `HKML\System\CurrentControlSet\Enum\PCI\${pci_id}\${gpu_idx}`. This > does have GPU LUID I can easily retrieve but some of the other data is > kept only as wide strings which I'd need to parse if I wanted to use > them (if only for bookkeeping purposes). E.g. the only way I see to > retrieve PCI vendor and device IDs would be parsing `${pci_id}` but as > far as I can tell, I can't just use `snwscanf` to process 2-byte wide > strings in Unixlibs. > Of course, I could pick the second version and read only the LUID while > ignoring PCI IDs and GPU ID/index completely, but I'd like to ask first > if it's correct thing to do before I commit to that. HKML\\System\\CurrentControlSet\\Enum\\PCI is the correct key to enumerate GPUs. > the only way I see to retrieve PCI vendor and device IDs would be parsing ${pci_id} but as far as I can tell, I can't just use snwscanf to process 2-byte wide strings in Unixlibs. Do you really need PCI IDs for D3DKMTEnumAdapters2? If you do, I am sure there is a way to parse them. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4857#note_59247

1 0

[PATCH 0/5] MR608: vkd3d-shader/hlsl: Lower casts from/to ints for SM1.
by Francisco Casas (＠fcasas) 27 Jan '24

27 Jan '24

For temporary registers, SM1-SM3 integer types are internally represented as floating point, so, in order to perform a cast from ints to floats we need a mere MOV. By the same token, casts from floats to ints can also be implemented with a FLOOR + MOV, where the FLOOR is then lowered by the lower_floor() pass. For constant integer registers "iN" there is no operation for casting from a floating point register to them. For address registers "aN", and the loop counting register "aL", vertex shaders have the "mova" operation but we haven't used these registers in any way yet. We probably would want to introduce these as synthetic variables allocated in a special register set. In that case we have to remember to use MOVA instead of MOV in the store operations, but they shouldn't be src or dst of CAST operations. Regarding constant integer registers, in some shaders, constants are expected to be received formatted as an integer, such as: int m; float4 main() : sv_target { float4 res = {0, 0, 0, 0}; for (int k = 0; k < m; ++k) res += k; return res; } which compiles as: // Registers: // // Name Reg Size // ------------ ----- ---- // m i0 1 // ps_3_0 def c0, 0, 1, 0, 0 mov r0, c0.x mov r1.x, c0.x rep i0 add r0, r0, r1.x add r1.x, r1.x, c0.y endrep mov oC0, r0 but this only happens if the integer constant is used directly in an instruction that needs it, and as I said there is no instruction that allows converting them to a float representation. Notice how a more complex shader, that performs operations with this integer variable "m": int m; float4 main() : sv_target { float4 res = {0, 0, 0, 0}; for (int k = 0; k < m * m; ++k) res += k; return res; } gives the following output: // Registers: // // Name Reg Size // ------------ ----- ---- // m c0 1 // ps_3_0 def c1, 0, 0, 1, 0 defi i0, 255, 0, 0, 0 mul r0.x, c0.x, c0.x mov r1, c1.y mov r0.y, c1.y rep i0 mov r0.z, r0.x break_ge r0.y, r0.z add r1, r0.y, r1 add r0.y, r0.y, c1.z endrep mov oC0, r1 Meaning that the uniform "m" is just stored as a floating point in "c0", the constant integer register "i0" is just set to 255 (hoping it is a high enough value) using "defi", and the "break_ge" involving c0 is used to break from the loop. We could potentially use this approach to implement loops from SM3 without expecting the variables being received as constant integer registers. According to the D3D documentation, for SM1-SM3 constant integer registers are only used by the 'loop' and 'rep' instructions. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/608

2 5

[PATCH 0/1] MR4653: d3d11: Stub D3D11_FEATURE_D3D11_OPTIONS2 handling in CheckFeatureSupport().
by Matteo Bruni (＠Mystral) 26 Jan '24

26 Jan '24

--- Required by Need for Speed Heat. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4653

5 5

Re: [PATCH v3 0/4] MR4888: wined3d: Avoid assuming the GL backend in (what can be) common code. - approved
by Alexandre Julliard (＠julliard) 26 Jan '24

26 Jan '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4888

1 0

Re: [PATCH v2 0/5] MR4897: wined3d: Implement shader stencil reference export. - approved
by Alexandre Julliard (＠julliard) 26 Jan '24

26 Jan '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4897

1 0

Re: [PATCH v2 0/1] MR4907: devenum: Use switch statements for moniker type handling. - approved
by Alexandre Julliard (＠julliard) 26 Jan '24

26 Jan '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4907

1 0

Re: [PATCH v2 0/3] MR4917: winegstreamer: Use WAVEFORMATEX in the AAC decoder transform. - approved
by Alexandre Julliard (＠julliard) 26 Jan '24

26 Jan '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4917

1 0

Re: [PATCH v7 0/2] MR4022: wined3d: Expose the image view usage to the Vulkan driver. - approved
by Alexandre Julliard (＠julliard) 26 Jan '24

26 Jan '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4022

1 0

Re: [PATCH v2 0/3] MR4945: user32/tests: Add mouse input tests with layered windows. - approved
by Alexandre Julliard (＠julliard) 26 Jan '24

26 Jan '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4945

1 0

2025

2024

2023

2022

wine-gitlab January 2024