-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
(Video) KMS no longer works with mesa #7119
Comments
Its failing here. https://github.com/libretro/RetroArch/blob/master/gfx/video_driver.c#L1076 So I tried turning thread video on and I got a segfault instead.
|
This appears to be a RetroArch bug, I asked in #nouveau and was kindly explained where RetroArch is going wrong.
Edit: Fixed markdown. |
@RobLoach This is not a vulkan bug, I don't even have vulkan drivers. :) I think its a general EGL issue. |
It's an issue when using the GBM egl platform. It returns multiple configs, one for each (matching) pixel format exposed by the driver. There's no way to stop eglChooseConfigs from doing that. And then you have to iterate over them to find which one has the EGL_NATIVE_VISUAL_ID that matches the GBM_FORMAT_* that you want to draw with. (And note that DRM_FORMAT_* == GBM_FORMAT_*.) Otherwise you'll get either failures or misrendering depending on exactly which way the fail goes, since the "front buffer" of the config will be in a different format than what the scanout engine is configured for when you feed those surfaces in as drm framebuffers. |
@twinaphex Do you know who could help solve this? I think the above comment explains why this is broken and what should be done to fix it. |
I don't reproduce the issue using Mesa 18.1.7 (August 24, 2018) and Intel HD (5500). |
Because the first-returned config happens to be the one you're looking for? |
I tried to reproduce it with Nvidia card (GK107) and Mesa 18.1.7 but it is working also using RA with commit 7428fef4bc
|
Now update mesa, and potentially the kernel, so that you get 30bpp properly exposed. Then I think you might get the 30bpp config first. |
For reference I can still reproduce it with mesa commit https://github.com/mesa3d/mesa/commit/14fe9fa11baa4e4e782d192e0b8c150ee9e8754f from 11 days ago and linux 4.17.14. @gouchi Also thanks for the interest! |
I can't reproduce the issue using latest Mesa with Intel HD card. |
I'm not sure what you're trying to demonstrate... I've pointed out where the bug is, as well as code for how to handle it. You need a driver which returns EGL configs in an order where the first one returned doesn't happen to match the DRM format that you've chosen. Nouveau is an instance of this happening, but it can happen anywhere. Try e.g. requesting a 10bpp format with intel and it will fail in the way described. Or RGB instead of BGR (or vice-versa). |
@gouchi Any progress on this? |
@orbea I am afraid not. Somebody more skilled on this subject should help ;-) |
I know what you mean...thanks for the reply. |
This issue is also reproducible with amdgpu (mesa). |
We don't know how to fix this ourselves. Pull requests very much welcome. |
There is a good example of how to fix this in comment #7119 (comment). See this link where the same issue affected kmscube. https://cgit.freedesktop.org/mesa/kmscube/commit/?id=56c3917ffd1f05942246e2532ca4a5707554a2fc I would make a PR, but all my attempts at fixing this have been unsuccessful. My understanding of the code base and GL are too little. |
Maybe @imirkin can make the PR then. There is not enough inhouse knowledge right now on DRM/KMS where we feel reasonably confident to make such changes, and it would still have to be tested. |
On a side note, this issue only affects opengl, with amdgpu and vulkan KMS still works. However this won't work with GL cores, there are vulkan issues with parallel-n64 and Edit: Parallel-psx seems like an easy fix. libretro/beetle-psx-libretro#449 |
I threw together a quick fix following what had been done to kmscube to address the same issue. https://drive.google.com/file/d/1mT_lb9Of49M3eJszhGAqVzySGnG0BTIu/view?usp=sharing |
@dtsarr Yes, that does work! Thanks a lot! However now when starting a core such as Genesis GX Plus with KMS and OpenGL RetroArch will print the following. I suspect its related to this change as the same will happen with the patch applied to
And for the record here is the current patch.
|
On second thought that might be unrelated and was masked by how I was using nouveau before and am now using radeonsi. |
Yes, it seems like that, see the following links. https://github.com/mesa3d/mesa/blob/3b2ad8b290215a4bd52be4e397c9ab5603b8b372/src/amd/common/ac_llvm_util.c#L64 |
Removing the workaround in mesa silences the warnings and I suspect the rest is a mesa issue. @dtsarr What do you think? It seems like your change could be made into a PR?
|
@orbea Can you make the PR? I'm still very new to Git and I don't want to mess things up. Please note that I modified the code slightly on my drive. |
I made a PR with the updated code, again thanks a lot! |
It should hopefully be fixed after PR #7729. |
Description
With newer mesa (Git master currently) RetroArch KMS no longer works at least with some systems.
I have tested this with nouveau, but unfortunately I can't test with the llvmpipe or swrast because they have been broken with KMS for much longer, maybe they have never worked? If anyone can test intel or AMD with a new enough mesa it would be appreciated to see if this is a more general issue or not.
I'm not sure if this is a RetroArch or mesa bug, but I'm posting it here for more visibility.
Expected behavior
KMS should work.
Actual behavior
RetroArch immediately errors when trying to start KMS.
Steps to reproduce the bug
Bisect Results
I bisected this to this mesa commit.
https://github.com/mesa3d/mesa/commit/753f603b52db5eb38e27e1842fa43299a348998b
Version/Commit
You can find this information under Information/System Information
Environment information
Slackware64-current
gcc-8.2.0
The text was updated successfully, but these errors were encountered: