Commit 2a3c46a829b9 added support for supportsFamily, an API new to macOS 10.15. It used an @available check to avoid trying to call it on macOS 10.13 and 10.14, but despite not running, it still creates a warning like: mtl.m:44:33: warning: instance method '-supportsFamily:' not found (return type defaults to 'id') [-Wobjc-method-access] On those old macOS versions. Use an #ifdef directive until I find a better to handle this, or drop this complexity by raising the minimum supported macOS version. Tested on macOS 10.13.6 and 13.0.1.
The upstream Metal API has deprecated this part of its API. Explicitly ignore a compilation warning about the deprecation.
This is a newer API to check whether a GPU device supports the feature set of a specific GPU family. It's available on macOS since 10.15.
The Objective-C BOOL type is defined as a signed char on on Intel-based Mac computers, but on Apple silicon, it is defined as as a native bool.¹ This makes it hard to write portable Cgo code across darwin/amd64 and darwin/arm64 ports. So, stop relying on it, and use the bool type from <stdbool.h> instead. ¹ https://developer.apple.com/documentation/apple_silicon/addressing_architectural_differences_in_your_macos_code#3616879
This wasn't needed in the past, but by now it is neccessary for MTLCreateSystemDefaultDevice to work.¹ ¹ https://developer.apple.com/documentation/metal/1433401-mtlcreatesystemdefaultdevice
This came up during code review in https://golang.org/cl/171025. Backport the improvements to the upstream copies of those packages. These are better names for these Go packages. The previous names were an attempt at leveraging the familiarity with Apple's API prefixes (i.e., AppKit identifiers tend to have "NS" prefix, Core Animation API identifiers tend to have "CA" prefixes). However, that isn't as useful here because those prefixes are not very consistent or recognizable when turned into Go package names. Create a helper to convert from bool to C.BOOL and use it instead of more verbose switches. Other people seem to like this style better.
It has become unnecessary after the switch from GLFW v3.2 to v3.3, because Window.GetCocoaWindow now returns unsafe.Unsafe directly.
It has been released recently. Start using it. Updates https://github.com/go-gl/glfw/pull/256
These were needed for a Metal API-based driver for x/exp/shiny.
Get the ContentView right away, instead of going through cocoaWindow. The ContentView is all that's needed from cocoaWindow at this time. This is simpler and reads better.
Decide on and document the minimum supported macOS version as 10.13. macOS 10.13 runs on the same hardware as 10.12, so anyone with 10.12 can update to 10.13 and use this package. I don't have access to older versions of macOS to test with, nor do I have the bandwidth to support them.
The goal of this change is to make it possible to use package mtl to render to a window at interactive framerates (e.g., at 60 FPS, assuming a 60 Hz display with vsync on). It adds the minimal API that is needed. A new movingtriangle example is added as a demonstration of this functionality. It opens a window and renders a triangle that follows the mouse cursor. Much of the needed API comes from Core Animation, AppKit frameworks, rather than Metal. Avoid adding that to mtl package; instead create separate packages. For now, they are hidden in internal to avoid committing to a public API and import path. After gaining more confidence in the approach, they can be factored out and made public.
Also clean up and simplify some of the other code.
It might be desirable for some users to be able to run a command that outputs information about Metal devices without having to write code. This is similar to utilities such as glfwinfo, glewinfo, etc.
This way, executing it with -help flag prints usage, rather than running unconditionally. Remove an unhelpful blank line.
Update Example_listDevices sample output to match output of a 2015 MBP on macOS Mojave.
The Go API tries to follow the Swift Metal API as closely as possible. Add tests and examples.