ElementalWarrior

Find a package appropriately named, but version 6.2.0 instead

Try with rum ElementalWarrior-9.13 /home/john/.wineAffinity2 winetricks dotnet48 -q -f

Well I got opencl checked on amd. Although it doesn't work if dxvk is installed into the wineprefix. New branch: affinity-photo3-wine9.13-part3 I immediately call the clSetEventCallback. Which means it likely isn't working as expected. Because it should be asynchronous, after the job is done. But :shrug:. I tried writing a wrapper function. But it just crashed. I'm not sure how easy it is to call PE functions from wine server process.

I found I was using a rocm driver from back in January. After installing opencl-amd from aur, the error from the driver went away. Now I get a lot more opencl logs, but I'm guessing the opencl implementation in wine isn't good enough yet for amd here. I am seeing that clSetEventCallback issue as well. 0150:trace:opencl:clGetDeviceInfo (00005555777DDD80, 0x4039, 8, 00007FFFFE4F0F98, 0000000000000000) 0150:trace:opencl:clGetDeviceInfo (00005555777DDD80, 0x101f, 8, 00007FFFFE4F0F90, 0000000000000000) 0150:trace:opencl:clGetDeviceInfo (00005555777DDD80, 0x101f, 8, 00007FFFFE4F0F90, 0000000000000000) 0150:trace:opencl:clCreateBuffer (000055557D491230, 1, 4096, 0000000000000000, 00007FFFFE4F0EC0) :3:rocdevice.cpp :2418: 48075526256 us: [pid:718937 tid:0x79eeb281a740] Device=0x5555777ddd70, freeMem_ = 0x1feffeffc 0150:trace:opencl:clGetMemObjectInfo (000055557A39DC90, 4354, 8, 00007FFFFE4F0EC0, 0000000000000000) 0150:trace:opencl:clGetDeviceInfo (00005555777DDD80, 0x1035, 4, 00007FFFFE4F1000, 0000000000000000) 0150:trace:opencl:clEnqueueWriteBufferRect (000055557D6027F0, 0000555576884390, 0, 00007FFFFE4F0F80, 00007FFFFE4F0F80, 00007FFFFE4F0F98, 4, 0, 4, 0, 000079EE900D8000, 0, 0000000000000000, 0000000000000000) 0150:trace:opencl:clEnqueueFillBuffer (000055557D6027F0, 000055557A39DC90, 00007FFFFE4F0E70, 1, 0, 324, 0, 0000000000000000, 000079EB96992B90) 0150:trace:opencl:clSetEventCallback (0000555576A1D050, 0, 00006FFFE09FB207, 000079EB971D0C10) 0150:fixme:opencl:wrap_clSetEventCallback not yet implemented 0150:trace:opencl:clFlush (000055557D6027F0) :3:rocvirtual.cpp :724 : 48075526441 us: [pid:718937 tid:0x79ee8b1396c0] Arg0: void* buf = ptr:0x79edd2601000 obj:[0x79edd2601000-0x79edd2602000] :3:rocvirtual.cpp :799 : 48075526456 us: [pid:718937 tid:0x79ee8b1396c0] Arg2: uint pattern_size = val:1 :3:rocvirtual.cpp :799 : 48075526462 us: [pid:718937 tid:0x79ee8b1396c0] Arg3: uint alignment = val:16 :3:rocvirtual.cpp :799 : 48075526467 us: [pid:718937 tid:0x79ee8b1396c0] Arg4: ulong end_ptr = val:134062343721280 :3:rocvirtual.cpp :799 : 48075526471 us: [pid:718937 tid:0x79ee8b1396c0] Arg5: uint next_chunk = val:256 :3:rocvirtual.cpp :3028: 48075526476 us: [pid:718937 tid:0x79ee8b1396c0] ShaderName : __amd_rocclr_fillBufferAligned :3:rocvirtual.cpp :724 : 48075526487 us: [pid:718937 tid:0x79ee8b1396c0] Arg0: void* buf = ptr:0x79edd2601140 obj:[0x79edd2601000-0x79edd2602000] :3:rocvirtual.cpp :799 : 48075526494 us: [pid:718937 tid:0x79ee8b1396c0] Arg2: uint pattern_size = val:1 :3:rocvirtual.cpp :799 : 48075526499 us: [pid:718937 tid:0x79ee8b1396c0] Arg3: uint alignment = val:1 :3:rocvirtual.cpp :799 : 48075526504 us: [pid:718937 tid:0x79ee8b1396c0] Arg4: ulong end_ptr = val:134062343721284 :3:rocvirtual.cpp :799 : 48075526507 us: [pid:718937 tid:0x79ee8b1396c0] Arg5: uint next_chunk = val:256 :3:rocvirtual.cpp :3028: 48075526512 us: [pid:718937 tid:0x79ee8b1396c0] ShaderName : __amd_rocclr_fillBufferAligned :3:rocvirtual.hpp :66 : 48075526524 us: [pid:718937 tid:0x79ee8b1396c0] Host active wait for Signal = (0x79ee005fae00) for 100000 ns :3:rocvirtual.hpp :75 : 48075526632 us: [pid:718937 tid:0x79ee8b1396c0] Host blocked wait for Signal = (0x79ee005fae00)

