ElementalWarrior

Don't use ai to answer questions for technical projects like this. It does a garbage job. Affinity does not get to choose whether opencl uses d12 under the hood. Its opencl implementation dependent. OpenCL is akin to defining a Car with 2 doors and an engine. It could be a mercedes, or a ford, but the application doesn't care as long as you tell it that you have 2 doors and an engine. If you see vkd3d logs when running affinity with vkd3d installed, then it is in some manner using d12. Their feature list page lists d3d10. So likely most of their application is written to use that functionality. https://affinity.serif.com/en-us/designer/full-feature-list/ But any advanced graphics application often support multiple libraries (metal/d3d/opengl/vulkan) and a varying combination of these, these days. --- Wine already has built-in DirectX12 to satisfy Affinity This is false. Although I wouldn't be surprised if most package libraries install vkd3d as a dependency for you. If vkd3d is available when building Wine, then Wine will use it to support Direct3D 12 applications. https://gitlab.winehq.org/wine/vkd3d

dxvk is an implementation of directx 8 through 11. vkd3d is an implementation of 12. They are separate dlls. When installed, typically they are placed into your wineprefix by their installers. Wine has its own implementation of d3d 8-11 in its source code. But it relies on vkd3d for 12 (vkd3d id a wine project itself). The only way to really tell which is being used is to pay attention to logging when you start an application with wine. The libraries have some environment variables you can turn on to get more debugging information. I've found that dxvk vs wine have different bugs/quirks. For a while dxvk worked better for me for affinity. Then with some patches, wine worked better. But there are kinda like a permutation of things to try. using or not using any of the following can be different experience wise: wayland/x11, vulkan/gl wine d3d, vkd3d, dxvk.

STFU; complain somewhere else.

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