March 2024 - Wine-gitlab - list.winehq.org

[PATCH 0/1] MR5420: d2d1/tests: Get rid of test shader blobs.
by Nikolay Sivov (＠nsivov) 28 Mar '24

28 Mar '24

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5420

2 1

[PATCH v6 0/1] MR4698: winewayland.drv: Add unaccelerated pointer support
by Grigory Vasilyev (＠h0tc0d3) 28 Mar '24

28 Mar '24

Adds the registry key `HKEY_CURRENT_USER\\Software\\Wine\\Wayland Driver\\unaccelerated_pointer` witch allows raw input. This makes it easier to calculate the same sensitivity in different games, use sensitivity calculators, and easily change values when changing DPI and do not depend on the compositor or OS. For example, you want to set the sensitivity to half as much, and sensitivity curves in libinput are more difficult to calculate than in the games themselves. -- v6: winewayland.drv: Add unaccelerated pointer support https://gitlab.winehq.org/wine/wine/-/merge_requests/4698

2 1

Re: [PATCH v2 0/4] MR745: hlsl: Avoid HLSL_CLASS_OBJECT, part 1.
by Francisco Casas (＠fcasas) 28 Mar '24

28 Mar '24

Francisco Casas (@fcasas) commented about libs/vkd3d-shader/hlsl.y: > if (!(modifiers & HLSL_STORAGE_STATIC)) > var->storage_modifiers |= HLSL_STORAGE_UNIFORM; > > - if (ctx->profile->major_version < 5 && (var->storage_modifiers & HLSL_STORAGE_UNIFORM) && > - type_has_object_components(var->data_type, true)) > + if (ctx->profile->major_version < 5 && (var->storage_modifiers & HLSL_STORAGE_UNIFORM) > + && var->data_type->class == HLSL_CLASS_STRUCT && type_has_object_components(var->data_type)) I think we would lose coverage for when we have an array of structs with object components. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/745#note_66419

1 0

[PATCH 0/4] MR745: hlsl: Avoid HLSL_CLASS_OBJECT, part 1.
by Zebediah Figura (＠zfigura) 28 Mar '24

28 Mar '24

HLSL_CLASS_OBJECT does not really have much in common, and a lot of code currently uses it assuming that all objects are resources, which is not actually true. Most users of HLSL_CLASS_OBJECT want to check for specific types, and so we can simplify code a fair amount by promoting all object "base types" to top-level classes. This series is a first step, comprising some cleanup towards that goal. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/745

2 4

[PATCH v4 0/10] MR739: vkd3d-shader/hlsl: Parse state blocks, part 1.
by Francisco Casas (＠fcasas) 28 Mar '24

28 Mar '24

I am still working on parsing the remaining features of the effects framework, such as the FX functions for the state block entries -- such as SetBlendState() -- and the "compile" and "Compileshader()" syntax. However, after adding the many tests included in 2/7 and reading the feedback from !708, I think that this first batch of patches are going in the right direction in terms of parsing the state blocks and how to represent them internally. As Nikolay mentioned in https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/708#note_64421 and https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/708#note_64444 there are many types of state blocks entries, which should be identified for writing the effect metadata. A part that may cause discussion on this series is that I kept the representation of `struct hlsl_state_block_entry` using a `hlsl_block` to keep it general enough to represent all these types of state block entries, thinking on later implementing a helper to identify which type of entry we are dealing with. Even though, as Nikolay pointed out, the instruction set of fx shaders is different, I still think that HLSL IR should be enough to represent the rhs of state blocks, and hopefully we won't need to pollute it too much (apart from the introduction of hlsl_ir_undeclared_load in 4/7 to avoid creating a new variable) if we find operations that are fx-specific, since I intend to represent calls to FX functions with the same `struct hlsl_state_block_entry`, given that they cannot be called in regular HLSL code. There are many validations that are applied on regular HLSL that still should be applied to state blocks, such as the use of valid swizzles and the correct use of operators. -- v4: vkd3d-shader/hlsl: Allow KW_PIXELSHADER and KW_VERTEXSHADER as stateblock lhs. vkd3d-shader/hlsl: Store state block on pass variables. vkd3d-shader/hlsl: Parse list of state blocks. vkd3d-shader/hlsl: Introduce hlsl_ir_stateblock_constant. vkd3d-shader/hlsl: Parse and store state blocks on variables. tests: Add tests for "compile" and CompileShader() syntax. tests: Add tests for fxgroup syntax. tests: Test function call syntax for state blocks. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/739

4 16

[PATCH 0/1] MR5417: avifil32: Update lCurrentFrame in IGetFrame_fnGetFrame().
by Paul Gofman (＠gofman) 28 Mar '24

28 Mar '24

Fixes slow motion videos in Joe Danger 2: The Movies. Currently lCurrentFrame is never updated and it decodes all the frames from start. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5417

3 2

[PATCH 0/6] MR606: Constant buffer reflection
by Zebediah Figura (＠zfigura) 28 Mar '24

28 Mar '24

