OPENGL renderer crashes on intel IGP #212
Labels
bug
Something isn't working
legacy core
This issue also affects the original melonDS libretro core.
opengl
For issues related to OpenGL.
Comments
|
Also, starting with left/right layout seem to work, while using top/bottom does crash. |
kokoko3k
changed the title
It might be; when RetroArch requests the max screen size for the first time, the OpenGL context hasn't yet been created so I don't have a good way to ask for the maximum possible size at that point. There are other things I can do that aren't too disruptive, though. Before I begin work on this, could you try 1.1.3 once it's available on the core downloader (likely over the weekend)? It fixes an unrelated bug, but I'd like to see if it makes a difference here as well. (I don't have the GPU you're using, so I can't test it myself.) |
|
Sure, I'll check by monday, thanks! |
|
Since it was not yet available, I downloaded the release from here, ensured it was properly installed and tried again, but unfortunately no change. |
|
I noticed that the maximum dimensions requested by the OpenGL renderer fit within your device's maximum texture and renderbuffer size. With that in mind:
|
|
Thank you for looking into this.
|
|
Hm...
|
|
Oh, wait, there was a false assumption due to my mistake, i suppose. Already tried to set renderer to 1x to no avail. I omitted to answer the other questions due to the layout tied issue which is not true. -wait, I need to re-try with the older melonds core. Btw, this IGP is able to run flycast core with heavy shaders, slow ofc, but with no crash. At this point I think this is going to be trickier to fix, but at least software renderer is ok. |
|
What about VRAM usage? What other applications (including basic system services!) are you running that use the Intel GPU? Also, what about standalone melonDS? Does the issue occur there, too? |
JesseTG
added
the
legacy core
|
I just logged off from the graphical Xorg session and turned off the display manager too. |
|
Could you test standalone melonDS as well (with varying levels of upscaling)? I took some rough numbers and it uses far less VRAM than RetroArch does. If the OpenGL renderer works in standalone melonDS, then that's enough for me to be sure that this is a VRAM issue. |
|
I can scale on MelonDs standalone until 13x (3328x2496), where it starts for a while then crashes with the same error as on the core. As stated in the very first post, it works fine for other scaling levels. |
|
Ah, yes, excuse me. Okay, I think I know enough to work on a fix. Hang tight. |
|
For a while I'd encountered an issue where using melonDS DS on macOS would crash my machine. It turns out that the cause is most likely the same as your issue here; namely, running out of VRAM. My Mac is a very old model with about the same amount of VRAM as yours. |
Notes to SelfThe main thing giving me pause about a fix for this issue is that the libretro API itself doesn't have a way to tell a core that it can't provide the framebuffer it's asking for. Even if I kept the initial framebuffer size small and progressively asked for larger ones based on the internal resolution scale, this wouldn't stop a crash; it would just put it off. And when that crash does occur, you're still left with a broken config that has to be manually deleted. Fixing this the "right" way to allow for graceful degradation would probably need a new API that every video driver in RetroArch would have to implement. But I think I have an idea that can at least mitigate the need to manually edit a crash-causing config; I can create a temp file with a known name that exists only for the duration of some crash-prone operation. If the core crashes before the file is cleaned up, then next time the core starts it'll see the file it'll know that there was a crash. At that point it can forcibly change the (presumed) offending option to something stable. |
|
Not sure if you could try to make a test with Mesa using crocus driver instead of Mesa Amber and i915 ? It should be possible as you are running Intel Gen 4, if I am correct ?
|
JesseTG seems to have reproduced the problem even on a Mac, so i really doubt a change in the driver would solve the issue; maybe it would spit a different error message tho. |
|
The issue is that libretro offers no way to tell the core that the VRAM it wants can't be allocated, so the core doesn't get a chance to try again; the frontend just takes the result of And having the core estimate available or required VRAM won't suffice either; not only is *Now that I think about it, even if it did return |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What version of melonDS DS are you using?
1.1.1
Does the problem happen in standalone melonDS?
No, it's a bug specific to melonDS DS.
What happened?
Trying to use Opengl renderer leads to segmentation fault when using integrated intel gpu.
Works fine with nvidia tho.
What should've happened instead?
Working on intel igp too.
Here's the log from a crash:
Which platforms do you see the problem on?
Which versions of the OS?
Archlinux
Which libretro frontend are you using?
1.18.0
Terms
The text was updated successfully, but these errors were encountered: