search

beyond-all-reason / spring

A powerful free cross-platform RTS game engine
https://beyond-all-reason.github.io/spring/
Other
177 stars 95 forks source link

BAR on Metal #936

Open svonava opened 11 months ago

svonava commented 11 months ago

Hi all,

I was wondering if the effort required to maintain a Metal port of BAR has ever been estimated cost-wise.

This could be a great way to bring more $$ into the project - I for one would gladly pay for a Apple-silicon compatible release of BAR.

Anybody knows?

Thanks, Daniel

lhog commented 11 months ago

I played around with Vulkan (which is compatible with Metal through MoltenVK). I added a very safe (as I thought) implementation to gather VK capabilities and unfortunately it crashes for many people with lesser drivers, so it had to be disabled. From that I concluded the native Vulkan way is not yet viable for our playerbase.

In the same time there's a promissing technology to emulate OpenGL on Vulkan, called Zink, as Vulkan backend is available through MoltenVK, this might be a way to go. It's not yet mature, but very promissing. Last time we checked it used to display most of the graphical stuff except a few items. I owe @Karolson , who is the main proponent of Zink, debugging of these remaining items.

lhog commented 11 months ago

That said modern Apple gear added another level of complexity stepping out from x64 architecture, so it's no longer just about missing OpenGL capabilities, but also the need to recompile for ARM (or use x64 emulation for this matter)

svonava commented 11 months ago

Can you elaborate on “From that I concluded the native Vulkan way is not yet viable for our playerbase.” - is it that only a subset of the Apple hardware is needed, or the latest OS, or the installation is hard (eg user has to compile?).

I expect that there is a decent fraction of players who are 30 year old nerds who code on a mac all day, then have to pull out a windows laptop from somewhere to play..

If the project is technically viable and it’s just a matter of somebody/small team sitting down for a month or two - a decently executed funding campaign would pay for it IMHO.

On Thu, 3 Aug 2023 at 20:35, lhog @.***> wrote:

That said modern Apple gear added another level of complexity stepping out from x64 architecture, so it's no longer just about missing OpenGL capabilities, but also the need to recompile for ARM (or use x64 emulation for this matter)

— Reply to this email directly, view it on GitHub https://github.com/beyond-all-reason/spring/issues/936#issuecomment-1664450281, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALMSVNGCWSNLK3632BVVLDXTPVPHANCNFSM6AAAAAA3DDH54U . You are receiving this because you authored the thread.Message ID: @.***>

sprunk commented 11 months ago

is it that only a subset of the Apple hardware is needed, or the latest OS, or the installation is hard (eg user has to compile?).

A safe Vulkan stub that doesn't actually render anything and just checks capabilities (see e6ac54ed8c76cc67d8fa4ecb923aec9cfa8bfc45) already crashes for many people with lesser drivers. An implementation that does more would run into even more issues. The problem is partially social since you can't control what hardware players have and what drivers they have installed.

svonava commented 11 months ago

I see - it just assume fully updated M1/M2 machines and then let everybody else catch up.

An update script that people can run to update the machine would help as well.

Is there some way we can estimate the effort needed?

On Thu, 3 Aug 2023 at 20:57, sprunk @.***> wrote:

is it that only a subset of the Apple hardware is needed, or the latest OS, or the installation is hard (eg user has to compile?).

An Vulkan stub that doesn't actually render anything and just checks capabilities (see e6ac54e https://github.com/beyond-all-reason/spring/commit/e6ac54ed8c76cc67d8fa4ecb923aec9cfa8bfc45) already crashes for many people with lesser drivers. An implementation that does more would run into even more issues. The problem is partially social since you can't control what hardware players have and what drivers they have installed.

— Reply to this email directly, view it on GitHub https://github.com/beyond-all-reason/spring/issues/936#issuecomment-1664477441, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALMSVP3REIDELBE5B7CQELXTPYBJANCNFSM6AAAAAA3DDH54U . You are receiving this because you authored the thread.Message ID: @.***>

svonava commented 11 months ago

On Thu, 3 Aug 2023 at 20:59, Daniel Svonava @.***> wrote:

I see - it just assume fully updated M1/M2 machines and then let everybody else catch up.

