shiny/driver/mtldriver: add start of a Metal API-based driver

The OpenGL API has been deprecated on macOS as of version 10.14.¹
The replacement for OpenGL on macOS is the Metal API.² This change adds
the start of a Metal API-based shiny driver. It can be activated by
specifying the -tags=metal build tag on macOS 10.13+. For example:

	go run -tags='example metal'

The goal of this CL has been to create an MVP. As a result, the focus is
on simplicity and correctness. Performance optimizations can come later.

The Metal API is currently used only to present the final pixels to
the screen. All rendering is performed on the CPU via the image/draw
algorithms (see
Future work is to use mtl.Buffer, mtl.Texture, etc., to do more of
the rendering work on the GPU.

From what I've observed so far, the Metal API is looking to be a great
fit for implementing the screen.Screen interface. But we'll learn more
when it's used to a greater extent of its full performance potential.

GLFW v3.2.1 is used for window creation, receiving input events, etc.
Package is used for Metal API access.
Helper packages for Apple's Core Animation and AppKit APIs are copied.



Change-Id: I0e02d660b776820ca499bfe7d67e47a9866d530c
Run-TryBot: Dmitri Shuralyov <>
TryBot-Result: Gobot Gobot <>
Reviewed-by: Nigel Tao <>
15 files changed
tree: baf5e9eaf66eb288b3c4959160fd87d3f4fda0c1
  1. .gitattributes
  2. .gitignore
  9. apidiff/
  10. cmd/
  11. codereview.cfg
  12. ebnf/
  13. ebnflint/
  14. errors/
  15. fsnotify/
  16. go.mod
  17. go.sum
  18. inotify/
  19. io/
  20. mmap/
  21. rand/
  22. shiny/
  23. shootout/
  24. sumdb/
  25. utf8string/
  26. winfsnotify/


This subrepository holds experimental and deprecated (in the old directory) packages.

The idea for this subrepository originated as the pkg/exp directory of the main repository, but its presence there made it unavailable to users of the binary downloads of the Go installation. The subrepository has therefore been created to make it possible to go get these packages.

Warning: Packages here are experimental and unreliable. Some may one day be promoted to the main repository or other subrepository, or they may be modified arbitrarily or even disappear altogether.

In short, code in this subrepository is not subject to the Go 1 compatibility promise. (No subrepo is, but the promise is even more likely to be violated by go.exp than the others.)

Caveat emptor.