Release for 1.8.1 containing targeted fixes for issues uncovered by Wine tests, in particular an assert which is currently preventing Wine tests from running with 1.8.
There were other "safe fix" patches I noticed after 1.8, but on the precedent of 1.7.1 I didn't pick any of them.
I've marked this as a draft since it's supposed to be a merge request into a vkd3d-1.8.x branch, but that doesn't currently exist, and it'll need Alexandre to create it as I understand. In the meantime I'm submitting the patches so they can be reviewed.
-- v3: Release 1.8.1.
From: Zebediah Figura zfigura@codeweavers.com
Instead of asserting.
(cherry picked from commit 1bd873fb2b887d6b4a21d0f009374ddf7cff8303) --- libs/vkd3d-shader/d3dbc.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libs/vkd3d-shader/d3dbc.c b/libs/vkd3d-shader/d3dbc.c index 712613ac..38a32dea 100644 --- a/libs/vkd3d-shader/d3dbc.c +++ b/libs/vkd3d-shader/d3dbc.c @@ -1693,7 +1693,12 @@ static void write_sm1_sampler_dcls(struct hlsl_ctx *ctx, struct vkd3d_bytecode_b if (var->objects_usage[HLSL_REGSET_SAMPLERS][i].used) { sampler_dim = var->objects_usage[HLSL_REGSET_SAMPLERS][i].sampler_dim; - assert(sampler_dim != HLSL_SAMPLER_DIM_GENERIC); + if (sampler_dim == HLSL_SAMPLER_DIM_GENERIC) + { + /* These can appear in sm4-style combined sample instructions. */ + hlsl_fixme(ctx, &var->loc, "Generic samplers need to be lowered."); + continue; + }
reg_id = var->regs[HLSL_REGSET_SAMPLERS].id + i; write_sm1_sampler_dcl(ctx, buffer, reg_id, sampler_dim);
From: Zebediah Figura zfigura@codeweavers.com
(cherry picked from commit 6e370777b484237f94800ec95c7b241755697b33) --- libs/vkd3d-shader/d3dbc.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/libs/vkd3d-shader/d3dbc.c b/libs/vkd3d-shader/d3dbc.c index 38a32dea..9a327fee 100644 --- a/libs/vkd3d-shader/d3dbc.c +++ b/libs/vkd3d-shader/d3dbc.c @@ -2086,5 +2086,9 @@ int hlsl_sm1_write(struct hlsl_ctx *ctx, struct hlsl_ir_function_decl *entry_fun out->code = buffer.data; out->size = buffer.size; } + else + { + vkd3d_free(buffer.data); + } return ret; }
From: Zebediah Figura zfigura@codeweavers.com
(cherry picked from commit 71afb78126488008f64716ae1df41910a8c5a2ef) --- libs/vkd3d-shader/d3dbc.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/libs/vkd3d-shader/d3dbc.c b/libs/vkd3d-shader/d3dbc.c index 9a327fee..0e03f43b 100644 --- a/libs/vkd3d-shader/d3dbc.c +++ b/libs/vkd3d-shader/d3dbc.c @@ -2068,7 +2068,6 @@ static void write_sm1_instructions(struct hlsl_ctx *ctx, struct vkd3d_bytecode_b int hlsl_sm1_write(struct hlsl_ctx *ctx, struct hlsl_ir_function_decl *entry_func, struct vkd3d_shader_code *out) { struct vkd3d_bytecode_buffer buffer = {0}; - int ret;
put_u32(&buffer, sm1_version(ctx->profile->type, ctx->profile->major_version, ctx->profile->minor_version));
@@ -2081,7 +2080,10 @@ int hlsl_sm1_write(struct hlsl_ctx *ctx, struct hlsl_ir_function_decl *entry_fun
put_u32(&buffer, D3DSIO_END);
- if (!(ret = buffer.status)) + if (buffer.status) + ctx->result = buffer.status; + + if (!ctx->result) { out->code = buffer.data; out->size = buffer.size; @@ -2090,5 +2092,5 @@ int hlsl_sm1_write(struct hlsl_ctx *ctx, struct hlsl_ir_function_decl *entry_fun { vkd3d_free(buffer.data); } - return ret; + return ctx->result; }
From: Zebediah Figura zfigura@codeweavers.com
--- ANNOUNCE | 89 ++++++++++------------------------------------------ configure.ac | 2 +- 2 files changed, 18 insertions(+), 73 deletions(-)
diff --git a/ANNOUNCE b/ANNOUNCE index 86d654d2..02cfa5f7 100644 --- a/ANNOUNCE +++ b/ANNOUNCE @@ -1,16 +1,12 @@ -The Wine team is proud to announce that release 1.8 of vkd3d, the Direct3D to +The Wine team is proud to announce that release 1.8.1 of vkd3d, the Direct3D to Vulkan translation library, is now available.
-This release contains improvements that are listed in the release notes below. -The main highlights are: - - - Support for still many more HLSL features and intrinsics. - - Performance improvements to vkd3d descriptor updates. - - Miscellaneous bug fixes. +This is a bugfix release, only containing targeted fixes for a couple +of defects that had slipped in in vkd3d 1.8.
The source is available from the following location:
- https://dl.winehq.org/vkd3d/source/vkd3d-1.8.tar.xz + https://dl.winehq.org/vkd3d/source/vkd3d-1.8.1.tar.xz
The current source can also be pulled directly from the git repository:
@@ -21,73 +17,22 @@ for the complete list.
----------------------------------------------------------------
-What's new in vkd3d 1.8 -======================= - - -*** libvkd3d - -- Performance improvements have been made to the code that handles descriptor - updates. In some applications the improvement can be quite significant. - -- Host-visible descriptor heaps are persistently mapped on creation. Some - applications access resource data from the CPU after calling Unmap(), and - that's supposed to work in practice. - -- 1-dimensional texture unordered-access views and shader resource views are - implemented. - -- Shader resource view, unordered access view, and constant buffer view root - descriptors with NULL GPU addresses are supported. - -- Direct3D 12 descriptor heap destruction is delayed until all contained - resources are destroyed. +What's new in vkd3d 1.8.1 +=========================
*** libvkd3d-shader
-- New features for the HLSL source type: - - Support for the ternary conditional operator "?:". - - Support for "discard" statements. - - Support for the "packoffset" keyword. - - Support for semantics on array types. - - Support for RWBuffer loads and stores. - - Register allocation for arrays and structures of resources and samplers - is implemented. - - Support for the SV_IsFrontFace pixel shader system-value semantics. - - Support for using constant expressions as array sizes and indices. - - Support for dynamic selection of vector components. - - Support for the following intrinsic functions: - - D3DCOLORtoUBYTE4() - - any() - - asfloat() - - ddx() and ddy() - - fmod() - - log(), log2(), and log10() - - sign() - - trunc() - - The SampleBias(), SampleCmp(), SampleCmpLevelZero(), and SampleGrad() - texture object methods are implemented. - - Support for the case-insensitive variants of the "vector" and "matrix" - data types. - - Parser support for the "unroll" loop attribute. A warning is output for - "unroll" without iteration count, and an error is output when an iteration - count is specified. Actual unrolling is not implemented yet. - - Parser support for RWStructuredBuffer resources. - - Parser support for SamplerComparisonState objects. Note that outputting - compiled effects is not supported yet, but parsing these allows shaders - containing SamplerComparisonState state objects to be compiled. - -- More improvements to HLSL support for the Direct3D shader model 1/2/3 - profiles. - -- The section alignment of DXBC blobs produced by - vkd3d_shader_serialize_dxbc() matches those produced by d3dcompiler more - closely. +- Previous releases included support for compiling HLSL to legacy Direct3D + bytecode. In certain cases vkd3d-shader would report that compilation had + failed due to an unimplemented feature through shader messages, but at the + same time return VKD3D_OK and an incorrect shader binary. These cases are + fixed in vkd3d 1.8.1.
-- The "main" function for shaders produced by the SPIR-V target is always - terminated, even when the source was a TPF shader without explicit "ret" - instruction. +- In previous releases, when compiling from HLSL to legacy Direct3D bytecode, + using .Sample() and similar methods would fail due to the feature not yet + being implemented. In vkd3d 1.8, this instead triggers an internal assertion. + This is fixed in vkd3d 1.8.1; the feature is still not implemented, but + compilation once again fails gracefully.
-- Relative addressing of shader input registers is supported by SPIR-V - targets. +- Some memory leaks related to HLSL compilation are fixed in vkd3d 1.8.1. diff --git a/configure.ac b/configure.ac index f9039158..20c9d2b8 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.69]) -AC_INIT([vkd3d],[1.8]) +AC_INIT([vkd3d],[1.8.1])
AC_CONFIG_AUX_DIR([bin]) AC_CONFIG_MACRO_DIR([m4])
Ugh, I cannot believe I did not test this properly. I've removed a fix for a commit that wasn't part of 1.8, which doesn't even compile when cherry-picked.
This merge request was approved by Giovanni Mascellani.
This is fine for me (I didn't really test the MR with Wine, though).
BTW, not a strong opinion, but I don't think we need to be too conservative about including bugfixes in stable releases. If we have targeted bugfixes that shouldn't be too risky, it's ok to include them.
BTW, not a strong opinion, but I don't think we need to be too conservative about including bugfixes in stable releases. If we have targeted bugfixes that shouldn't be too risky, it's ok to include them.
It depends a bit on where we want to go with these. 1.7.1 and 1.8.1 were fixes for things that arguably shouldn't have made it into 1.7 and 1.8 in the first place. I could see us moving to a scheme where we did more regular bugfix releases though; e.g. 1.9.1 a month after 1.9, and 1.9.2 a month before 1.10. At that point it would probably make sense to try to include a bit more in those releases.
It depends a bit on where we want to go with these. 1.7.1 and 1.8.1 were fixes for things that arguably shouldn't have made it into 1.7 and 1.8 in the first place. I could see us moving to a scheme where we did more regular bugfix releases though; e.g. 1.9.1 a month after 1.9, and 1.9.2 a month before 1.10. At that point it would probably make sense to try to include a bit more in those releases.
Personally I don't feel the need for timed stable releases (though, again, it's not something I would actively oppose to). My point of view is that somebody using 1.x should be able to switch to 1.x.y with a rather strong trust that that's not going to break their application (while moving to 1.x+1 might require some more review and testing). Within this boundary every patch that makes the user's life easier should be acceptable.
My point of view is that somebody using 1.x should be able to switch to 1.x.y with a rather strong trust that that's not going to break their application (while moving to 1.x+1 might require some more review and testing).
No, x.y+1 is supposed to be strictly better than x.y; if we need to release x.y+1.1 that means we screwed up, and I'd like not having to release 1.9.1 in a couple of months.
Now, we may come to the conclusion that that's too hard, that the x.y releases are really more like release candidates, and that we should expect people to move from x.y.1 to x.y+1.1. If that's where we're headed, I'd rather just have explicit release candidates for e.g. Wine to test with before we make the x.y releases.
We may also/instead come to the conclusion that the roughly three months between releases is too long, and that we'd like to get targetted fixes for specific applications out sooner than that. That would be where regular x.y.z releases come in.
I don't think we're quite there yet for either of those scenarios, but that's my current thinking.
With the vkd3d 1.9 release planned for September 20 in a few weeks, and the issues addressed by this MR not being too consequential outside the Wine tests, Alexandre mentioned preferring to just wait for vkd3d 1.9 as far as Wine is concerned.
If there are other users of vkd3d that would like to have a 1.8.1 release to address these issues, now would be the time to let us know.
This merge request was closed by Zebediah Figura.
-
Giovanni Mascellani (＠giomasce) -
Henri Verbeet (＠hverbeet)
-
Zebediah Figura
-
Zebediah Figura (＠zfigura)