ElementalWarrior
-
Posts
76 -
Joined
-
Last visited
Reputation Activity
-
ElementalWarrior got a reaction from Wanesty in Affinity Suite V2 on Linux [ Wine ]
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.
-
ElementalWarrior got a reaction from Zode in Affinity Suite V2 on Linux [ Wine ]
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
-
ElementalWarrior got a reaction from __avg__ in Affinity Suite V2 on Linux [ Wine ]
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.
-
ElementalWarrior got a reaction from __avg__ in Affinity Suite V2 on Linux [ Wine ]
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)
-
ElementalWarrior got a reaction from Wanesty in Affinity Suite V2 on Linux [ Wine ]
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
-
ElementalWarrior got a reaction from SevenStart in Affinity Suite V2 on Linux [ Wine ]
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
-
ElementalWarrior got a reaction from Wanesty in Affinity Suite V2 on Linux [ Wine ]
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
-
ElementalWarrior got a reaction from __avg__ in Affinity Suite V2 on Linux [ Wine ]
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
-
ElementalWarrior got a reaction from Sorn in Affinity Suite V2 on Linux [ Wine ]
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
-
ElementalWarrior got a reaction from Snapseed in Affinity Suite V2 on Linux [ Wine ]
Run winecfg and make sure you have your windows version set to something new, like windows 10
-
ElementalWarrior got a reaction from Wanesty in Affinity Suite V2 on Linux [ Wine ]
Run winecfg and make sure you have your windows version set to something new, like windows 10
-
ElementalWarrior got a reaction from J.S. Bach in Affinity Suite V2 on Linux [ Wine ]
Run winecfg and make sure you have your windows version set to something new, like windows 10
-
ElementalWarrior got a reaction from Snapseed in Affinity Suite V2 on Linux [ Wine ]
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.
-
ElementalWarrior reacted to Loren Dias in Affinity Suite V2 on Linux [ Wine ]
MSIX is basically a archive. You can unzip it via command. (MSI is not) Here's what my extract command looked like.
unzip -d affinity-photo-2.1.1_2023-08-09_00-25 affinity-photo-2.1.1_2023-08-09_00-25.msix You can also use a GUI:
https://help.gnome.org/users/file-roller/3.26/introduction.html.en
https://peazip.github.io/
After the whole thing is extracted, If memory serves right the .exe you are looking for is "[Archive]/App/Photo.exe"
Edit: Morning coffee didn't hit, if you can get a MSIX that would probably be ideal, if not I wanted to attach this information to this thread for others in case they get confused on how to begin an install.
-
ElementalWarrior got a reaction from Snapseed in Affinity Photo running on Linux with Bottles
Yeah I'd refrain from trying to debug this until you install a more recent version of wine. Either building my branch, or trying v1 on vanilla wine.
-
ElementalWarrior got a reaction from Snapseed in Affinity Photo running on Linux with Bottles
Closed means it wasn't merged. You want this link: https://gitlab.winehq.org/wine/wine/-/merge_requests/1444/diffs. This was merged.
-
ElementalWarrior got a reaction from Snapseed in Affinity Photo running on Linux with Bottles
Ah, I stand corrected. Checking the submodule on the git repo I linked. It's using wine 8.0.
I would probably not recommend using wine-ge for Affinity then. It's more gaming oriented anyway.
-
ElementalWarrior got a reaction from Snapseed in Affinity Photo running on Linux with Bottles
wine 8.14 is 12 minor versions newer than wine 8.2. So you will have my changes.
wine-ge is a custom build maintained by a guy who's handle is GloriousEggroll. Pretty sure that's what GE stands for. https://github.com/GloriousEggroll/wine-ge-custom
So you're at the mercy of what he builds if you're using wine-ge.
Look in the console a the same time you get that error, and see if you have logs about FIXME's or ERRORS.
-
ElementalWarrior got a reaction from Snapseed in Affinity Photo running on Linux with Bottles
1. RoResolveNamespace
I hacked in RoResolveNamespace calls specifically to get photo running: https://gitlab.winehq.org/ElementalWarrior/wine/-/commit/3de8daf601acd6d6f4dd95c7cba842050049e685
So any lines about RoResolveNamespace not followed by Found ... aren't resolving properly.
RoResolveNamespace docs: Determine the direct children, types, and sub-namespaces of the specified Windows Runtime namespace, from any programming language supported by the Windows Runtime.
Its responsible for looking up types, etc for the runtime. Which is used by C#, and WinRT/ C++/CX. So if I didn't hack in the path to the winmd files, it isn't going to resolve those types properly.
WinRT is window's effort to export headers/have an interface for any language to look up types, or build bindings to their libraries.
2. Fixme's
Fixme's are logging statements, written by wine devs as the stub out, or point out missing functionality. In effect, because the functionality is missing, our linux code will IN THEORY perform FASTER than windows, because it is doing less work.
If you have concerns that the logging itself is slowing your application performance, turn off application logging `WINEDEBUG=-all`
The fixme's are there to give other devs a heads up, that if something isn't working properly, and you see the fixme, that maybe if you implement this functionality, your application may work.
3. File dialog
In my experience, you only have folder selected if it has a background on the list entry in the left panel. So it kinda looks like you have no folder selected. Although experiences in that dialog may depend on the linux distribution you are using vs what I am using.
I had the best experience with it by opening the checkboxes FIRST, then ONLY selecting a folder by clicking the text, for the folder I wanted to browse/save to.
-
ElementalWarrior got a reaction from Snapseed in Affinity Photo running on Linux with Bottles
10 months ago vs 12 months ago. The one I linked is similar to the one you linked. I just took out a bunch of maybe controversial changes so it would get merged. It should address the saving issues. And would be in somewhere along the lines of wine 8.2 or 8.3
-
ElementalWarrior got a reaction from Wanesty in Affinity Photo running on Linux with Bottles
Ah, I stand corrected. Checking the submodule on the git repo I linked. It's using wine 8.0.
I would probably not recommend using wine-ge for Affinity then. It's more gaming oriented anyway.
-
ElementalWarrior got a reaction from Wanesty in Affinity Photo running on Linux with Bottles
1. RoResolveNamespace
I hacked in RoResolveNamespace calls specifically to get photo running: https://gitlab.winehq.org/ElementalWarrior/wine/-/commit/3de8daf601acd6d6f4dd95c7cba842050049e685
So any lines about RoResolveNamespace not followed by Found ... aren't resolving properly.
RoResolveNamespace docs: Determine the direct children, types, and sub-namespaces of the specified Windows Runtime namespace, from any programming language supported by the Windows Runtime.
Its responsible for looking up types, etc for the runtime. Which is used by C#, and WinRT/ C++/CX. So if I didn't hack in the path to the winmd files, it isn't going to resolve those types properly.
WinRT is window's effort to export headers/have an interface for any language to look up types, or build bindings to their libraries.
2. Fixme's
Fixme's are logging statements, written by wine devs as the stub out, or point out missing functionality. In effect, because the functionality is missing, our linux code will IN THEORY perform FASTER than windows, because it is doing less work.
If you have concerns that the logging itself is slowing your application performance, turn off application logging `WINEDEBUG=-all`
The fixme's are there to give other devs a heads up, that if something isn't working properly, and you see the fixme, that maybe if you implement this functionality, your application may work.
3. File dialog
In my experience, you only have folder selected if it has a background on the list entry in the left panel. So it kinda looks like you have no folder selected. Although experiences in that dialog may depend on the linux distribution you are using vs what I am using.
I had the best experience with it by opening the checkboxes FIRST, then ONLY selecting a folder by clicking the text, for the folder I wanted to browse/save to.
-
ElementalWarrior got a reaction from Wanesty in Affinity Photo running on Linux with Bottles
Closed means it wasn't merged. You want this link: https://gitlab.winehq.org/wine/wine/-/merge_requests/1444/diffs. This was merged.
-
ElementalWarrior got a reaction from Wanesty in Affinity Suite V2 on Linux [ Wine ]
Rebuilding for a different instruction set is trivial compared to changing your 3M line of code software to use an entirely different set of window, filesystem, keychain, network, etc libraries.
Drop the criticism of Serif on this thread.
They don't "simply" support Linux for the same reason not everyone here is debugging, patching and upstreaming wine code. It is time consuming, not straightforward, and requires expertise.
The more people rag on Linux support on serifs own forum, the more likely they will be to just lock every thread talking about Linux.
-
ElementalWarrior got a reaction from Snapseed in Affinity Suite V2 on Linux [ Wine ]
Look for logs in the terminal that have to do with writing to file and the term "fixme" or "stub". The function is probably not implemented in wine