Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Apple Macbook/Mini ARM and ALLEGRO

This thread is locked; no one can reply to it. rss feed Print
Apple Macbook/Mini ARM and ALLEGRO
_jagged
Member #17,124
September 2019

Hey everyone, I'm going to buy an 'm1' mini as a toy. I think it's a very exciting move by Apple and I firmly believe ARM will take over personal computing (it already has, but I mean the type with a keyboard). I've learnt some Swift over the last few weeks, and it's alright. But... Any chance that one of you champs that work on ALLEGRO are porting it for the new macs?

I assume gcc will be available, as macs are UNIX, Right?

Peter Hull
Member #1,136
March 2001

I suspect it won't work straight away but it ought to be fixable. On the plus side, Allegro already works on iOS (correct me if I'm wrong) so there's nothing Intel specific in there. I worry about OpenGL; currently we rely on it and it's deprecated in the MacOS SDK. Do the new Macs have OpenGL? Otherwise (and maybe we should do this anyway?) we need a back-end for Metal.

[edit] Andrew Cunningham says that OpenGL is still available in Big Sur, I assume that means for both Intel and A.S. macs.

amarillion
Member #940
January 2001
avatar

It would be hard for apple to completely remove OpenGL, no? Things like WebGL depend on it too.

How much work would it be for us to create a Metal back-end for Allegro? Has any work been done in this direction?

Peter Hull
Member #1,136
March 2001

Has any work been done in this direction?

Only on my HD as far as I know.
{"name":"612709","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/0\/c061c8031fd4b463cffe71549ab6c846.png","w":264,"h":62,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/0\/c061c8031fd4b463cffe71549ab6c846"}612709
Seriously though I don't really understand the Metal API and I haven't spent much time on it.
Pete

dthompson
Member #5,749
April 2005
avatar

It would be hard for apple to completely remove OpenGL, no?

Yes indeed, and I reckon they won't for quite a while.

In the interests of keeping things simple, I wonder whether Vulkan + MoltenVK would be a better option than adding a Metal backend - much less cross-platform work to do in that case, and we get a performance bonus for Windows/Linux too.

______________________________________________________
Website. It was freakdesign.bafsoft.net.
This isn't a game!

Thomas Harte
Member #33
April 2000
avatar

I know nothing about modern Allegro or its implementation, and rarely even lurk here, but by coincidence I lurked today and I brushed up on Metal earlier in the year so if there's anything I can answer on that then ask away. But it's pretty simple stuff:

Buffers act as intermediaries between CPU and GPU. On the Mac you probably want them to be managed rather than shared, which means formally declaring modified ranges before you can use them — if there's a discrete GPU then that'll trigger a copy across the bus. If it's an integrated GPU I think you get the same behaviour as ordinary shared buffers.

The shading language is C++11 with some type differences, and the most regular way of declaring what's in a buffer is via plain-old-data structs. These are guaranteed to use the same alignment and padding as if compiled for the CPU so Metal-specific programs often just use the same struct declaration for both the CPU and GPU code.

There's really only two kinds of shader to worry about — the regular sort that pair with geometry, interpolate some fields (from another struct) across their surface and call your shader per pixel, and compute shaders which amount to a parallel for loop. I guess Allegro will be interested only in the former.

Apple provides MTKView which can bind Metal content to the display. It's extremely straightforward.

You'll generally bind specific drawing steps into a pipeline and then just issue those. There's no implicit global state and you can issue them from any old thread. They're then issued in a serial fashion to the GPU.

In my project, which is emulation related and spends most of its GPU code on NTSC or PAL encoding and decoding, I had to add 1,802 lines to support Metal. That contrasts with 2,310 lines dedicated to OpenGL. It took me a bit more than a month to figure out, all in, primarily using Apple's documentation and forums, and a little of <a href="https://metalbyexample.com>metalbyexample.com</a>. The second example — how to get a triangle on screen — was the main point of interest, albeit that I deviated from it substantially even as I was getting started because it predates MetalKit and MTKView.

The Metal version does run noticeably better than the OpenGL did, but that's largely because I primarily develop in Xcode so the fact that Apple doesn't supply a debugger or profiler for OpenGL just means that the process is all the more painful and therefore I've experimented less. Apple's vintage version of OpenGL also obfuscates some of the more modern functionality — especially around shared buffers. If you've been writing your OpenGL so far with decent tooling and/or on modern platforms then you won't see those issues quite so substantially. Metal does allow you to be a lot more specific about which buffers are ephemeral though (i.e. whether they really need loading to and from the GPU cache), so that's nice.

My understanding of Apple's current position towards OpenGL is that it has survived onto the M1 Macs but Apple doesn't intend to advance it beyond the c.2011 vintage it seems to have become stuck at. You can assume it'll get scare prompts in the not-too-distant future — compiler warnings are already generated for any use of NSOpenGLView.

Honestly, if you can make MoltenVK work then I don't have a good reason to advocate Metal.

Arthur Kalliokoski
Second in Command
February 2005
avatar

Wow! Thomas Harte! This is your first post in what, 8 years? Do you lurk time to time? Glad to hear from you!

They all watch too much MSNBC... they get ideas.

Thomas Harte
Member #33
April 2000
avatar

Yes, I lurk from time to time, though usually I've absolutely nothing to contribute.

It just so happens that the main thing I do hobbyist programming on nowadays is an emulator with a complicated-for-its-genre GPU back-end* and I added Metal as an alternative to OpenGL in September this year. So I felt like maybe I could provide something here.

* it's emulating a CRT in the manner that they actually work — not magicing whole frames about and then smudging them up as a "CRT emulation" — so it's a lot of streaming in small chunks with plenty of intermediate processing (e.g. to decode NTSC or PAL). In Metal it's actually a combination of compute and regular fill shaders.

Metal has been a big win, but I expect that any other modern graphics API would do just as well. The main issues with OpenGL are its olden times thread semantics, and having either to build shaders at runtime or to start introducing and maintaining additional steps in your build chain e.g. just to get an equivalent of #include.

Peter Hull
Member #1,136
March 2001

I would like to see that emulator, is it available anywhere? And, will it emulate "dot crawl" which I remember fondly from the '80s :D

Thomas Harte
Member #33
April 2000
avatar

Yes, dot crawl appears on appropriate systems. It's actually those few that are in-phase with the colour clock that tend to be more problematic

To try to keep things vaguely on topic:

  • the actual Metal shaders are here; and

  • everything to do with pipelines, etc, is here.

The project is a perpetual work in progress so all I can see are the gross uglinesses, but that's what I came up with within a month or so of starting on my first Metal code. It's an improvement both algorithmically and in terms of neatness on the older OpenGL code, so that's something. Naturally I intend to backport lessons learnt. Somewhere amongst doing all the other things I intend to do.

Otherwise, Mac binaries live on the GitHub and if your distribution uses it then the easiest way to grab the Qt/Linux build is via its Snap. Though I've never quite established whether that's correctly packaged to output audio, and it's definitely worse than the Mac for latency. Or you can build that or the Linux/SDL target directly from source.

Fair warning: the SDL build has no UI. But the whole project is supposed to be about hiding complexity. Don't think like a classic emulator of make a whole bunch of guesses as to how to configure your emulated machine, go online and search for how to launch software on that machine — the emulator will seek to figure out both for you.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Thomas Harte
Member #33
April 2000
avatar

I have never tried Allegro 5, but only on account of not having written a game or anything much like one in at least 12 years, and my final two being for the then-nascent iPhone.

I've also tended in a different philosophical direction re: platform integration — it's the platform-specific stuff that's actually running the show, and the cross-platform stuff is the library it calls into.

So e.g. in the emulator above I've no cross-platform way to create a window, or propagate a must-quit message, or access whatever that platform provides for pull-down menus, or any other attempt to extract norms from different systems.

In summary: different objectives lead to different outcomes. I like to invest more time on the per-platform stuff in order to optimise for platform fit, and many others would think that's a poor allocation of time.

Go to: