More commits in one MR than usual, but the implementations are quite short, and it's good to get them all in at once.
--
v2: vkd3d: Implement GetCopyableFootprints1().
vkd3d: Implement CreatePlacedResource1().
vkd3d: Implement CreateCommittedResource2().
vkd3d: Implement GetResourceAllocationInfo2().
tests/d3d12: Add tests for GetCopyableFootprints1().
tests/d3d12: Add tests for CreatePlacedResource1().
tests/d3d12: Add tests for CreateCommittedResource2().
tests/d3d12: Add tests for GetResourceAllocationInfo2().
vkd3d: Add ID3D12Device8 interface stubs.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/683
--
v4: vkd3d-shader: Refactor common code for vkd3d_shader_compile().
vkd3d-shader: Refactor common code for vkd3d_shader_scan().
vkd3d-shader: Treat the HLSL case specially in vkd3d_shader_compile().
vkd3d-shader: Treat the HLSL case specially in vkd3d_shader_scan().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/679
~~This applies on top of !662, the last four commits belong here.~~
Here we compute a topological order (plus some additional properties) of the shader blocks. Eventually the blocks will be emitted precisely in this order, after having been enriched with structured control flow information.
--
v9: vkd3d-shader/ir: Keep loops contiguous in the topological sort.
vkd3d-shader/ir: Dump the topological order of the control flow graph.
vkd3d-shader/ir: Topologically sort the control flow graph.
vkd3d-shader/ir: Allow adding to a block list without checking for duplicates.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/672
Buffers could be used with 'shared' and 'single' modifiers. There is a bit more work left to do to support this - 'shared' needs a compiler flag to enable child effects to be useful, and 'single' is not a keyword.
--
v4: vkd3d-shader/hlsl: Allow modifiers on buffer declarations.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/666
Basically !427, but in the form of a custom test driver script.
If I am not mistaken, for the driver script to run properly it is necessary to run
"autoreconf" in the source directory and call the configure script again in the build directory.
The output when running tests would be the same we currently have except for tests that don't PASS,
in that case, detailed information for each failing line will appear. Make a failing test to try it!
--
v5: tests: Get detailed information on failing tests.
tests: Copy autotool's testsuite driver script.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/661
I wanted to use ._xy element access to make it shorter, but that attempt was crushed by the reality - such indexing apparently compiles but does not produce correct element access loads. I'm going to update once this is fixed.
--
v10: vkd3d-shader/hlsl: Add determinant() function.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/329
--
v6: vkd3d-dxbc: Add an option to choose the output filename.
vkd3d-dxbc: Add an option to re-emit the shader with the correct checksum.
vkd3d-dxbc: Add an option to ignore checksum.
vkd3d-shader/dxbc: Add flag to ignore the DXBC checksum.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/582
This MR adds support for some more OpenGL functionality:
* wglCreateContextAttribsARB
* wglShareLists
* wgl(Get)SwapIntervalEXT
I originally intended to also include a fix for the translucency issue seen in some compositors, by using EGL_EXT_present_opaque. However, I'll hold off for now since I am seeing some issues with certain hardware and pixel formats when using this extension. Initial investigation indicates it is a problem in Mesa. For anyone who is affected by the translucency issue and wants to try out the patch in their local build anyway, it is at: https://gitlab.winehq.org/afrantzis/wine/-/commit/0685d1d2cfc126e2bb546fe2c…
--
A question for the upcoming work:
In the next OpenGL part I would like to focus on `WGL_ARB_pixel_format`. I was thinking that if a driver implements `wglGetPixelFormatAttribivARB` then it would be possible, in theory at least, to have a default implementation of `wglChoosePixelFormatARB` (and `wglGetPixelFormatAttribfvARB`) in `opengl32`. I am tempted to do this, instead of adding one more driver specific full implementation, although I am not yet sure if there any driver specific considerations or behaviors that would pose issues with such approach. Thoughts?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5264
On Fri Mar 8 17:52:04 2024 +0000, Stefan Dösinger wrote:
> So on my Radeon 9000 (r250), Windows XP, this produces no pick results
> for the HW device:
> ```
> ddraw1.c:15913: Driver string: "ati2dvag.dll"
> ddraw1.c:15914: Description string: "Mobility Radeon 9000"
> ddraw1.c:15915: Driver version 0.0.0.0
> ddraw1.c:15638: Test failed: run {84e63de0-46aa-11cf-816f-0000c020156e}
> ddraw1.c:15689: Test failed: Got incorrect number of pick records
> (expected 1): 0.
> ddraw1.c:15696: Test failed: Got incorrect number of pick records
> (expected 3): 0.
> ddraw1.c:15728: Test failed: Got incorrect number of pick records
> (expected 1): 0.
> ddraw1.c:15737: Test failed: Got incorrect number of pick records
> (expected 1): 0.
> ddraw1.c:15765: Test failed: Got an unexpected ratio of pick
> hits/misses: 0/256.
> ddraw1.c:15805: Test failed: Got incorrect number of pick records
> (expected 1): 0.
> ddraw1.c:15817: Test failed: Got incorrect number of pick records
> (expected 3): 0.
> ddraw1.c:15829: Test failed: Got incorrect number of pick records
> (expected 1): 0.
> ddraw1.c:15838: Test failed: Got incorrect number of pick records
> (expected 1): 0.
> ddraw1.c:15866: Test failed: Got an unexpected ratio of pick
> hits/misses: 0/256.
> ddraw1.c:15638: Test failed: run {a4665c60-2673-11cf-a31a-00aa00b93356}
> 08f4:ddraw1: 204 tests executed (0 marked as todo, 0 as flaky, 12
> failures), 0 skipped.
> ```
> I'll try to figure out why and see if I can test the game that inspired
> the original author to implement this method to see if it works.
> The RGB device works as expected.
The test passes on the HW device of my way newer Radeon Polaris card on Windows 11. As of now I am unsuccessful in getting my Radeon 9000 from 2002 to produce any pick results.
On a quick test run it seems Lego Island is happy with setting *count = 0 in IDirect3DDevice::GetPickRecords. That prevents it from trying to essentially malloc a random amount of memory. But I am not entirely certain, the menu of this game is confusing. I was (intellectually) unable to start a game even on Windows...
I am downloading FIGHTING to see if it works on my old machine and to see if it uses a HW device or just the RGB device. Judging by the screenshots it might just software render.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3422#note_64027