API tools faq
paste
Advertisement
Guest User

Manually testing Mesa drivers

a guest
Dec 1st, 2015
204
0
Never
Add comment
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 6.30 KB | None | 0 0
raw download clone embed print report
  1. By using some environments variables used by Mesa (LIBGL_DEBUG,LIBGL_DRIVERS_PATH), it's possible to make the current Mesa (old, from distribution's repository) load a driver (new, freshly built) as opposed to the ones distributed by the package manager. Have a list of commands:
  2.  
  3. export MESA_INSTALL_DIR=/home/some-user/some-install-dir
  4. # Setting LD_LIBRARY_PATH is required because a call to "_glapi_Dispatch" on libglapi.so will be done.
  5. # The contents of stderr (which will be filled by Mesa's report) are piped to output.log
  6. LIBGL_DEBUG=verbose LIBGL_DRIVERS_PATH=$MESA_INSTALL_DIR/lib/dri LD_LIBRARY_PATH=$MESA_INSTALL_DIR/lib glxinfo 2> output.log
  7.  
  8. The file "output.log" should look like this:
  9. libGL: OpenDriver: trying /home/some-user/some-install-dir/lib/dri/r600_dri.so
  10. libGL: Can't open configuration file /home/some-user/.drirc: No such file or directory.
  11. libGL: Can't open configuration file /home/some-user/.drirc: No such file or directory.
  12. libGL: Using DRI2 for screen 0
  13.  
  14. It works. The ".drirc" file has no relation to the issues below. It's possible to change "glxinfo" to "glxgears" or "xonotic-sdl" (if you have it installed) and it will work just fine.
  15.  
  16. [ISSUES]
  17.  
  18. However, the odd thing is, after loading the *new* drivers, old, resource-poor contexts are given as opposed to more resourceful contexts.
  19.  
  20. [Output of "glxinfo", using /usr/lib64/dri/r600_dri.so given by the distribution's maintainers]
  21. OpenGL vendor string: X.Org
  22. OpenGL renderer string: Gallium 0.4 on AMD CEDAR (DRM 2.43.0, LLVM 3.7.0)
  23. OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.0.3 (git-b4bfea0)
  24.  
  25. [Output of "glxinfo", using /home/some-user/some-install-dir/dri/r600_dri.so]
  26. OpenGL vendor string: X.Org
  27. OpenGL renderer string: Gallium 0.4 on AMD CEDAR (DRM 2.43.0, LLVM 3.7.0)
  28. OpenGL version string: 2.1 Mesa 11.2.0-devel (git-99cd600)
  29.  
  30. And this is very likely *not* a regression. I have checked out the commit "b4bfea0", built it, and loaded it. The results were exactly the same. There is another major difference, which is the "output.log" file:
  31.  
  32. [The command for getting an output.log like this is: LIBGL_DEBUG=verbose glxinfo 2> output.log]
  33. libGL: OpenDriver: trying /usr/lib64/dri/tls/r600_dri.so
  34. libGL: OpenDriver: trying /usr/lib64/dri/r600_dri.so
  35. libGL: Can't open configuration file /home/some-user/.drirc: No such file or directory.
  36. libGL: Can't open configuration file /home/some-user/.drirc: No such file or directory.
  37. libGL: Using DRI2 for screen 0
  38.  
  39. On this case, Mesa's loader has attempted to open $MESA_INSTALL_DIR/tls/r600_dri.so, which it didn't on the other case. I have no idea if this is related to this issue.
  40.  
  41. I'm still grasping how Mesa's structure work (I've read about Gallium, DRM, Linux Kernel Module Development...), so I might be missing details on how the driver loading process really works. For example, is the "*_dri.so" (in this experiment, "r600_dri.so") library dinamically linked against (or loaded by) a program that runs on kernel space? If that is the case (which I seriously hope and believe it's not), what would prevent malicious code being added to a dummy "r600_dri.so" and then Mesa, seeing the environment variable set, happily loads it and calls it? Since I strongly believe this is not the case, then why does the OpenGL context degrade?
  42.  
  43. [FURTHER INVESTIGATION]
  44.  
  45. By copying the binary shared objects given by the distribution maintainers on "/usr/lib64/dri" to "/home/some-user/binary-objects" and making Mesa load them, I hoped to get some insight (would these binaries, as opposed to the freshly built ones, work?), and I indeed got some insight. The command is the following:
  46.  
  47. LIBGL_DEBUG=verbose LIBGL_DRIVERS_PATH=/home/some-user/binary-objects LD_LIBRARY_PATH=$MESA_INSTALL_DIR/lib glxinfo 2> output.log
  48.  
  49. libGL: OpenDriver: trying /home/some-user/binary-objects/r600_dri.so
  50. libGL: dlopen /home/some-user/binary-objects/r600_dri.so failed (/home/some-user/binary-objects/r600_dri.so: undefined symbol: _glapi_tls_Dispatch)
  51. libGL error: unable to load driver: r600_dri.so
  52. libGL error: driver pointer missing
  53. libGL error: failed to load driver: r600
  54. ...
  55.  
  56. It failed to load because of a missing symbol. By removing the LD_LIBRARY_PATH environment variable, it loads properly. So, it means that "_glapi_tls_Dispatch" is not on the freshly built Mesa libraries, but it somewhere under /usr/lib64? Very, very likely, yes. I've used the following command and the output was empty:
  57.  
  58. find $MESA_INSTALL_DIR -type f \( -name '*.so' -o -name '*.ko' -name '*.o' \) -exec nm -A {} \; | grep _glapi_tls_Dispatch
  59.  
  60. However, by using a slightly different command, I do have found the _glapi_Dispatch (which was also a missing symbol a while ago) on the freshly built objects:
  61.  
  62. $MESA_INSTALL_DIR/lib/dri/kms_swrast_dri.so: U _glapi_Dispatch
  63. $MESA_INSTALL_DIR/lib/dri/r600_dri.so: U _glapi_Dispatch
  64. $MESA_INSTALL_DIR/lib/dri/swrast_dri.so: U _glapi_Dispatch
  65. $MESA_INSTALL_DIR/lib/dri/nouveau_vieux_dri.so: U _glapi_Dispatch
  66. $MESA_INSTALL_DIR/lib/dri/r200_dri.so: U _glapi_Dispatch
  67. $MESA_INSTALL_DIR/lib/dri/i965_dri.so: U _glapi_Dispatch
  68. $MESA_INSTALL_DIR/lib/dri/vmwgfx_dri.so: U _glapi_Dispatch
  69. $MESA_INSTALL_DIR/lib/dri/r300_dri.so: U _glapi_Dispatch
  70. $MESA_INSTALL_DIR/lib/dri/radeon_dri.so: U _glapi_Dispatch
  71. $MESA_INSTALL_DIR/lib/dri/i915_dri.so: U _glapi_Dispatch
  72.  
  73. Why is that there are no objects with '_glapi_tls_Dispatch' ? Strange, strange... Have I missed some flags on the building process? Because that symbol do is on the source code:
  74.  
  75. /src/mesa/drivers/dri/common/dri_test.c:14:PUBLIC __thread struct _glapi_table * _glapi_tls_Dispatch
  76.  
  77. I've tried to find _glapi_tls_Dispatch on the distribution's binaries, but had no success. "nm" kept outputting to stderr "(...) no symbols". All of "/usr/lib", all of "/usr/lib64". Not a single symbol (Makes sense. The distribution maintainers are probably saving space and bandwidth). The dependencies are probably resolved by the filename (I'm reading the following: www.kaizou.org/2015/01/linux-libraries/ ).
  78.  
  79. By the way, the idea of testing Mesa by dynamically loading objects came into me after reading the following blog entry:
  80. http://blogs.igalia.com/itoral/2014/09/04/driver-loading-and-querying-in-mesa/
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement
Public Pastes
Advertisement
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy.  OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!