FEX-Emu / FEX

A fast usermode x86 and x86-64 emulator for Arm64 Linux
https://fex-emu.com
MIT License
2.37k stars 124 forks source link

Libraries we need to Thunk #267

Open Sonicadvance1 opened 4 years ago

Sonicadvance1 commented 4 years ago

Libraries we need for performance reasons

Libraries we need for compatibility reasons

Add more here

skmp commented 2 years ago

(Removed myself as I'm not in thunks for now)

Sonicadvance1 commented 2 years ago

libm would be interesting

Sonicadvance1 commented 2 years ago

libopenal?

Sonicadvance1 commented 2 years ago

libfmod might be interesting as closed source to closed source thunking support.

Sonicadvance1 commented 2 years ago

libvulkan directly instead of the device drivers. At the very least will resolve a hang in current vulkan thunking but also will mean we don't need to generate a device thunk per driver. A lot of the work for the device drivers can be reused for the libvulkan loader.

skmp commented 2 years ago

After some more thorough investigation on how GLX and EGL are implemented under the hood, it looks like we don't need to thunk X11 or Wayland by doing a secondary connection to the display server for GLX or EGL purposes.

While I thought that doing this on GLX is a bit of a hack, EGL will use parallel connections both for X11 and Wayland to handle eglGetDisplay(EGL_DEFAULT_DISPLAY) and uses dri2_egl_display::own_device to track this.

For X11, see https://github.com/mesa3d/mesa/blob/6f4b5fb67507b607d61ab8316dfa3bbc4bab6498/src/egl/drivers/dri2/platform_x11.c#L1327.

For wayland, see https://github.com/mesa3d/mesa/blob/6f4b5fb67507b607d61ab8316dfa3bbc4bab6498/src/egl/drivers/dri2/platform_wayland.c#L2681.

Also, detecting the platform from the native display is done in an interesting (scary?) way we can reuse, https://github.com/mesa3d/mesa/blob/3415bf0268884bf3c16d495a4e1afd30d67bc71d/src/egl/main/egldisplay.c#L129

Related: #1728

skmp commented 2 years ago

Chromium, and hopefully no one other, buypasses libGLX and directly assembles the GLX X11 requests and sends them over with xcb.

Chromium's Glx::GetFBConfigs that hand assembles the GLX request https://github.com/chromium/chromium/blob/main/ui/gfx/x/generated_protos/glx.cc#L2015

Chromium's Connection::SendRequest that uses xcb to send raw requests https://github.com/chromium/chromium/blob/main/ui/gfx/x/connection.cc#L529

GLX Wire format: https://www.khronos.org/registry/OpenGL/specs/gl/glxencode1.3.pdf

At least xcb is used and is not bypassed there too.

This makes our GLX thunks... more involved, and may or may not be a problem.

libGLX is still used for most other thinks (and hardware initialization)

Interesting links:

https://xcb.freedesktop.org/opengl/

https://stackoverflow.com/questions/41069032/if-pure-xcb-opengl-is-impossible-then-whats-the-use-of-the-xcb-glx-api-found

skmp commented 2 years ago

Leaving it here as a note, we should also test for libraries brought in through DT_NEEDED for compatibility reasons (see #1880 for an example of why this is a good idea). readelf -d can help is enforce/validate this as part of the build.

While at it, we should validate SONAME as well.

kmp@mangie:~/projects/FEX/build$ readelf -d /lib/x86_64-linux-gnu/libGLX.so

Dynamic section at offset 0x21da0 contains 29 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libGLdispatch.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libX11.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000e (SONAME)             Library soname: [libGLX.so.0]