This is an attempt to invent a vkd3d-shader interface, and begin to implement the relevant parts of ID3D12ShaderReflection in vkd3d-utils. This series is missing most Doxygen documentation, mostly because I feel very uncertain about this interface and don't want to put in the significant effort to write documentation until I'm sure it's settled. This series also has tests for bindings but not the implementation, mainly because I didn't want to bother splitting those tests out to a separate patch right now, and I see no harm in having them already there and marked todo... Here is a long list of already open questions: * As always, should anything be named differently? * In particular, I've decided to give the variables names that make it clear this is d3d-specific code. I think trying to make this generic enough to work for other shader types is a fool's errand. * Should we even try to use this interface for sm1? It's mostly already a subset of dxbc; the only addition is the constant register set... * Should we bother with interfaces? These count as "constant buffers", they have a distinct type, and they have some extra data that we'd need to account for. * Should we bother with lib_* targets? This mostly means allowing for a single shader to hold multiple sets of reflection data. Note that this would also affect descriptor info and STAT info, although not signature info. * I've tried to pass through most data directly, partly out of a concern that that's what d3dcompiler probably does, and so trying to interpret it could break an extremely hypothetical and unlikely application. More saliently, converting to a more sensible representation just to convert back is extra work that I'm not really sure I see a point for. But if we want to change the interface regardless, here are some ideas: - enum vkd3d_shader_d3d_buffer_type could just be more flags. - I think a buffer's size is redundant and can be calculated from its contained variables. Same for field offsets (unless packoffset affects this?) - "constant_register" could be flags too? But we already have a type for them, so I don't think that's better. - The kind/type interface is weird in several ways. Majority could be a type or var flag; objects could be classes... * Fields of struct vkd3d_shader_d3d_type could be 16-bit (like they are in the RDEF section). The main reason I didn't do this is because we can't force a 16-bit enum, although we could define the field as uint16_t. But we could also just define the other "count" fields as 16-bit. * I suspect I already know the answer to this one, but... If this is all going to be d3d specific anyway... do we really care about having this in vkd3d-shader? Or, alternatively, we could provide an interface that's friendlier than COM, but still use the d3d struct types instead of copy-pasting and changing all the names to vkd3d-shader (which is a bit exhausting, honestly—not just because of rewriting but because of documentation. The latter is certainly a self-created problem, but so is the former.) * vkd3d_shader_d3d_field currently has a hole in it on LP64; is that a problem? (I think it's the only structure with a hole in it.) * As long as this is a d3d interface, should we go ahead and make it "scan_d3d_info" and add all the d3d-specific STAT block stuff? One extra anticipatory note on how this differs from Wine's implementation: This implementation does *not* store types in an rbtree, nor deduplicate them. The main reason for this is that native doesn't deduplicate types (I have tests for this, later in my local branch) and it avoids what seems like a significant complication to the vkd3d-shader interface. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/606

6 37

[PATCH 0/4] MR741: Cachestub
by Stefan Dösinger 28 Mar '24

28 Mar '24

None -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/741

2 7

[PATCH 0/2] MR742: vkd3d-shader/fx: Add an option to include empty buffers in the effect binary.
by Nikolay Sivov (＠nsivov) 28 Mar '24

28 Mar '24

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/742

2 2

[PATCH v3 0/31] MR541: RFC: Shader cache for vkd3d
by Stefan Dösinger 28 Mar '24

28 Mar '24

Here is a preview of my shader cache work for early comments. It isn't complete, but does successfully cache things. What's there: * A new vkd3d API that is used internally for caching, can be used to implement the ID3D12ShaderCacheSession interface and hopefully be used by wined3d as well * Simple saving and loading of the cached objects * It is used to cache render passes, root signatures and pipeline states What is not yet there * Partial cache loading and eviction * ID3D12ShaderCacheSession - largely because it needs bumping ID3D12Device up to version 9, which may bring unrelated regressions. For this and tests see my "cache-rework" branch (which * Cache file compression * Incremental updates of cache files - right now they are rewritten from scratch on exit * Loading the cache in an extra thread. The pipeline state creation code will need some refactor for that I am not quite happy yet with the two patches that write and reload actual graphics pipelines. The way I am storing the d3d settings aren't quite consistent yet either - in some cases I use the d3d input data as key directly, in others I store them as values attached to a hash value. The latter is usually the case if I need to cross-reference something, e.g. have a link from the pipeline state to the root signature. This kind of setup shows how wined3d can build a chain of linked state though. There are also known issues with locking, explained in comments in the patches. -- v3: DEBUG: Make cache profiling more visible Revert "simple benchmark" simple benchmark tests: Add tests for ID3D12ShaderCacheSession. vkd3d: Implement ID3D12ShaderCacheSession::SetDeleteOnDestroy. vkd3d: Implement ID3D12ShaderCacheSession on top of vkd3d_shader_cache. vkd3d: Add a stub ID3D12ShaderCacheSession implementation. vkd3d: Stub device methods up to D3D12Device9. vkd3d: Load cached pipelines in a separate thread. vkd3d: Try to find a read-only cache in C:\windows\scache vkd3d: Remove the custom render pass lock. vkd3d: Cache and preload compute pipelines. vkd3d: Add some cache efficiency debug code. vkd3d: Add EXT_pipeline_creation_feedback. vkd3d: Catch and release graphics pipelines. vkd3d: Store graphics pipelines in the cache. vkd3d: Precreate root signatures from cache vkd3d: Keep root signatures around. vkd3d: Store render passes in the on-disk cache and recreate them on startup. vkd3d: Store the VK pipeline cache in an on-disk vkd3d cache. vkd3d: Keep the application name around. vkd3d: Add a win32 version of vkd3d_get_program_name. vkd3d: Basic shader cache writing and reading. vkd3d: Replace the custom render pass cache with vkd3d_shader_cache. vkd3d: Implement vkd3d_shader_cache_enumerate. vkd3d: Add cache locking. vkd3d: Implement vkd3d_shader_cache_get. vkd3d: Implement vkd3d_shader_cache_put. vkd3d: Create and destroy the shader cache tree. vkd3d: Implement shader_cache_open/close. vkd3d: Define and stub the shader cache API. This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/541

3 10