An update script that people can run to update the machine would help as well.

Is there some way we can estimate the effort needed?

On Thu, 3 Aug 2023 at 20:57, sprunk @.***> wrote:

is it that only a subset of the Apple hardware is needed, or the latest OS, or the installation is hard (eg user has to compile?).

An Vulkan stub that doesn't actually render anything and just checks capabilities (see e6ac54e https://github.com/beyond-all-reason/spring/commit/e6ac54ed8c76cc67d8fa4ecb923aec9cfa8bfc45) already crashes for many people with lesser drivers. An implementation that does more would run into even more issues. The problem is partially social since you can't control what hardware players have and what drivers they have installed.

— Reply to this email directly, view it on GitHub https://github.com/beyond-all-reason/spring/issues/936#issuecomment-1664477441, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALMSVP3REIDELBE5B7CQELXTPYBJANCNFSM6AAAAAA3DDH54U . You are receiving this because you authored the thread.Message ID: @.***>

lhog commented 11 months ago

My Vulkan attempt was unrelated to MacOS, I made it for the current Linux and Windows users. And there were related crashes for far too many people to ignore them.

As far as Mac, we don't have anything for it, even for x64 ones: no building pipelines, no libraries, only fragmental source code readiness. More than anything we need a motivated developer with Mac, who is not afraid of hitting roadblocks one after another. All previous attempts from contributors so far didn't succeed.

sprunk commented 11 months ago

Is there some way we can estimate the effort needed?

If you're eager to throw money at the problem you could just find and hire somebody competent, to look at things and produce such estimate

svonava commented 11 months ago

I'd be inclined to throw some money at the problem yes but probably a good idea to see if there is interest in the community first.

Is this something we could survey in-game?

p2004a commented 11 months ago

The results might be quite skewed because game currently doesn't support Mac, so likely not many Apple users in game at the moment.

Overall, there is interest:

We can't easily do polls in game, we can do them easily on forums like Discord, Reddit, not sure about website (it's webflow).

What exactly what you like to survey on top of the above question about Mac support?

From technical side, this post focuses on the graphical API, which is very problematic, because it's not exposed only to the engine, but is also available to Lua code of games. I would also like to point out that there is one more problem that is related to "sync": game simulation depends on the deterministic results of floating point operations across players using streflop library which doesn't have ARM support at the moment, and is potentially another hard problem to work around for supporting native ARM execution.

svonava commented 11 months ago

Ok so we know that there is broad demand, the other aspect is - would people be willing to pay and roughly how much. It seems that the expense on the project side is going to be a lump sum initially and then ongoing cost to maintain the compatibility, correct?

So the plan that seem reasonable:

  1. Perform a deeper technical check and write a 2-pager on everything that has to be done to add metal support.
  2. On top of that, estimate the initial and the ongoing cost.
  3. Set up a patreon (or similar) for BAR and make the mac version the main use-of-funds, with the "ongoing cost" portion being the target.
  4. Circulate that link to as many places as possible and see what we can get.
  5. Do a separate quick fundraise to cover the initial effort.

Basically, if (4) can get good traction, I'm happy to also pitch into (5).

Does that sound reasonable?

On Sun, Aug 6, 2023 at 5:02 PM Marek Rusinowski @.***> wrote:

The results might be quite skewed because game currently doesn't support Mac, so likely not many Apple users in game at the moment.

Overall, there is interest:

We can't easily do polls in game, we can do them easily on forums like Discord, Reddit, not sure about website (it's webflow).

What exactly what you like to survey on top of the above question about Mac support?

From technical side, this post focuses on the graphical API, which is very problematic, because it's not exposed only to the engine, but is also available to Lua code of games. I would also like to point out that there is one more problem that is related to "sync": game simulation depends on the deterministic results of floating point operations across players using streflop https://nicolas.brodu.net/en/programmation/streflop/index.html library which doesn't have ARM support at the moment, and is potentially another hard problem to work around for supporting native ARM execution.

— Reply to this email directly, view it on GitHub https://github.com/beyond-all-reason/spring/issues/936#issuecomment-1666888711, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALMSVPV2PP4GQGGT5MNNDLXT6WZVANCNFSM6AAAAAA3DDH54U . You are receiving this because you authored the thread.Message ID: @.***>

p2004a commented 11 months ago

On a high level this sounds like something that can work out. It has an assumption that we will be able to find a competent developer willing to do this work, including ongoing maintenance, which I find not obvious.

We will though need somebody motivated and with enough free time on their hands to drive and push forward execution of such a plan.

Things move forward in this project only when there is an individual willing to spend their free time on it.

marcushutchings commented 10 months ago

Maybe try to get the x64 version running over Zink and MoltenVK?

The API exposed to games is OpenGL and that isn't going to change, so in essence one needs to convert OpenGL into Metal.

ryansch commented 7 months ago

I have an M1 Max based mac. I've installed Asahi Linux and tried to run BAR. There's an ARM64 flatpak but it appears that the spring/recoil binaries are actually built for x86_64.

I fiddled with the build system and managed to get through cmake but the generated Makefiles are trying to pass x86 options to gcc.

Is this primarily a build tooling issue or a larger porting effort (streflop issue notwithstanding)?

Edit: Note that my usecase is unrelated to the graphics issues in macOS.

p2004a commented 7 months ago

There's an ARM64 flatpak but it appears that the spring/recoil binaries are actually built for x86_64.

https://github.com/flathub/info.beyondallreason.bar/issues/40

Is this primarily a build tooling issue or a larger porting effort (streflop issue notwithstanding)?

The main porting effort would be to make sure that all floating operations give the same results on arm and on x86.

Karolson commented 7 months ago

Your best bet is probably running BAR through an x86 on ARM emulator (box64, FEX, etc.) Though note than Asahi Linux supports OpenGL only up to 3.1 at the moment. No idea if that's enough to launch BAR

marcushutchings commented 7 months ago

We need OpenGL 4.3 for BAR, so that's the first issue to resolve.

marcushutchings commented 7 months ago

You'll also need to use a library like https://github.com/DLTcollab/sse2neon, we use SSE extensions directly in-engine.

Karolson commented 7 months ago

We need OpenGL 4.3 for BAR, so that's the first issue to resolve.

BAR works fine with OpenGL 3, but doesn't have healthbars. Dunno if 3.1 would suffice, as latest 3.x version is 3.3 Trying to compile the engine for ARM is indeed a problem, so just see if emulators work first

cellulosa commented 7 months ago

Doesn't this help? It mentions OpenGL 4 https://github.com/openglonmetal/MGL

marcushutchings commented 7 months ago

Unfortunately, that only supports OpenGL 4.6. We need capability that gets deprecated by the time of OpenGL 4.6. So it won't help here.

12345swordy commented 6 months ago

From technical side, this post focuses on the graphical API, which is very problematic, because it's not exposed only to the engine, but is also available to Lua code of games. I would also like to point out that there is one more problem that is related to "sync": game simulation depends on the deterministic results of floating point operations across players using streflop library which doesn't have ARM support at the moment, and is potentially another hard problem to work around for supporting native ARM execution.

From my quick reading regarding deterministic results from float values. They say that if you strictly follow the IEEE 754 compliant mode standard you shouldn't get any problems. https://gafferongames.com/post/floating_point_determinism/

Trass3r commented 2 months ago

note than Asahi Linux supports OpenGL only up to 3.1 at the moment.

By now it's at 4.6: https://rosenzweig.io/blog/conformant-gl46-on-the-m1.html

marcushutchings commented 1 month ago

Unless Asahi also has Rosseta then, no.

Karolson commented 1 month ago

You can try running the game with an emulator like box64/fex-emu

Karolson commented 1 month ago

box64 now supports 16k pages required for M1, and Mesa 24.1 with OpenGL 4.6 on M1 has been released

svonava commented 1 month ago

@Karolson does that mean box64 now runs BAR? Could you confirm the performance / feature completness?

Karolson commented 1 month ago

I don't have any desktop ARM hardware, can't confirm anything

alanpaone commented 1 month ago

I gave it a shot in Asahi with box64. Doesn't quite work! I'm not sure if this means that __gcov_dump, __gcov_flush, etc are missing/broken somehow, or if R_X86_64_JUMP_SLOT is affecting all of them. I'm not familiar with box64 tbh, and I have no idea if this is the only roadblock or just the first one, but they seem to be actively progressing on M1, I'll try it again on the next update.

Warning: Weak Symbol __gcov_dump not found, cannot apply R_X86_64_JUMP_SLOT @0x10a6aada0 (0xa128af6) Warning: Weak Symbol __gcov_flush not found, cannot apply R_X86_64_JUMP_SLOT @0x10a6aada8 (0xa128b06) Warning: Weak Symbol ZSTD_trace_decompress_begin not found, cannot apply R_X86_64_JUMP_SLOT @0x10a6aae8 (0xa128cc6) Warning: Weak Symbol ZSTD_trace_decompress_end not found, cannot apply R_X86_64_JUMP_SLOT @0x10a6aae90 (0xa128cd6) Warning: Weak Symbol _ZTHN2v88internal12trap_handler21g_thread_in_wasm_codeE not found, cannot apply R_X86_64_JUMP_SLOT @0x10a6ab518 (0xa1299e6) Warning: Weak Symbol _ZTHN2v88internal19RwxMemoryWriteScope31code_space_write_nesting_level_E not found, cannot apply R_X86_64_JUMP_SLOT @0x10a6ab520 (0xa1299f6) Warning: Weak Symbol OPENSSL_memory_alloc not found, cannot apply R_X86_64_JUMP_SLOT @0x10a6ab770 (0xa129e96) Warning: Weak Symbol OPENSSL_memory_free not found, cannot apply R_X86_64_JUMP_SLOT @0x10a6ab778 (0xa129ea6) Warning: Weak Symbol sdallocx not found, cannot apply R_X86_64_JUMP_SLOT @0x10a6ab780 (0xa129eb6) Warning: Weak Symbol OPENSSL_memory_get_size not found, cannot apply R_X86_64_JUMP_SLOT @0x10a6ab788 (0xa129ec6) 3456|SIGILL @0xffff22ffde08 (???(0xffff22ffde08)) (x64pc=0x105ccd87f//tmp/.mount_BeyondYTg5uh/beyond-all-reason:"/tmp/.mount_BeyondYTg5uh/beyond-all-reason + 0x5ccd87f", rsp=0xffff13fffd30, stack=0xffff13800000:0xffff14000000 own=0xffff13800000 fp=0xffff13fffd70), for accessing 0xffff22ffde08 (code=1/prot=7), db=0xffff221ab990(0xffff22ffdda0:0xffff22ffde48/0x105ccd87f:0x105ccd880//tmp/.mount_BeyondYTg5uh/beyond-all-reason + 0x5ccd87f:clean, hash:cc/cc) handler=(nil) RAX:0x0000000000000016 RCX:0x0000000000000000 RDX:0x0000ffff133ff660 RBX:0x0000000000001000 RSP:0x0000ffff13fffd30 RBP:0x0000ffff13fffd70 RSI:0x0000ffff28810f60 RDI:0x0000ffff13fffd44 R8:0x0000000000000000 R9:0x0000000000000001 R10:0x0000000101b7096c R11:0x0000000000000010 R12:0x0000000000000003 R13:0x0000000000000000 R14:0x0000000000000003 R15:0x00003e1800201000 ES:0x002b CS:0x0033 SS:0x002b DS:0x002b FS:0x0043 GS:0x0053 RSP-0x20:0x0000000000000000 RSP-0x18:0x0000000000000000 RSP-0x10:0x0000ffff13fffd70 RSP-0x08:0x0000000105ccd87f RSP+0x00:0x0000000000000000 RSP+0x08:0xffffffff00000003 RSP+0x10:0x0000001600000000 RSP+0x18:0x000000010a7830b0 opcode=90 11 41 64 00 00 00 00 (CC 0F 0B CC CC) Illegal instruction (core dumped)

loligans commented 1 month ago

I gave it a shot in Asahi with box64. Doesn't quite work!

Can you provide instructions on what you did to launch the game?

12345swordy commented 2 weeks ago

If we talking about throwing money at the problem, how much money are we talking about here?

svonava commented 2 weeks ago

@12345swordy: How much money would it take to make somebody who knows what they are doing actually take a serious stab at this?

If we have some idea about the budget, then I could take it up with whoever cares in the BAR organization or suggest setting it up as an independent patreon gig and contributing :)

On Sun, Jun 16, 2024 at 9:32 AM 12345swordy @.***> wrote:

If we talking about throwing money at the problem, how much money are we talking about here?

— Reply to this email directly, view it on GitHub https://github.com/beyond-all-reason/spring/issues/936#issuecomment-2171763878, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALMSVKJVLHD4BZIPNS6YRLZHW42RAVCNFSM6AAAAAA3DDH54WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZRG43DGOBXHA . You are receiving this because you authored the thread.Message ID: @.***>

TheSilverHornet commented 2 weeks ago

The last thing BAR needs is people randomly throwing money at certain bits of development, it's one of the fastest ways to kill everything. Donate for server costs if you want to support the game.

6AKU66 commented 2 weeks ago

The last thing BAR needs is people randomly throwing money at certain bits of development, it's one of the fastest ways to kill everything. Donate for server costs if you want to support the game.

People always want throw money to specific things that concern them.

svonava commented 2 weeks ago

I'd prefer to support the game in a way that allows me to play it on my default computer @TheSilverHornet - how exactly is that going to "kill" it?

sprunk commented 2 weeks ago

image

TheSilverHornet commented 1 week ago

It all builds on less interesting/glamourous/'demanded' work in the background. If you start throwing money at some devs and not others, the rest are likely to resent it and rapidly stop the unappreciated work, others try to fight over the lucrative coding, and still others give up entirely at the state of the whole mess. Poorly thought out monetisation is a very good way to kill a voluntary project.

p2004a commented 1 week ago

I believe what you fear @TheSilverHornet is effectively this https://ziglang.org/news/bounties-damage-open-source-projects/, which is indeed problematic.

But, explicitly hiring somebody to do the work, is different. It's not like BAR, even officially, isn't doing it already in the form of buying proprietary assets.

TheSilverHornet commented 1 week ago

Sometimes it can work in modular fashion, but it very much needs thought to avoid turning into a bounty type system via the back door. There is a large difference between buying external prerolled assets off the shelf, and 'bribing' an existing developer to do something specific. Safest route would probably be paying someone fully external to do it, if possible, but they'd probably ask so much it would be prohibitive.

p2004a commented 1 week ago

and 'bribing' an existing developer to do something specific

I don't believe that is what is happening in this thread.

paying someone fully external to do it

I believe this is what is happening.

sprunk commented 1 week ago

My 3c:

alanpaone commented 1 week ago

Its a very classic Mac Guy attitude to try and just buy our way out of our own decisions. If you really want to play on your mac, parallels will mostly work, and judging by how much better parallels 19 is than 18, it will probably be better with august's update to 20. If you have coding knowledge, it is probably less ongoing support work to help improve box64. If you don't , and just want to throw money at this problem, buy a steam deck, and you'll get full support and be able to play right away. there are not enough of us to pay the salary of a mac gaming developer.

12345swordy commented 1 week ago

@12345swordy: How much money would it take to make somebody who knows what they are doing actually take a serious stab at this?

Assume 40 hours per week:

Best case: 1-2 months work. $5,000 - $10,000 dollars Worst case: 3-4 months work. $15,000 - $20,000 dollars

Porting to arm architecture alone is very hard, given the engine requirement to have deterministic physics which in turn requires deterministic float point math, which itself very hard even for x86_64 hardware systems alone. You don't need the engine to run on metal you just need it to run on ARM architecture. (Unless there are plans to implement vulkan, just run linux/windows on your arm machine)

nimbusgo commented 1 week ago

I noticed that fedora asahi linux has support for opengl 4.6 for a few months now on apple silicon.

My initial attempts at running BAR on an m1 with fedora asahi were unsuccessful because of the different architectures.

I'm wondering if using box64 on fedora asahi might work. Will give that a try. Anyone try anything like this yet?

alanpaone commented 1 week ago

Anyone try anything like this yet

yes, it doesn't run, but that was last month, given the pace of development it probably gets a different error now

loligans commented 1 day ago

Anyone try anything like this yet

yes, it doesn't run, but that was last month, given the pace of development it probably gets a different error now

I'll try again when I get my friends mac and post steps for others