ElementalWarrior

Did you copy into your prefix the win meta files?

It's not my code really. I believe I got it from this bugzilla thread: https://bugs.winehq.org/show_bug.cgi?id=45868 Iirc the original author did get a change merged, but it doesn't resolve it for affinity. If I did debug it and try to understand the issue, I don't remember the cause now. I originally made this change like 2 years ago it seems. At one point I emailed the original author, but he never replied.

I found the best performance was by using wayland and vulkan. Which you can do by running winetricks renderer=vulkan and then set the DISPLAY env var to nothing: export DISPLAY= NOTE if you set the env var like this, anything you run from the terminal you applied this to may be affected. Or just run wine + photo.exe like so: DISPLAY= wine ~/.wine/drive_c/Program\ Files/Affinity/Photo\ 2/Photo.exe Note that you may need to change where Photo.exe is installed if you use a different wine prefix.

On modern wine-10.3, you can start affinity photo without any of my changes. To install it, this commit is still needed commit e27add553a490b3fdf91051251f85a83a93f51c7 (ElementalWarrior/affinity-photo2-wine10.3, affinity-photo2-wine10.3) Author: James McDonnell <topgamer7@gmail.com> Date: Sun Feb 26 12:56:24 2023 -0800 shell32/iconcache: Call LoadIconW diff --git a/dlls/shell32/iconcache.c b/dlls/shell32/iconcache.c index 8f9519d2ca8..7e9a37db44d 100644 --- a/dlls/shell32/iconcache.c +++ b/dlls/shell32/iconcache.c @@ -1007,9 +1007,7 @@ HRESULT WINAPI SHGetStockIconInfo(SHSTOCKICONID id, UINT flags, SHSTOCKICONINFO if (flags) FIXME("flags 0x%x not implemented\n", flags); - sii->hIcon = NULL; - if (flags & SHGSI_ICON) - sii->hIcon = LoadIconW(GetModuleHandleW(sii->szPath), MAKEINTRESOURCEW(sii->iIcon)); + sii->hIcon = LoadIconW(GetModuleHandleW(L"shell32.dll"), MAKEINTRESOURCEW(IDI_SHELL_FILE)); sii->iSysImageIndex = -1; TRACE("%3d: returning %s (%d)\n", id, debugstr_w(sii->szPath), sii->iIcon);

Yeah, I was mostly referring to the bug in wine. Which happens regardless of building wine with whatever tooling they use. Technically they can probably use whatever license for their packaging code they want, so long as they build wine in a separate process/repo. But I'm no lawyer, and I haven't looked into it. Every once and a while i rebase my changes to latest wine to see if it is more stable and Vulkan/Wayland/etc works better. But not much has seemed to have improved. It's a lot of work tracking down issues and trying to patch things. And I barely use graphics editing software.

I think there is a bug in the wine code for whatever function is called here. It kinda looks like the paths are rendered backwards. Maybe there is an ignored parameter in the code. But it's unlikely something someone can fix without debugging and submitting a patch

While Apple mac's are very nice computers. I don't agree with their business practices. Primarily about how they treat their hardware. The fact that a device "owner" cannot simply replace a button, or a screen, without profit capture by Apple, and the replacement done by Apple. But also you cannot side load your own binaries onto their phones. So I put my "vote" of my money, elsewhere.

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