No VRAM for R9 270X #48
Comments
|
Your output doesn't include the pci id. You need to use "lspci -vnn" for the numbers to be there. However, google says it's 1002:6810. That pci id is included, so something else is preventing VRAM status. Maybe your kernel or libdrm is too old, or maybe your radeontop build was without amdgpu support. |
|
1002:6810 is the same header showing when I run I am not using amdgpu, I'm using radeon as my kernel driver, so building without amdgpu support should not be an issue. My kernel is 4.11.9, and libdrm is 2.4.81. I'm running a fully up to date Archlinux system, and tried both the latest stable radeontop, as well as building from git. |
|
Try adding printfs in detect.c, for example right after drmOpen, to see what it returned. |
|
haagch on the #radeon irc just got me to do this as well. |
|
Run it with LIBGL_DEBUG=verbose (sudo LIBGL_DEBUG=verbose radeontop), that should print some info on why drmOpen fails. |
|
So it looks like the issue may be in libdrm, rather than radeontop. I'm not entirely sure what this means, but it appears it's falling back to an old version because 1.4 fails. Then it tries to find my card, and fails to find it. Output: |
|
Yes, it's either a libdrm or kernel bug (or very unprobably udev). Please open a bug against libdrm, title something like "libdrm fails to get bus id" (do try libdrm git first, though). The interface version doesn't matter, my system also prints that. |
|
Thank you for your help. The issue still occurs with lidrm-git, so I will open an issue with them. |
|
I received a response from my bug report on libdrm:
I'm not sure if this means much to you. I am not a C programmer, so I'm not sure how to write the changes they suggest myself. The bug report is here: https://bugs.freedesktop.org/show_bug.cgi?id=101837 |
|
I've just tested on my friend's system and he has the exact same issue. |
|
Same here with Mesa and libdrm from git on a Radeon 6950. @clbr "it's either a libdrm or kernel bug (or very unprobably udev)" - No, it's not. I just bisected it: I know there are commits in between the good and the bad commit: I couldn't test them as gentoo refuses to install them: Please fix this ASAP as I need a way to measure VRAM and GTT live to confirm a possible driver bug. |
|
Please look at commit 219a3e6 in your range. That very commit changed from a hardcoded path to using libdrm's drmOpen. If drmOpen fails for you, then it is not radeontop's fault, as the arguments to it are correct. |
|
(and seriously, "fix this ASAP" on new year's eve?) |
|
It's a bug in your app if it worked before: There's something called fallback. Weirdly even with a fallback it doesn't work: V10lator@21f107e This brings me to believe you dont know the real root of the bug and I really don't have the time to read into your codes and debug this for you. (Sorry for the "ASAP" but as I told I was in urgent need of it (and as you refuse to fix this since month had to hack together a version that works for me on new years eve)) |
|
I don't care to trace a likely kernel bug I can't reproduce, on hardware I do not have.
It is not my code that fails. I don't want to repeat myself, so please see my previous reply. |
|
Or a gimp analogy: gimp version Y used gtk2 and ran on your computer, Y+1 changed to gtk3 and your gtk3 setup fails for some reason. You'd still argue it's gimp's bug. |
|
I got the same problem with the VRAM reporting. Edit: My GPU is an AMD RX 460 |
|
"Or a gimp analogy: gimp version Y used gtk2 and ran on your computer, Y+1 changed to gtk3 and your gtk3 setup fails for some reason. You'd still argue it's gimp's bug." @Fisher42 Setting the driver name is the key here I guess. Will try to do that later on and if it works with the fallback codes I'll do a pull request. //EDIT: @clbr Think about it this way: Your codes worked before, you know exactly what change triggered the bug and a fallback to the old codes seems plain stupid (not like changing from gtk3 back to gtk2 which I agree would be a stupid fallback), so why are you refusing to do that? |
|
I'm doing this in my free time, which I do not have an abundance of - why do you assume you are the only busy person? I have posted to and am subscribed to the bug linked above, so I'm already doing what you ask, working together. Secondly, this is not the only software that triggers it: many of the libdrm tests can also do so, and X drivers have done so in the past. You can likely write a couple-line sample that just calls drmOpen with your bus string, and have that reproduce it too. A fallback like your commit would be bad for two reasons: the bus path uses the very same function that fails inside drmOpen, so it would just repeat the failure; and a hardcoded card0 would fail on systems for which the drmOpen commit was made, those with intel+amd or nvidia+amd. Working around a failing dependency is not the spirit of open source, it is to fix problems at their source. Since I can't reproduce it, and the bug likely lies in the kernel, there is not much I can do. For anyone interested and with afficted hardware, here's what I'd do: follow the setInterfaceVersion and getUnique drm ioctls in the kernel, adding printks to every path to see what fails and how. I can't give more specific instructions without spending a lot of time on it. |
|
At the risk of provocation, I also have the VRAM part not working on my system as well when using an RX 480. |
|
New libdrm, new kernel and new card (rx 580) but still the same problem. Libdrm devs say "An orthogonal solution is to simply not use drmOpen. While it works, sometimes, there's a lot of hidden gotchas" (Source: https://bugs.freedesktop.org/show_bug.cgi?id=101837#c3 ) - yet @clbr ignores the gotchas and says it has to work his way. Also it's funny to see that other tools have no problem whatsoever to read the VRAM. @anadon I don't think @clbr will ever bother to fix this, so just use other tools (like radeon-profile: https://github.com/marazmista/radeon-profile ). |
|
As I wrote in that bug's comment 4 on 2017-07-21, the one following the linked comment 3, radeontop does need to open the node and so the solution provided in comment 3 cannot be used. |
|
Please walk us through what information is needed by radeontop that is only available through root access to a node. |
|
@clbr Did you look how radeon-profile reads out the VRAM? It seems it doesn't use drmOpen (but I didn't look too deeply, so I might be wrong. Anyway, it works there) : @anadon Sorry, I just woke up before writing my last comment. Still I fail to see what was obnoxious as I just pointed out that there are gotchas @clbr should be handling (if he wants to keep the drmOpen path), that other tools are able to read the VRAM without problems and giving you an alternative tool to help you reading out the VRAM usage. |
|
@V10lator You're blaming clbr and backing him into a corner where he is backed into a corner and needs to justify himself very defensively in order to maintain any validity of his opinion and position. Putting people into such a social corner stresses, and reduces how cooperative they are yielding a purely worse situation. You did this in a very direct manner with harsh tone. In the flow of communication these actions are very disruptive, thus fitting the descriptor of 'obnoxious'. There are situations where being so harsh is necessary, but this is not one of them. For further reading, there was a study of effective arguments on r/changemymind which touches on many of these [1] and IBM released a tone analyzer [2] for writing which can help make such writing more plain when you might miss something. [1] https://arxiv.org/pdf/1602.01103 |
|
@anadon @V10lator |
|
OK, I traced the code. it's very bad, but basically:
there is probably a menu somewhere for picking the card. |
|
So... what I've found so far:
Long story short, you should read comment at the top of https://elixir.bootlin.com/linux/v5.1/source/drivers/gpu/drm/drm_ioctl.c#L43 and open the device by name or directly as @Hello71 wrote. Opening by name can be as simple as adding a new commandline option for specifying driver name or path to dri node. No need to make something fancy. Opening by BUSID is simply unsupported and it is sad that it has been 2 years since this bug is known and still not fixed. :( |
|
trek00 contributed some amdgpu improvements. Please test current git. |
|
I've tested the current master (09d8c0b) on Arch Linux with kernel 5.2.0-arch2-1-ARCH and it works perfectly - VRAM is shown on my POLARIS11. Even under a non-root user. Good work! |
…s EPERM cause only DRM_MASTER can call it :( clbr/radeontop#48 (comment)
drmOpen needs bus id check which needs interface 1.4 ioctl which gives EPERM cause only DRM_MASTER can call it :( clbr/radeontop#48 (comment)
drmOpen needs bus id check which needs interface 1.4 ioctl which gives EPERM cause only DRM_MASTER can call it :( clbr/radeontop#48 (comment)
drmOpen needs bus id check which needs interface 1.4 ioctl which gives EPERM cause only DRM_MASTER can call it :( clbr/radeontop#48 (comment)
drmOpen needs bus id check which needs interface 1.4 ioctl which gives EPERM cause only DRM_MASTER can call it :( clbr/radeontop#48 (comment)
drmOpen needs bus id check which needs interface 1.4 ioctl which gives EPERM cause only DRM_MASTER can call it :( clbr/radeontop#48 (comment)
Using plain `open` as `drmOpen` needs bus id check which needs interface 1.4 ioctl which gives EPERM cause only DRM_MASTER can call it :( clbr/radeontop#48 (comment)
Using plain `open` as `drmOpen` needs bus id check which needs interface 1.4 ioctl which gives EPERM cause only DRM_MASTER can call it :( clbr/radeontop#48 (comment)
Using plain `open` as `drmOpen` needs bus id check which needs interface 1.4 ioctl which gives EPERM cause only DRM_MASTER can call it :( clbr/radeontop#48 (comment)
Using plain `open` as `drmOpen` needs bus id check which needs interface 1.4 ioctl which gives EPERM cause only DRM_MASTER can call it :( clbr/radeontop#48 (comment)
Using plain `open` as `drmOpen` needs bus id check which needs interface 1.4 ioctl which gives EPERM cause only DRM_MASTER can call it :( clbr/radeontop#48 (comment)
Using plain `open` as `drmOpen` needs bus id check which needs interface 1.4 ioctl which gives EPERM cause only DRM_MASTER can call it :( clbr/radeontop#48 (comment)
|
hello, the problem with displaying 0% load in the mangohud overlay has been preserved |
radeontop outputs "Failed to open DRM node, no VRAM support."
then continues to run, but does not display my VRAM usage.
My card is a Club3D R9 270X. It's a very uncommon brand, so someone in the #radeon irc suggested that it may be that my PCI ID is not in the supported devices list. I've attached part of the output of
lspci -vv. If any more information is needed, I'll be happy to provide it.Thank you.
EDIT: Updated lspci output
The text was updated successfully, but these errors were encountered: