BAR on Metal #936
Comments
|
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. |
|
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) |
|
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
<#936 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALMSVNGCWSNLK3632BVVLDXTPVPHANCNFSM6AAAAAA3DDH54U>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
A safe Vulkan stub that doesn't actually render anything and just checks capabilities (see e6ac54e) 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. |
|
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
<e6ac54e>)
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
<#936 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALMSVP3REIDELBE5B7CQELXTPYBJANCNFSM6AAAAAA3DDH54U>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
* “I’d just assume”
…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
> <e6ac54e>)
> 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
> <#936 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AALMSVP3REIDELBE5B7CQELXTPYBJANCNFSM6AAAAAA3DDH54U>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
|
|
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. |
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 |
|
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? |
|
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. |
|
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:
- Reddit posts:
https://www.reddit.com/r/beyondallreason/search/?q=mac&restrict_sr=1
(it's a low volume forum)
- Search for "mac" on BAR discord results 634 hits, and most are about
mac support (although this search ofc results some duplicates)
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
<#936 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALMSVPV2PP4GQGGT5MNNDLXT6WZVANCNFSM6AAAAAA3DDH54U>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
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. |
|
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. |
|
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. |
flathub/info.beyondallreason.bar#40
The main porting effort would be to make sure that all floating operations give the same results on arm and on x86. |
|
Your best bet is probably running BAR through an x86 on ARM emulator (box64, FEX, etc.) |
|
We need OpenGL 4.3 for BAR, so that's the first issue to resolve. |
|
You'll also need to use a library like https://github.com/DLTcollab/sse2neon, we use SSE extensions directly in-engine. |
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 |
|
Doesn't this help? It mentions OpenGL 4 https://github.com/openglonmetal/MGL |
|
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. |
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. |
By now it's at 4.6: https://rosenzweig.io/blog/conformant-gl46-on-the-m1.html |
|
Unless Asahi also has Rosseta then, no. |
|
You can try running the game with an emulator like box64/fex-emu |
|
box64 now supports 16k pages required for M1, and Mesa 24.1 with OpenGL 4.6 on M1 has been released |
|
@Karolson does that mean box64 now runs BAR? Could you confirm the performance / feature completness? |
|
I don't have any desktop ARM hardware, can't confirm anything |
|
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.
|
People always want throw money to specific things that concern them. |
|
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? |
|
|
|
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. |
|
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. |
|
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. |
I don't believe that is what is happening in this thread.
I believe this is what is happening. |
|
My 3c:
|
|
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. |
Assume 40 hours per week: Best case: 1-2 months work. $5,000 - $10,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. |
|
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? |
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 |
|
I use an old intel Macbook as a daily driver and I have access to an M1 Macbook. Can anyone point me to how to get started? Maybe I can start with getting builds to work on x86? |
|
The first thing I'd do is to grab some basic application running on OpenGL (something like https://github.com/JoeyDeVries/LearnOpenGL/tree/master/src/1.getting_started/2.1.hello_triangle) and make it run on Metal. |
|
Xplane have their OpenGL running on Zink over MoltenVK on Mac - so that approach has been proven to work. Starting with a super simple app and getting that working, as Ihog suggested, is a good starting point. |
Nice! Keep us posted about the progress and perhaps make a buymeacoffee.com or www.patreon.com account as you make progress ^_^ |
|
Thanks for the pointers guys! I was just fiddling a bit with MGL before I noticed someone here saying it would probably not work because it supports only OpenGL 4.6. MGL seems to be somehow dependant on Xcode and I'm trying to make its build work without that dependency. I have the macbooks, but I normally target linux so it is taking me some time to get up to speed there. BTW a couple of questions for @marcushutchings if I may About
Does it make sense to try to get MGL to support older OpenGL? Do you know what got deprecated that we need? Also, I don't know anything about zink. A cursory google lead me to an article [1] that indicates zink is part of mesa 3d drivers. Am I looking at the right thing here? If so, I don't think we can use it. It would force dependency on x11 emulation on macos [2] which in my experience is pretty dismal. For now I'm trying to get MGL to build and to use it with the some basic OpenGL as @lhog suggested. Let me know if there's a better way! [1] https://www.phoronix.com/review/zink-mesa-221 |
|
Zink is OpenGL on Vulkan driver, and as MacOS doesn't support Vulkan either it will have to use MoltenVK Vulkan on Metal too, and it has nothing to do with X11 But that doesn't matter anyway, Spring has an OpenGL 3.3 render path and MacOS's deprecated OpenGL driver should support that out of the box |
|
Do you have a link to the Zink repo?
…On Wed, Jul 24, 2024, 20:35 Karolson ***@***.***> wrote:
Zink is OpenGL on Vulkan driver, and as MacOS doesn't support Vulkan
either it will have to use MoltenVK Vulkan on Metal too, and it has nothing
to do with X11
But that doesn't matter anyway, Spring has an OpenGL 3.3 render path and
MacOS's deprecated OpenGL driver should support that out of the box
—
Reply to this email directly, view it on GitHub
<#936 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABUBGLJ4LWJH6UFOBI6DNI3ZN7XYRAVCNFSM6AAAAAA3DDH54WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBYGY3DONZVGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Zink is part of Mesa |
|
Zink is indeed a part of Mesa and translates GL into Vulkan. I don't know about its dependencies on Mac.
You'd need to do that yourself. |
|
The engine (and games) use OpenGL calls as old as from 2.x era as well as more modern 3.x and 4.x calls. |
|
|
|
I was able to get BAR building and running on a Macbook Pro M1 in Asahi. I had to port streflop to arm64 but it looks like it's passing the SpringMath::Init test. I'm trying to do more complete testing of streflop independently but I'm having trouble getting consistent results under Windows even before I add my changes. Anyways after porting streflop and vendoring https://github.com/DLTcollab/sse2neon it was pretty straight forward to get building under gcc. There were a few other small unsuprising changes. There's of course a few code paths doing nothing atm (fpucheck and cpuid AFAIK), but I'm able to start a skirmish with an AI. Took me a while to figure out how to bootstrap BAR on the platform and get it to launch. I'm not sure I can recreate it yet. Took some unknown combo of pr-downloader, bar-lobby, chobby, and manually messing with files to put together a working game directory. Hopefully that was just me learning the architecture and someone could recreate it easily. Graphics on lowest: ~105FPS @ 3024x1890 Here's the logs from a short run using chobby:test to launch: Stdout & stderr As you can see there's definitely more work to be done. Some graphical bugs on ultra make units invisible. Some menus seem to be crashing from nil references. The AI also looks like it's stuck although it will attack if I approach. Who knows maybe these issues are related to my botched game files. It's not BAR on Metal but I think it's reasonable to say that it will be much easier to target Linux Arm64 first especially with Asahi now being fully OpenGL 4.6 compliant. At the very least these results are encouraging enough to say that MGL might get this running on MacOS in a similar state. It's pretty hacked up right now but here's what it took. I will try to clean it up and see if it's something the maintainers would like to merge. Risk should be minimal to the existing clients since most of the changes will end up guarded by ifdefs for the target platform. |
I think as a test you can try to join into MP session as a spectator and watch entire game and see if you will start to get desync messages. Also you can try watch replays... |
|
I haven't gotten byar-chobby to work yet (again I think just messed up game files). The best I can do is chobby:test but when I try MP I can login but only see "Games are hidden, unsure why." under Battle List. It also doesn't show any replays. bar-lobby lists my replays but throws lots of errors trying to launch. Haven't tried to debug either yet. I'm hoping I can figure out a spring command to launch replays but I'm not there yet. Here's one of my replay files: replay.zip FP inconsistency could come from either streflop (which I've spent the most time verifying independently) and sse2neon (haven't done much testing yet). |
|
Nice work! |
The question is how well it works/performs. Seems like they've given up in favor of microVMs. |
|
Oh my gosh... Awesome advancement!
That is most probably due to the engine name / version mismatch with what BAR runs at. This can be worked/hacked around. |
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
The text was updated successfully, but these errors were encountered: