October 2022 - Wine-GitLab - list.winehq.org

Re: [PATCH v6 0/2] MR979: d3d9: Implement d3dx_effect_SetRawValue
by Patrick Hibbs (＠hibbsncc1701) Oct. 22, 2022

Oct. 22, 2022

On Wed Oct 19 09:30:54 2022 +0000, Patrick Hibbs wrote: > changed this line in [version 5 of the diff](/wine/wine/-/merge_requests/979/diffs?diff_id=14510&start_sha=9be4873a7477520f0eb74837f2a269f864a9ac13#6af8d13245d87d86339fd93c308f9d2332f22092_9210_9259) Done in v3 of the patch. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/979#note_11302

1 0

Re: [PATCH v6 0/2] MR979: d3d9: Implement d3dx_effect_SetRawValue
by Patrick Hibbs (＠hibbsncc1701) Oct. 22, 2022

Oct. 22, 2022

On Wed Oct 19 09:30:46 2022 +0000, Patrick Hibbs wrote: > changed this line in [version 5 of the diff](/wine/wine/-/merge_requests/979/diffs?diff_id=14510&start_sha=9be4873a7477520f0eb74837f2a269f864a9ac13#6af8d13245d87d86339fd93c308f9d2332f22092_9196_9222) Done in v3 of the patch. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/979#note_11304

1 0

Re: [PATCH v6 0/2] MR979: d3d9: Implement d3dx_effect_SetRawValue
by Patrick Hibbs (＠hibbsncc1701) Oct. 22, 2022

Oct. 22, 2022

On Wed Oct 19 09:30:44 2022 +0000, Patrick Hibbs wrote: > changed this line in [version 5 of the diff](/wine/wine/-/merge_requests/979/diffs?diff_id=14510&start_sha=9be4873a7477520f0eb74837f2a269f864a9ac13#6af8d13245d87d86339fd93c308f9d2332f22092_9185_9222) Done in v3 of the patch. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/979#note_11305

1 0

Re: [PATCH v6 0/2] MR979: d3d9: Implement d3dx_effect_SetRawValue
by Patrick Hibbs (＠hibbsncc1701) Oct. 22, 2022

Oct. 22, 2022

On Wed Oct 19 09:30:56 2022 +0000, Patrick Hibbs wrote: > changed this line in [version 5 of the diff](/wine/wine/-/merge_requests/979/diffs?diff_id=14510&start_sha=9be4873a7477520f0eb74837f2a269f864a9ac13#6af8d13245d87d86339fd93c308f9d2332f22092_9225_9259) Done in v3 of the patch. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/979#note_11301

1 0

Re: [PATCH v6 0/2] MR979: d3d9: Implement d3dx_effect_SetRawValue
by Patrick Hibbs (＠hibbsncc1701) Oct. 22, 2022

Oct. 22, 2022

On Wed Oct 19 09:30:58 2022 +0000, Patrick Hibbs wrote: > changed this line in [version 5 of the diff](/wine/wine/-/merge_requests/979/diffs?diff_id=14510&start_sha=9be4873a7477520f0eb74837f2a269f864a9ac13#6af8d13245d87d86339fd93c308f9d2332f22092_9265_9259) Done in v3 of the patch. Should I respond to all of these if I think it's been done? Should I mark the thread resolved if I think it's been done, or is that something the reviewer should do? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/979#note_11300

1 0

Re: [PATCH v6 0/2] MR979: d3d9: Implement d3dx_effect_SetRawValue
by Patrick Hibbs (＠hibbsncc1701) Oct. 22, 2022

Oct. 22, 2022

On Tue Oct 18 10:04:52 2022 +0000, Matteo Bruni wrote: > First of all, sorry for the delay. > These are some good tests, in principle. They already show that the > implementation is not correct (e.g. it doesn't sanitize D3DXPT_BOOL > values to 0/1) but I guess you already knew that. > Actually, in regard to that point specifically: assuming that > SetRawValue() does in fact do what it says, it suggests that BOOL values > are stored unchanged and are instead sanitized on use (or e.g. by > GetValue()). That's probably something that we want to fix in our > implementation, separately from SetRawValue() itself. Marking the > relevant tests as todo_wine initially and fixing them afterwards is an option. > The expected results used by the tests are muddied quite a bit by the > fact that the parameter value is not cleared to 0 (or any other value) > between individual tests. That also makes it more complicated than > necessary to add more tests. I'd fix that by explicitly clearing the > tested parameter before each test. > WRT your questions: > 1. I think you can simply compute the expected results beforehand and > put them into static const variables. You can certainly e.g. use your > test_effect_setrawvalue_init_floats() function with some additional > traces to figure out what those values are supposed to be, but I don't > see any reason to recalculate the expected results at runtime in the > final tests. It might make sense to have a comment in the test > explaining what those "weird" expected results actually mean, hard to > say at this point. > 2. If I understand the test correctly, there is no evidence that > SetRawValue() can "overflow" the current parameter. Either way, I think > it's a matter of cutting the value size to the maximum of bytes and > param->bytes or something like that. > 3. For sure :smile:. I think we used the /Fx output parameter to get > DWORD data. > 4. Testing that SetRawValue() doesn't affect the "next" parameter when > used with larger offsets / sizes is probably interesting. I also have a > bunch of comments that I'll mention inline. There's most likely more, > it's not an exhaustive list. > One more thing. I saw you just pushed a new version of the patches, > fixing a couple issues I had noticed. Nice, but generally please wait to > push updates while I have the MR assigned to me, it means I'm actively > reviewing it and changing stuff at that time can be somewhat disruptive > for me. Sorry about the unexpected push, I'll be more careful next time. With regards to the bool fixups, are we sure we want to just write the raw data given to us? I ask because I've also noticed that SetRawValue() has a tendency to promote datatypes when given a single value and a vector / matrix paramater. I.e. float and int become a float4 and int4 respectively for both vectors and matrices. (MSDN calls this behavior a "cast.") This results in the next 3 values in the paramater's buffer being set to zero. Assuming SetRawValue() shouldn't fix the bool values itself, should it also avoid fixing the ints and floats? If so, how should we indicate the need for a fixup to other functions? There doesn't seem to be any infrastructure to support that in wine currently. (We could abuse the paramater block support for that, but see the speculation below.) The float and int promotions were the reason I didn't clear the paramater after each test. As doing so would cause us to miss the writes to the next 3 values in the paramater. As they would already be set to zero before the call. Should I still go ahead and clear the paramaters after each test anyway? As a dirty hack, I added a call to zero out the paramaters after each test with a 4x4 matrix of zero ints in v3 of the test. That call is commented out in the push, but if you enable it it will succeed for most of the tests under win10. (I disabled it before I fixed the string test crashes. So it may work fine now, I haven't checked.) I haven't tried checking the paramaters after the current one for alterations. I was going to put that in it's own set of tests. This part is speculation but, if it is a valid use of SetRawValue() to set adjacent paramaters regardless of type with one call, then the entire set of paramaters for a given effect needs to be in the same memory block. (Which seems to be not the case in wine, as there are plenty of calls to heap_alloc() / heap_realloc() using the param->data pointer in effect.c.) That would also imply that there is a specific ordering of paramaters in memory as well. Which would need to be tested for. If this behavior is combined with the bool assumption above, then we'd also need to test for order of operations too. Assuming all of that needs to be done, how do we split this up? Because I have a feeling that this patchset is going to be rather large in scope. (If all of the assumptions and speculation are true that is.) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/979#note_11299

1 0

Re: [PATCH v6 0/2] MR979: d3d9: Implement d3dx_effect_SetRawValue
by Patrick Hibbs (＠hibbsncc1701) Oct. 22, 2022

Oct. 22, 2022

On Wed Oct 19 09:30:52 2022 +0000, Patrick Hibbs wrote: > changed this line in [version 5 of the diff](/wine/wine/-/merge_requests/979/diffs?diff_id=14510&start_sha=9be4873a7477520f0eb74837f2a269f864a9ac13#6af8d13245d87d86339fd93c308f9d2332f22092_9206_9250) That was a leftover I missed from a previous iteration of the test. It's been removed in v3 of the patch. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/979#note_11292

1 0

Re: [PATCH v5 0/5] MR944: win32u: Make desktop resize logic asynchronous.
by Rémi Bernon Oct. 22, 2022

Oct. 22, 2022

On Tue Oct 18 23:34:47 2022 +0000, Rémi Bernon wrote: > The cause of the failure was that we're using incorrect mutex names in > some places for the `display_device_init` mutex. In some unlikely event, > which becomes apparently more likely with the changes here, > `D3DKMTOpenAdapterFromGdiDisplayName` was able to enter the mutex CS at > the same time as the devices are refreshed, and fails to find the video > device in `HKLM\\HARDWARE\\DEVICEMAP\\VIDEO`, returning an error which > ultimately triggers an allocation failure. > This should never happens as the device refresh should also be done > while holding the same mutex, but because the names were wrong it was > two different mutexes. I've opened > https://gitlab.winehq.org/wine/wine/-/merge_requests/1099 to fix this. > This is for the `d3drm` tests failure at least, I didn't look at the > ddraw ones, hopefully it's the same problem. Marvin reported the same `ddraw7` errors in !1099, so they may not be fixed. I'm not able to reproduce them locally so far, using the same kind of setup as Gitlab and running the tests in a loop. These take a longer time, especially as I'm running the other d3d tests with ddraw in case they have an impact, so it's possible I'm simply being unlucky, or that they are somehow only happening on the testbot now. I'll probably stop looking for now and see how things improve with that MR. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/944#note_11293

1 0

[PATCH v5 0/2] MR979: d3d9: Implement d3dx_effect_SetRawValue
by Patrick Hibbs (＠hibbsncc1701) Oct. 22, 2022

Oct. 22, 2022

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=46012 Signed-off-by: Patrick Hibbs <hibbsncc1701(a)gmail.com> -- v5: d3dx9/tests: Implement tests for d3dx_effect_SetRawValue(). https://gitlab.winehq.org/wine/wine/-/merge_requests/979

3 3

Re: [PATCH v6 0/2] MR979: d3d9: Implement d3dx_effect_SetRawValue
by Patrick Hibbs (＠hibbsncc1701) Oct. 22, 2022

Oct. 22, 2022

On Wed Oct 19 09:30:34 2022 +0000, Patrick Hibbs wrote: > changed this line in [version 5 of the diff](/wine/wine/-/merge_requests/979/diffs?diff_id=14510&start_sha=9be4873a7477520f0eb74837f2a269f864a9ac13#6af8d13245d87d86339fd93c308f9d2332f22092_9089_9004) The same issue with strings occurs with Texture and shader types. I.e. Paramater is rendered irretrievable. Calling it's relevant GetXXX() function causes a crash if it's a scalar. Calling GetParamaterByName() will return an invalid handle. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/979#note_11291

1 0