Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preliminary implementation of OpenGL detection on Linux #73

Merged
merged 1 commit into from
Mar 20, 2024

Conversation

Zaraka
Copy link
Contributor

@Zaraka Zaraka commented Mar 20, 2024

I promised in #68 that I would implement Linux OpenGL detection, welp I totally forgot that I actually did some kind of detection months ago, so there you have it.

This right now uses only EGL, which is of course a problem. The status of Linux OpenGL suffers from many historical issues, especially X11 therefore we have two main ways how to get GL context in Linux

  • GLX - which is an old, mostly unmaintained piece of technology that is older than the majority of gen Z, this was designed for X11, but you can get it working on Wayland using XWayland
  • EGL - a new way how to do GL stuff without X11 on Linux, it's much nicer to use, but not as widely supported

Getting renderer and vendor is easy, but it gets hard once you want to query memory or even frequency info.
For memory, there are two GL extensions GL_NVX_gpu_memory_info and GL_ATI_meminfo, both work on AMD and NVIDIA, because mesa developers are chads. The problem is both require desktop GL, which would not be a problem, but...
NVIDIA only supports OpenGL ES 2.0 on EGL, so that is a case which needs GLX instead of EGL.
GL_ATI_meminfo is kinda useless because it won't give you the total memory amount only the free parts, I found out that there are functions to get the total amount (GetGPUInfoAMD), but they are only in the WGL association, that is not available on Linux. They may be available in GLX as well, but I have not found them yet.

GL_NVX_gpu_memory_info does not provide any info on the cache/shared memory size.

To this day I have no idea how to get GPU frequency on Linux without using AMD/NVIDIA specific tools and libraries (which we probably don't want to use as well)

I may contribute fixes and developments to this, maybe even GLX implementation in the future, but at this point, I would like to ask you a question I have been asking several times a week for the last year "Why not Vulkan?"

@nabijaczleweli
Copy link
Collaborator

remote/Lenovo 300e Chromebook 2nd Gen (Intel)/Lenovo 300e Chromebook 2nd Gen (MTK) (the warnings/errors went to the standard error stream)/local AMD GPU

==> tarta <==
Infoware version 0.6.0

  Properties:
    Device #1:
      Vendor       : Unknown
      Name         : llvmpipe (LLVM 15.0.6, 128 bits)
      RAM size     : 0B
      Cache size   : 0B
      Max frequency: 0Hz


==> chrust <==
Infoware version 0.6.0

  Properties:
    Device #1:
      Vendor       : Intel
      Name         : Mesa Intel(R) UHD Graphics 600 (GLK 2)
      RAM size     : 0B
      Cache size   : 0B
      Max frequency: 0Hz


==> chwast <==
libEGL warning: DRI2: failed to authenticate
MESA: error: ZINK: failed to choose pdev
libEGL warning: egl: failed to create dri2 screen
Infoware version 0.6.0

  Properties:
    Device #1:
      Vendor       : Unknown
      Name         : llvmpipe (LLVM 17.0.6, 128 bits)
      RAM size     : 0B
      Cache size   : 0B
      Max frequency: 0Hz

==> rozbian <==
Infoware version 0.6.0

  Properties:
    Device #1:
      Vendor       : AMD
      Name         : AMD Radeon RX 6500 XT (radeonsi, navi24, LLVM 17.0.6, DRM 3.54, 6.6.13-amd64)
      RAM size     : 0B
      Cache size   : 0B
      Max frequency: 0Hz

@nabijaczleweli
Copy link
Collaborator

nabijaczleweli commented Mar 20, 2024

Given the 1992 release date, GLX has a good part of a decade on me, yeah.

Output from my tests looks reasonable. The 6500 XT doesn't appear to have GL_NVX_gpu_memory_info, hence the 0B as-seen. Can't really test on my nvidia GPUs rn.
Applied; cleanups in 3e49973.

Not vulkan because in May 2016 (617baca) vulkan was three months old to the public; I'm not opposed to a vulkan back-end.

@nabijaczleweli nabijaczleweli merged commit 6b53628 into ThePhD:main Mar 20, 2024
12 of 14 checks passed
@nabijaczleweli
Copy link
Collaborator

5158f0a

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants