Adding more info to TGSI when translating from NIR

[Gert Wollny]

Dear all, 

With virgl we are interested in exploiting performance improvements on
e.g. ARM hardware by using fp16 when the guest application uses it. 
virgl uses TSGI (as text string) passed to the host to communicate
shaders from the guest to the host, and with TGSI no such information
is available. 

With NTT is place it should now be possible to add this information, so
I was wondering whether anybody (especially you Emma), would have any
objections to go forward in that direction. 

The reason we don't want to change to another transport format now is,
that with Zink and Venus getting better, the lifetime of VirGL is
probably limited and it is not worth the effort to invest in such
profound changes that would require the re-write the whole shader
conversion code in virglrenderer.

The approach that I would take for this is most likely by introducing
another tgsi_file_type `TGSI_FILE_TEMP16` (so far we have 15 types, so
that the four bits for the file type can hold one more value), that is
then attached to the registers using 16 bit. I'd have to add another
pass to RA to handle the extra type of temporaries, and some NTT option
that would enable this feature only when the driver requests it (In the
end it only makes sense when virgl is running on a GLES host).

Any opinions or comments? 

Best, 
Gert 

Enable OpenGL software rendering on macOS

[Martin Pernollet]

TLDR : I failed using Mesa software rendering on macOS. I am looking for advice 
to invoke mesa's libGL.dylib without relying on macOS's system GL.

Hi everyone,

I am building (java) software involving Mesa for CPU rendering. I use CPU 
rendering as fallback when JOGL (OpenGL binding for Java) fail to use the GPU 
natively. This is sometime the case for old Linux distributions, this will 
certainly be frequent on macOS in the future due to Apple's OpenGL deprecation.

Mesa CPU rendering is working great on Ubuntu (by enabling 
LIBGL_ALWAYS_SOFTWARE=true) and Windows (by simply loading Mesa's DLL instead 
of system DLL, no need to ask for software mode).

I however thrive to useMesa's software rendering on macOSfor the following 
reasons

- Spying dynamic library load sequence shows that whenever Mesa's libGL.dylib 
is loaded, Apple Metal and libGL.dylib are loaded before, even when using DYLD 
tricks to ensure Mesa get loaded before any other library (except the Java VM) 
[1] Someone says that Mesa's macOS implementation relies on system GL [4]. I 
noticed that when enabling LIBGL_ALWAYS_SOFTWARE=true, this activates Apple 
software rendering but not Mesa's software rendering [5].I wonder how I could 
avoid this and use a pure Mesa's OpenGL implementation in this situation.
- When getting out of the java World

- Running a pre-built glxgear/glxinfo installed through MacPorts only allows 
using Apple's libGL.dylib but not Mesa's libGL.dylib [2].
- Building glxinfo myself by linking explicitely to Mesa's GL + X11 lead to an 
X11 error that I am not able to depict [3].

This has been discussed already on Khronos community [1] but I have no clue how 
to go further. I hope some experts here can help me solve this!

Thanks in advance,

Martin

[1] 
https://community.khronos.org/t/failing-to-load-mesa3d-on-macos-instead-of-macos-provided-opengl-library/108408
[2] 
https://community.khronos.org/t/failing-to-load-mesa3d-on-macos-instead-of-macos-provided-opengl-library/108408/14
[3] 
https://community.khronos.org/t/failing-to-load-mesa3d-on-macos-instead-of-macos-provided-opengl-library/108408/19
[4] 
https://community.khronos.org/t/how-to-use-opengl-on-zink-mesa-moltenvk-and-macos/108160/18
[5] 
https://community.khronos.org/t/failing-to-load-mesa3d-on-macos-instead-of-macos-provided-opengl-library/108408/17

Re: Enable OpenGL software rendering on macOS

[Jose Fonseca]

The difficulty with OpenGL on macOS is that all driver interfaces are both 
undocumented and deprecated.


If you want to override the system OpenGL, you can use apitrace code as 
reference.  There are two approaches:

  1.  DYLD_FRAMEWORK_PATH  
https://github.com/apitrace/apitrace/blob/master/cli/cli_trace.cpp
  2.  DYLD_INSERT_LIBRARIES 
https://github.com/apitrace/apitrace/tree/dyld-interpose (experimental branch)


AFAIK, Mesa build for macOS generates a ibGLX which depends on X11, which is 
probably not what you want.  You want to use Mesa for macOS apps which use CGL 
as opposed to GLX, right?


So, if one wants to have a SW renderer on macOS with llvmpipe without depending 
on X11, then one would need to implement:

  *   a new Gallium 
frontend
 that implements CGL API (equivalent to the WGL frontend that exists for 
Windows)
  *   a new SW renderer 
winsys 
that draws pixels to Cocoa window somehow (equivalent to the GDI winsys that 
draws to a Windows GDI surface)

It's not a matter of just integrating existing components together -- there's 
lot of new code that would be need here -- I'd reckon 2 months for somebody 
familiar with Mesa/macOS, 6 - 12 months for somebody more novice.  And let's be 
frank, given mac deprecation of OpenGL and migration away from Intel to Arm, 
the usefulness of this in the long term is dubious.


Jose


From: mesa-dev  on behalf of Martin 
Pernollet 
Sent: Friday, April 29, 2022 12:32
To: mesa-dev@lists.freedesktop.org 
Subject: Enable OpenGL software rendering on macOS


⚠ External Email

TLDR : I failed using Mesa software rendering on macOS. I am looking for advice 
to invoke mesa's libGL.dylib without relying on macOS's system GL.


Hi everyone,

I am building (java) software involving Mesa for CPU rendering. I use CPU 
rendering as fallback when JOGL (OpenGL binding for Java) fail to use the GPU 
natively. This is sometime the case for old Linux distributions, this will 
certainly be frequent on macOS in the future due to Apple's OpenGL deprecation.

Mesa CPU rendering is working great on Ubuntu (by enabling 
LIBGL_ALWAYS_SOFTWARE=true) and Windows (by simply loading Mesa's DLL instead 
of system DLL, no need to ask for software mode).

I however thrive to use Mesa's software rendering on macOS for the following 
reasons

  *   Spying dynamic library load sequence shows that whenever Mesa's 
libGL.dylib is loaded, Apple Metal and libGL.dylib are loaded before, even when 
using DYLD tricks to ensure Mesa get loaded before any other library (except 
the Java VM) [1] Someone says that Mesa's macOS implementation relies on system 
GL [4]. I noticed that when enabling LIBGL_ALWAYS_SOFTWARE=true, this activates 
Apple software rendering but not Mesa's software rendering [5]. I wonder how I 
could avoid this and use a pure Mesa's OpenGL implementation in this situation.
  *   When getting out of the java World
 *   Running a pre-built glxgear/glxinfo installed through MacPorts only 
allows using Apple's libGL.dylib but not Mesa's libGL.dylib [2].
 *   Building glxinfo myself by linking explicitely to Mesa's GL + X11 lead 
to an X11 error that I am not able to depict [3].

This has been discussed already on Khronos community [1] but I have no clue how 
to go further. I hope some experts here can help me solve this!

Thanks in advance,

Martin

[1] 
https://community.khronos.org/t/failing-to-load-mesa3d-on-macos-instead-of-macos-provided-opengl-library/108408
[2] 
https://community.khronos.org/t/failing-to-load-mesa3d-on-macos-instead-of-macos-provided-opengl-library/108408/14
[3] 
https://community.khronos.org/t/failing-to-load-mesa3d-on-macos-instead-of-macos-provided-opengl-library/108408/19