@thoxy I've seen that assert error before. There are github threads in the rocm code base about it. It's an assertion made by the amd opencl drivers. Thats why you don't find the file. Because its referencing the amd source code. This way they can see where the assertion was, and try to fix the issue. I'm pretty sure opencl works when I run darktable, so I wonder if something about the clGetPlatformIDs function is used to determine opencl support in Affinity

Alright, after reverting the commit causing the segfault, we have this: affinity-photo2-wine9.13-part2 Nothing shows up when I include +opencl in WINEDEBUG Which is kinda odd in itself I suppose

Hmm, looks like I built that branch improperly. Seems some commit is causing segfaults when I try to configure. I thought I worked around it, but apparently not well enough.

Here's a zip. patches.zip

Currently I'm just creating a new branch pretty well every time I rebase. And sometimes I have to drop commits off the branch if they get upstreamed, or re-written. For example __avg__ re-wrote the RoResolveNamespace changes I made, and dxcore stubs I had created, and wintypes changes. So its probably not something well suited to being automated. If you want to create patches, I'd suggest just doing: git format-patches 72bb43949782400fdb52daf100b90cc97d1a1063^..affinity-photo2-wine9.13 Where the commit hash is the first one found in this link:

I created another branch. Updated off the most recent wine changes. It's the bleeding edge, so you may see issues in other in it. I also included recent WIP patches for vulkan child window handling. This **should** fix (**mostly**) using wayland and vulkan for affinity photo. It did seem a bit buggy still. For example its a bit flickery at times, and it still didn't work on wine's d3d11 and below handling. It still doesn't work when using pure wayland for me, only XWAYLAND works for me on sway. But if you run Photo with the vulkan renderer, and dxvk installed. It should work somewhat normally. If you don't want to muck with regedit to set the renderer, you can just send the environment variable: `WINE_D3D_CONFIG="renderer=vulkan"`. So to be clear, this branch includes: - Remi Bernon's child window handling: https://gitlab.winehq.org/wine/wine/-/merge_requests/5573 - Remi Bernon's transparent window changes: https://gitlab.winehq.org/wine/wine/-/merge_requests/6025#note_75558 - Alexandros Frantzis's work for vulkan + gl child window handling: https://gitlab.winehq.org/wine/wine/-/merge_requests/6107 - __avg__'s patches for hardware acceleration: https://github.com/oh-ok/wine-affinity-patches/tree/main - My changes, with some of them reverted in place of __avg__'s. I could not get hardware acceleration working on AMD. Although AMD's OpenCL functionality is a bit a of a cluster f*** with regards to ROCM and HIP and all that crap going on. @__avg__ if you have thoughts on this, I'm happy to hear them The branch is named affinity-photo2-wine9.13 -- You can find it here: https://gitlab.winehq.org/ElementalWarrior/wine/-/tree/affinity-photo2-wine9.13?ref_type=heads

Run winecfg and make sure you have your windows version set to something new, like windows 10

Wine doesn't use windows drivers. But OpenCL isn't going to be a direct mapping to windows drivers. Its a library that translates function calls to being called on your gpu. Linux has native OpenCL drivers, so in theory wine will take the windows OpenCL library calls, and call the linux native OpenCL library. Which will then utilize your gpu. Problems here could include: 1. Do you have the linux native opencl packages installed for your gpu. 2. How full is wine's implementation of opencl calls to native opencl libraries. 3. Is your wine version compiled with opencl support 4. Is linux opencl native supporting your graphics card? Does it support it well? 5. Does wine call opencl functionality that isn't supported by your card.

But I suppose not new enough for the changes other than mine.

Well. 8.6 is still greater than 8.2

As Vaniglia seems to be usebottles "vanilla" (mostly) wine. https://docs.usebottles.com/components/runners