Virgil 3D renderer on macOS

Virgil 3D renderer on macOS

[小田喜陽彦]

Hi,

I would like to introduce my Virgil 3D renderer port to macOS.

Some patches which are made in the process are useful even without
Virgil 3D renderer, and already submitted to upstreams:
- [PATCH] ui/cocoa: Support unique keys of JIS keyboards
- [PATCH] ui/cocoa: Remove the uses of full screen APIs
- [PATCH] ui/cocoa: Do not copy members of pixman image
- [PATCH] ui/cocoa: Interpret left button down as is when command is pressed
- Support ANGLE on macOS by akihikodaki · Pull Request #239 · anholt/libepoxy
  https://github.com/anholt/libepoxy/pull/239

I will send other patches when I confirm they do not cause harm on
Linux hosts, or changes they depend on get merged.

The complete source code is available on GitHub:
https://github.com/akihikodaki/libepoxy/tree/macos
https://github.com/akihikodaki/qemu/tree/macos
https://github.com/akihikodaki/virglrenderer/tree/macos

The "cocoa" display of QEMU will provide OpenGL support to the guest
on macOS hosts. "NSOpenGLContext" (which wraps "CGL") will be the
backend for core profile. ANGLE (which also wraps CGL and provides
compatibility improvements) will be the backend for ES profile. It is
possible to build without ANGLE, but such a build will lose ES profile
compatibility.

Videos captured on M1 MacBook Air are available on YouTube:
https://youtu.be/ezvQPREjN1s (The WebGL Aquarium on the host, for comparison)
https://youtu.be/iOG9Dbn8VoE (QEMU with OpenGL Core)
https://youtu.be/k0bVlVQU2JQ (QEMU with OpenGL ES)

glmark2 gives 577 scores for gl=es and 151 scores for gl=off. The FPS
of the WebGL aquarium with identical configurations was consistent
with the display on the host (60 FPS), 15 FPS with gl=es, 8 FPS with
gl=off.

I have not ran a formal conformance tests, but gl=core (which uses
NSOpenGLContext) had a few problems:
- glmark2 fails with the following output:
> vrend_compile_shader: context error reported 6 "glmark2" Illegal shader 0
> shader failed to compile
> ERROR: 0:2: '' :  extension 'GL_ARB_fragment_coord_conventions' is not supported

- Mozilla Firefox opening "about:support" fails with the following
output on the host (This one should be easy to fix but I rather not
because I also have gl=es.):
> No provider of glTexStorage2DMultisample found.  Requires one of:
>     Desktop OpenGL 4.3
>
>     GL_ARB_texture_storage_multisample
>     OpenGL ES 3.1

In contrast, gl=es, backed with ANGLE, runs properly as far as I have seen.

My motivation is to make Linux desktop usable on M1. Patches to add
Hypervisor framework support on Aarch64 are already submitted ("hvf:
Implement Apple Silicon Support") and they are indeed useful for
various workloads and I also used them to port Virgil, but I also
needed graphics acceleration for my purpose. Another attempt to get
Linux work on M1 is Asahi Linux, which aims to run Linux bare-metal.
Of course, this needs porting graphic stacks to M1 and is likely to
take time. I am satisfied with my port for the purpose although there
may be rooms for performance or compatibility improvements.

There is nothing preventing that if anyone would like to use Virgil on
Intel Macs. Also, some patches may benefit other OpenGL ES
configurations and displays.

Thanks,

Re: Virgil 3D renderer on macOS

[Akihiko Odaki]

2021年2月13日(土) 12:20 Programmingkid <programmingkidx@gmail.com>:
> I am also an M1 Mac owner. I don't know very much about graphics cards but I would be happy to help if you need a tester.

I don't need a tester now because I have not fixed even likely-obvious
performance and compatibility problems which I can find out easily if
I debug it or I run some serious performance/conformance test
programs. But thank you for your proposal.

>
> I was doing a lot of thinking about implementing a 3D video card in QEMU. One option was to port PCem's Voodoo2 card to QEMU. Another option was to implement the ATI Rage 128 card. Drivers wouldn't probably be a problem since they already exist for Mac OS and Windows. One issue users might encounter is game support. Both these cards are older and probably are missing features that newer games need. Then there's the problem of proprietary firmware files these cards probably use. So I was wondering what your opinion on this issue. Should we focus on emulating a real video card or focus on making Virgil 3D compatible with more operating systems?

The latter. I have no idea how complex such ancient accelerators are,
but probably fewer people than those interested in Virgil are
interested in them. The difference is quite important; you can reuse
code written for different purposes if you hack an existing program,
Virgil. In the case of my port, I made Virgil 3D renderer run on a
macOS/CGL host where it was mainly written for Linux/DRM hosts. You
can do the same, and port Virgil 3D drivers which already exist to
other platforms although it should be much harder than my port, which
is essentially fixes of some minor problems of programs written with
standard APIs (OpenGL).

Re: Virgil 3D renderer on macOS

[Programmingkid]

> On Feb 12, 2021, at 4:25 AM, qemu-devel-request@nongnu.org wrote:
> 
> Message: 2
> Date: Fri, 12 Feb 2021 12:52:21 +0900
> From: 小田喜陽彦 <akihiko.odaki@gmail.com>
> To: qemu-devel@nongnu.org, virglrenderer-devel@lists.freedesktop.org
> Subject: Virgil 3D renderer on macOS
> Message-ID:
> 	<CAMVc7JXQ_W+wDb9fUrGXmnO9Udaugbg=X-9PkpKNY13Xe7YxiQ@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
> 
> Hi,
> 
> I would like to introduce my Virgil 3D renderer port to macOS.
> 
> Some patches which are made in the process are useful even without
> Virgil 3D renderer, and already submitted to upstreams:
> - [PATCH] ui/cocoa: Support unique keys of JIS keyboards
> - [PATCH] ui/cocoa: Remove the uses of full screen APIs
> - [PATCH] ui/cocoa: Do not copy members of pixman image
> - [PATCH] ui/cocoa: Interpret left button down as is when command is pressed
> - Support ANGLE on macOS by akihikodaki · Pull Request #239 · anholt/libepoxy
>  https://github.com/anholt/libepoxy/pull/239
> 
> I will send other patches when I confirm they do not cause harm on
> Linux hosts, or changes they depend on get merged.
> 
> The complete source code is available on GitHub:
> https://github.com/akihikodaki/libepoxy/tree/macos
> https://github.com/akihikodaki/qemu/tree/macos
> https://github.com/akihikodaki/virglrenderer/tree/macos
> 
> The "cocoa" display of QEMU will provide OpenGL support to the guest
> on macOS hosts. "NSOpenGLContext" (which wraps "CGL") will be the
> backend for core profile. ANGLE (which also wraps CGL and provides
> compatibility improvements) will be the backend for ES profile. It is
> possible to build without ANGLE, but such a build will lose ES profile
> compatibility.
> 
> Videos captured on M1 MacBook Air are available on YouTube:
> https://youtu.be/ezvQPREjN1s (The WebGL Aquarium on the host, for comparison)
> https://youtu.be/iOG9Dbn8VoE (QEMU with OpenGL Core)
> https://youtu.be/k0bVlVQU2JQ (QEMU with OpenGL ES)
> 
> glmark2 gives 577 scores for gl=es and 151 scores for gl=off. The FPS
> of the WebGL aquarium with identical configurations was consistent
> with the display on the host (60 FPS), 15 FPS with gl=es, 8 FPS with
> gl=off.
> 
> I have not ran a formal conformance tests, but gl=core (which uses
> NSOpenGLContext) had a few problems:
> - glmark2 fails with the following output:
>> vrend_compile_shader: context error reported 6 "glmark2" Illegal shader 0
>> shader failed to compile
>> ERROR: 0:2: '' :  extension 'GL_ARB_fragment_coord_conventions' is not supported
> 
> - Mozilla Firefox opening "about:support" fails with the following
> output on the host (This one should be easy to fix but I rather not
> because I also have gl=es.):
>> No provider of glTexStorage2DMultisample found.  Requires one of:
>>    Desktop OpenGL 4.3
>> 
>>    GL_ARB_texture_storage_multisample
>>    OpenGL ES 3.1
> 
> In contrast, gl=es, backed with ANGLE, runs properly as far as I have seen.
> 
> My motivation is to make Linux desktop usable on M1. Patches to add
> Hypervisor framework support on Aarch64 are already submitted ("hvf:
> Implement Apple Silicon Support") and they are indeed useful for
> various workloads and I also used them to port Virgil, but I also
> needed graphics acceleration for my purpose. Another attempt to get
> Linux work on M1 is Asahi Linux, which aims to run Linux bare-metal.
> Of course, this needs porting graphic stacks to M1 and is likely to
> take time. I am satisfied with my port for the purpose although there
> may be rooms for performance or compatibility improvements.
> 
> There is nothing preventing that if anyone would like to use Virgil on
> Intel Macs. Also, some patches may benefit other OpenGL ES
> configurations and displays.
> 
> Thanks,

I am also an M1 Mac owner. I don't know very much about graphics cards but I would be happy to help if you need a tester. 

I was doing a lot of thinking about implementing a 3D video card in QEMU. One option was to port PCem's Voodoo2 card to QEMU. Another option was to implement the ATI Rage 128 card. Drivers wouldn't probably be a problem since they already exist for Mac OS and Windows. One issue users might encounter is game support. Both these cards are older and probably are missing features that newer games need. Then there's the problem of proprietary firmware files these cards probably use. So I was wondering what your opinion on this issue. Should we focus on emulating a real video card or focus on making Virgil 3D compatible with more operating systems?