This MR optimizes and makes correctness improvements to the window_surface flush implementation:
1. Implement a buffer queue to avoid constantly allocating new buffers.
2. Take into account the bounds of the window_surface flush and track per-buffer damage to reduce copying from the window_surface.
3. Copy from the window_surface only pixel data that lies within the flushed bounds. Maintain the latest contents for pixels outside these bounds, by copying them from the latest valid buffer.
4. Communicate damaged surface regions to the compositor to allow it to perform more efficient pixel data transfers (e.g., texture uploads).
Thanks!
--
v2: winewayland.drv: Send surface damage region to the compositor.
winewayland.drv: Update only the flushed bounds from the window_surface.
winewayland.drv: Track damaged buffer regions.
winewayland.drv: Use a buffer queue for window_surface.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3234
This replaces Wine's 14 copies of debugstr_hstring.
--
v4: include: Introduce wine_dbgstr_hstring and debugstr_hstring.
include: Use correct header guard name in winstring.h.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3157
vkd3d-shader/hlsl: Support evaluated expressions for sample count in multisampled textures declarations.
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v2: vkd3d-shader/hlsl: Disallow certain instruction types from constant expressions.
vkd3d-shader/hlsl: Support evaluated expressions for sample count in multisampled textures declarations.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/256
```
On Margate Sands.
I can connect
Nothing with nothing.
```
--
v4: vkd3d-shader/d3dbc: Scan for the maximum temporary register index.
vkd3d-shader: Record a global temporary count per sm4 shader.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/255
In a declaration with multiple variables, the variables must be created
before the initializer of the next variable is parsed. This is required
for initializers such as:
```
float a = 1, b = a, c = b + 1;
```
The solution is to parse the type information in the same rule as the first variable ('a' in this case) so that it can be declared before the parser reaches the initializer for the following variables.
To initialize the following variables, the type information is passed along from the first variable's struct parse_variable_def to the next and so on.
---
Solves https://bugs.winehq.org/show_bug.cgi?id=54484, pointed out by @nsivov.
--
v4: vkd3d-shader/hlsl: Declare vars individually when parsing struct declarations.
vkd3d-shader/hlsl: Declare vars individually when parsing regular declarations.
vkd3d-shader/hlsl: Split declare_vars().
tests: Test multiple variable initializers.
tests: Test semantics in uniform variables.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/250
On my Nvidia GeForce GTX 1050 Ti `ddxddy.shader_test` doesn't pass because of considerably different numeric results.
As Giovanni pointed out, this is because my GPU uses the fine derivate and not the coarse derivate to implement ddx() and ddy().
For this reason, the result for ddx|ddy() is quantized so that the test passes if the GPU uses either coarse or fine derivates.
Additionally, tests for both ddx_coarse|ddy_coarse() and ddx_fine|ddy_fine() are added, that expect a more precise result.
--
v4: vkd3d-shader/hlsl: Support fine derivates.
vkd3d-shader/hlsl: Support coarse derivates.
tests: Quantize regular and coarse derivate test results.
tests: Make ddx() and ddy() test behave correctly for shader models < 4.
tests: Test coarse and fine derivates.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/224
This is obviously questionable, as it requires reaching into Wine internals in
tests (beyond simply detecting whether Wine is in use).
However, we are at a point where, for d3d10 and above, the Vulkan renderer works
well enough in general to see real use [in fact, in my experience it usually
works better than the GL renderer], and at this point I think avoiding
regressions is quite important. It is currently difficult to run tests with it
when the results contain so much noise, and I think we need to solve this
problem, by actually marking which tests work on each backend.
We could in theory expose the renderer through some adapter string, but I
believe in the past applications have been sensitive about the contents of
adapter strings.
Fixing either renderer to reach and maintain parity is not feasible. The GL
renderer is not going away, but regrettably GL as an API is abandoned by
Khronos, and important features we need in order to implement some Direct3D
features will probably never be introduced into GL. Moreover, the amount of
effort that would be required to reach parity is not small, and itself would all
need to be verified manually.
--
v2: d3d10core/tests: Mark test failures specific to the Vulkan or GL renderers.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3232
> The part that doesn't thrill me is the fact that DXGI still directly accesses the VkQueue object, which I tend to see as an internal implementation detail to vkd3d. On the other hand it's nice that we don't need new API from vkd3d (even if, in the future, we were to need something other than vkQueueSubmit() and vkQueuePresentKHR()).
For what it's worth, it was a fairly explicit design decision early on to expose the underlying Vulkan objects for d3d12 devices and command queues, as well as to allow the creation of d3d12 resources on top of existing Vulkan images, for the purpose of interoperation with other Vulkan code. I.e., the idea is that it should be possible to integrate vkd3d into a larger Vulkan application to draw some parts using the d3d12 API, while everything else is drawn using Vulkan.
The internal queueing of command queue operations on the vkd3d level is unfortunate in that regard; ideally we just wouldn't do that. This MR could probably do a better job of explaining why we need to do that in some cases, and what kind of command queue operation sequences could result in out-of-order presentation.
If we're going to need to introduce a DXGI worker thread anyway, could we just make vkd3d_acquire_vk_queue() block until there are no longer any operations queued?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3165#note_37779
Sub / Function can be on one line, but only if there's brackets.
```
| Storage_opt tFUNCTION Identifier ArgumentsDecl BodyStatements tEND tFUNCTION
```
This leads to sometimes to `link_statements` being called with `head` being NULL, probably because now the `:` can be parsed as `Statement` in `BodyStatements`.
Also note that this introduces another shift/reduce conflict, could be related, but I don't understand it well enough. Feedback would be appreciated, I'm still learning bison.
--
v3: vbscript: Support one-line sub/function.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3206
This MR optimizes and makes correctness improvements to the window_surface flush implementation:
1. Implement a buffer queue to avoid constantly allocating new buffers.
2. Take into account the bounds of the window_surface flush and track per-buffer damage to reduce copying from the window_surface.
3. Copy from the window_surface only pixel data that lies within the flushed bounds. Maintain the latest contents for pixels outside these bounds, by copying them from the latest valid buffer.
4. Communicate damaged surface regions to the compositor to allow it to perform more efficient pixel data transfers (e.g., texture uploads).
Thanks!
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3234
Shader Model 6 introduces a 16-bit float (half) type, and 16-bit and 64-bit integer types. Storing extra info in the type enum simplifies checking if a type is any integer, floating point or numeric type, and the declaration of SPIR-V types. The benefits depend on using enum vkd3d_data_type in the backend instead of vkd3d_shader_component_type.
Patch 2 is difficult to split because types typically flow through to vkd3d_spirv_get_type_id(), so partial changes would require new calls to conversion functions which would be deleted again later.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/263
On Mon Jul 3 18:50:55 2023 +0000, Zebediah Figura wrote:
> > With this implementation it should be relatively easy to present with
> whatever API is available, though I don't really know how the options
> you mention work, so maybe there is some additional complexity I'm not
> aware of.
> Sounds great :-)
> The "fullscreen window styles" problem (and one of the older d3d
> contributors can correct me on this) is basically that some applications
> use ddraw (and other versions?) to present to a fullscreen window,
> expecting the presented area to cover the whole screen, but wgl (and
> Vulkan) swapchains only present to the client rect. We currently get
> around this by changing the window styles to remove all the nonclient
> decorations, but that breaks some applications too. What we want is a
> way to present to the actual window, and part of the idea is that using
> D3DKMTPresent() is the architecturally correct way to do this.
> I don't quite know what the concerns are for dcomposition either. Zhiyi
> was looking at that and ran into a wall, but he probably can at least
> describe the problem in greater detail.
> There are also some thoughts about using D3DKMTPresent() to deal more
> efficiently with some cases where we currently have to do a GDI blit.
> I'm fuzzy on these details though; again Henri can explain it better.
What D3DKMTPresent() does is that it sends a command to the compositor/DWM to display contents. Since DWM is responsible for drawing the window decoration, it allows the nonclient decorations to be overwritten without affecting window styles. The complexity here is that we don't have a DWM. Implementing a DWM and making it work with the host WM is not trivial, if not impossible. Also, the window decoration is currently handled by the host system, for example, Mutter. Having D3DKMTPresent() is certainly more architecturally correct. That way, DWM can intercept these surfaces and do the composition without tearing and not worry about the surface lifetime.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3165#note_37742
This is obviously questionable, as it requires reaching into Wine internals in
tests (beyond simply detecting whether Wine is in use).
However, we are at a point where, for d3d10 and above, the Vulkan renderer works
well enough in general to see real use [in fact, in my experience it usually
works better than the GL renderer], and at this point I think avoiding
regressions is quite important. It is currently difficult to run tests with it
when the results contain so much noise, and I think we need to solve this
problem, by actually marking which tests work on each backend.
We could in theory expose the renderer through some adapter string, but I
believe in the past applications have been sensitive about the contents of
adapter strings.
Fixing either renderer to reach and maintain parity is not feasible. The GL
renderer is not going away, but regrettably GL as an API is abandoned by
Khronos, and important features we need in order to implement some Direct3D
features will probably never be introduced into GL. Moreover, the amount of
effort that would be required to reach parity is not small, and itself would all
need to be verified manually.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3232
Required for !1857 to not break when comctl32 version 6 isn't requested by application (in particular, found this in [qapitrace](https://github.com/apitrace/apitrace)).
Manifest resource id and assembly identity name match with Windows.
For isolation purposes, activation context is disabled while emitting events.
--
v13: comdlg32: Enable visual styles when showing IFileDialog.
comdlg32: Return E_UNEXPECTED if IFileDialog is already shown.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2068
> With this implementation it should be relatively easy to present with whatever API is available, though I don't really know how the options you mention work, so maybe there is some additional complexity I'm not aware of.
Sounds great :-)
The "fullscreen window styles" problem (and one of the older d3d contributors can correct me on this) is basically that some applications use ddraw (and other versions?) to present to a fullscreen window, expecting the presented area to cover the whole screen, but wgl (and Vulkan) swapchains only present to the client rect. We currently get around this by changing the window styles to remove all the nonclient decorations, but that breaks some applications too. What we want is a way to present to the actual window, and part of the idea is that using D3DKMTPresent() is the architecturally correct way to do this.
I don't quite know what the concerns are for dcomposition either. Zhiyi was looking at that and ran into a wall, but he probably can at least describe the problem in greater detail.
There are also some thoughts about using D3DKMTPresent() to deal more efficiently with some cases where we currently have to do a GDI blit. I'm fuzzy on these details though; again Henri can explain it better.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3165#note_37677
Sub / Function can be on one line, but only if there's brackets.
```
| Storage_opt tFUNCTION Identifier ArgumentsDecl BodyStatements tEND tFUNCTION
```
This leads to sometimes to `link_statements` being called with `head` being NULL, probably because now the `:` can be parsed as `Statement` in `BodyStatements`.
Also note that this introduces another shift/reduce conflict, could be related, but I don't understand it well enough. Feedback would be appreciated, I'm still learning bison.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3206
Required for !1857 to not break when comctl32 version 6 isn't requested by application (in particular, found this in [qapitrace](https://github.com/apitrace/apitrace)).
Manifest resource id and assembly identity name match with Windows.
For isolation purposes, activation context is disabled while emitting events.
--
v12: comdlg32: Enable visual styles when showing IFileDialog.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2068
On Fri Jun 30 17:01:00 2023 +0000, Zebediah Figura wrote:
> So in isolation I think the solution proposed by this patch set is fine,
> and even looks prettiest. *But* what I remember from that discussion—and
> Henri will undoubtedly be able to express this more eloquently—is that
> the concern is
> (a) we might want to do something more complicated than just
> vkQueuePresent()—cf. the issues about fullscreen window styles /
> presenting to the client rect. I'm not sure but this might also turn out
> to be an issue for DirectComposition.
> (b) we might want to plumb presentation through D3DKMTPresent() [which
> may be necessary to achieve the above], and it will probably not be
> possible to do any vkd3d calls from the Unix side.
I pushed a new implementation incorporating the changes you're suggesting, and honestly I don't dislike it: https://gitlab.winehq.org/giomasce/wine/-/commits/chianti (only the last three commits changed in a meaningful way; or maybe at all). With this implementation it should be relatively easy to present with whatever API is available, though I don't really know how the options you mention work, so maybe there is some additional complexity I'm not aware of.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3165#note_37623
In a declaration with multiple variables, the variables must be created
before the initializer of the next variable is parsed. This is required
for initializers such as:
```
float a = 1, b = a, c = b + 1;
```
The solution is to parse the type information in the same rule as the first variable ('a' in this case) so that it can be declared before the parser reaches the initializer for the following variables.
To initialize the following variables, the type information is passed along from the first variable's struct parse_variable_def to the next and so on.
---
Solves https://bugs.winehq.org/show_bug.cgi?id=54484, pointed out by @nsivov.
--
v3: vkd3d-shader/hlsl: Declare vars individually when parsing struct declarations.
vkd3d-shader/hlsl: Declare vars individually when parsing regular declarations.
vkd3d-shader/hlsl: Split declare_vars().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/250
These replace Wine's 14 copies of debugstr_hstring.
--
v3: wintypes: Replace debugstr_hstring with debugstr_h.
windows.ui: Replace debugstr_hstring with debugstr_h.
windows.system.profile.systemmanufacturers: Replace debugstr_hstring with debugstr_h.
windows.perception.stub: Replace debugstr_hstring with debugstr_h.
windows.networking: Replace debugstr_hstring with debugstr_h.
windows.media: Replace debugstr_hstring with debugstr_h.
windows.media.speech/tests: Replace debugstr_hstring with debugstr_h.
windows.media.speech: Replace debugstr_hstring with debugstr_h.
windows.globalization: Replace debugstr_hstring with debugstr_h.
windows.devices.enumeration: Replace debugstr_hstring with debugstr_h.
threadpoolwinrt: Replace debugstr_hstring with debugstr_h.
graphicscapture: Replace debugstr_hstring with debugstr_h.
cryptowinrt: Replace debugstr_hstring with debugstr_h.
combase: Replace debugstr_hstring with debugstr_h.
include: Introduce wine_dbgstr_h and debugstr_h.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3157
On Sun Jul 2 20:51:00 2023 +0000, Alex Henrie wrote:
> atlbase.h, atlcom.h, and atlwin.h are also C++-only in Windows, but Wine
> allows them to be used in C and uses them in its own C code. I assumed
> that the same logic would apply to atlconv.h, but if that doesn't work
> then we may want to introduce a new helper in include/wine.
We have the other headers but we use them only for the ATL implementation. They are not something we'd want to use globally.
As for a new include/wine helper, there doesn't seem to be enough usage of that function to justify it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3191#note_37561
On Sun Jul 2 20:29:53 2023 +0000, Alexandre Julliard wrote:
> A2BSTR is a C++ only macro, it's not something we'd want to use as a
> standard replacement.
atlbase.h, atlcom.h, and atlwin.h are also C++-only in Windows, but Wine allows them to be used in C and uses them in its own C code. I assumed that the same logic would apply to atlconv.h, but if that doesn't work then we may want to introduce a new helper in include/wine.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3191#note_37559
On Sun Jul 2 20:14:43 2023 +0000, Alex Henrie wrote:
> @mstefani Thanks for the feedback. Would you be willing to remove your
> downvote now that the scope of this MR has been reduced?
Sorry, forgot about that
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3191#note_37557
On Sun Jul 2 17:27:26 2023 +0000, Michael Stefaniuc wrote:
> My comment was referring to the tests where we convert ascii string literals.
> The two left commits seem fine though as those don't just convert ascii
> string literals in the code.
> But I had just a quick look at them.
@mstefani Thanks for the feedback. Would you be willing to remove your downvote now that the scope of this MR has been reduced?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3191#note_37554