GLideN64 won't work on Linux with an Intel GPU (Mesa driver) #454
Comments
|
Minimum OpenGL is 4.2, where did you read that? |
|
I have only OpenGL 3.3 & plugin works |
|
I tried here with my Intel HD Graphics 4600: With the binary from the release: |
|
glxinfo | grep OpenGL: |
|
Mine is: |
|
OpenGL core profile shading language version string: 3.30 If real shading language version is 1.30 - you're doomed. The plugin dumps errors in gliden64.log file. Check, is it created? |
|
shader_compile error: 0:1(10): error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES |
|
You need card/driver with GLSL 3.30 support. I think, this can be closed. |
|
"The development release of Mesa 10.1 may implement GL 3.3 on radeon drivers, but you need to request a 3.3 core profile. You are not doing this currently." http://stackoverflow.com/questions/21565680/how-to-enable-opengl-3-3-using-mesa-10-1-on-ubuntu |
|
It seems you have to ask core profile 3.30, to enable it: http://darmawan-salihun.blogspot.com.br/2015/03/glsl-330-in-intel-haswell-cpu.html |
|
Before closing this ticket, we should give this a try. |
|
Sadly, it's still the same with the public release 1.1. Is there a way to force OpenGL ES 3.0 on GLideN64? Because my driver supports it.
|
|
Trying last commit b219997: |
|
If you check, Intel also has issues with windows #512 , so I guess there's no escape from the issue |
|
Maybe you can get a proprietary driver for linux (or go to the open source version if you already have the official driver) to fix it though |
|
There is no intel proprietary driver for linux... |
|
^ This. So yeah, GLideN64 won't work even if compiled with -DGLES2=On, it'll always give a segfault.... EDIT: Pinging @gonetz , with GLES2 it actually doesn't create the gliden64.log file, just a segfault. What do you think? |
|
what about this link? https://downloadcenter.intel.com/download/13815/Intel-Graphics-Drivers-for-Linux- I think these are the proprietary drivers |
|
This is Mesa, Xorg, kernel and other stuff updated... |
|
After doing some experimenting, I was able to get the plugin to run* on my computer by running mupen64plus using the following command: MESA_GL_VERSION_OVERRIDE=3.3COMPAT mupen64plus --gfx This problem comes because Mesa does not really support compatibility profiles, but you can force them using the above environment variable. I think you can also force in drirc, but I haven't tried that.
|
|
It won't run until you turn off multi-sampling. After doing that I'm playing Legend of Zelda Ocarina of Time on GLideN64 on my Intel Mesa graphics driver just fine. |
|
For me it still doesn't work, even with MESA_GL_VERSION_OVERRIDE and with multi-sampling turned off. It still segfaults... What distro are you using? |
|
Debian testing. Without knowing what the segfaults are, I'd naturally try messing with the settings (for reference, I also ran into issues trying to turn on hi res textures). I'd also make sure that you're building from source and referencing the correct .so file when running mupen64plus (the --gfx option). If you post the output you're getting then maybe I can speculate more. |
|
I have now resolved this issue by erasing mupen64plus's cfg file, looks like I have messed up with the settings in the past, maybe this is what has caused the segfault (strangely, it happened only with this graphic plugin). Now it works with a clean cfg file. Thanks! Still, I won't close this issue because MESA_GL_VERSION_OVERRIDE is only a workaround and it won't fix properly the graphic plugin. We need to make GLideN64 request the proper OpenGL core profile as it has been said before. |
|
Whether or not this issue should be closed is at least debatable. I tried forcing the application to request a core context, but the plugin definitely uses some deprecated (GL <= 3.0) functionality, and it didn't look trivial to get rid of those. |
|
That's very unlikely, see here: http://lists.freedesktop.org/archives/mesa-dev/2012-August/026624.html If you're going to file that bug report, I'll close this. Thanks. |
|
After taking a look at the Mesa GL3.txt, you're absolutely right about the compatibility context. |
|
Gah mobile browser. And the issue of whether or not to close the bug becomes an issue of practicality. If people who come here searching for a solution are more likely to find it if it is open then it might be worth while to keep it open. |
|
There are other things that could be done to try and improve performance, including mapping triangles.vertices and m_rect directly to the buffer instead of doing a memcpy. like: then doing all the work on triangles.vertices, then unmap before the draw call, but that would involve more drastic changes to the code, and I'm not sure if it would be much of a difference from the memcpy. The other things is using VAO's instead of setting the glVertexAttribArray calls before each draw call, and that would involve at least 2000 VAO's, one for each buffer offset for each VBO. The information I read about VAO performance isn't that encouraging, which is why I didn't bother trying that out. |
|
So I can confirm that this (the vbo5 branch) allows the Core Profile to work, tested in RetroArch. I'm not really sure what more could be done to improve the performance. Any input from anyone would be appreciated. |
|
You could have two separate code paths depending on a configuration option, one with the new way and one with the old. That way drivers that need the core profile, can switch that to enabled. It could also be selected automatically at runtime through auto detection of the OpenGL renderer. |
|
Well you always need the core profile for OpenGL (3+, which is what GLideN64 supports), the only time you can "legally" choose between VBO's and client side arrays is in GLES2/3, so you could make the old way used by the GLESX ifdef to include GLES3/3.1. I've updated the vbo5 branch since you tried it last, I realised I did my math wrong and it was creating a 20MB VBO, not a 2MB VBO like it should, so the performance might be better. It would be best to get VBO's working well since it is the "proper" way to do it, but if it can't get there, I think using the old way for GLES2/3 would be sufficient. |
|
I just tested your latest update to the vbo5 branch. I don't see a difference in speed. |
|
Ya so this new code could be avoided by GLESX ifdefs since it doesn't offer any performance benefit. It is still required for OpenGL 3+ though, I assume the performance is going to be the same since laptops/desktops have much better memory bandwidth. |
|
Memory bandwidth is much less of a concern for mobile since the memory is shared between the CPU and GPU. I think the calls you are making should be faster based on that. I don't get why they are slower. |
|
"Classic" GL drivers have a lot of hardware specific optimization. Modern GL makes certain hardware architectures more efficient since the driver has to keep track of less state translation, but it doesn't help with existing mobile architectures that much AFAIK. Memory bandwidth isn't a given. People running 7-y/o desktop hardware (e.g. Evergreen AMD GPUs, like my old rig) should be able to expect 60 VI/s with fancy options like bloom and pixel shaded light disabled. Stuff that old doesn't have good memory bandwidth. The performance penalty is probably just increased indirection. Also, GL has a lot of calls that seem like they should be non-blocking internally, but actually make the driver block on itself much like glfinish(), or only on specific dependants, etc. And drivers are allowed to implement more aggressive internal state blocks on such functions. It's a quagmire, but it's still better than old GL once you get everything sorted out; the problem is, there's no index of "GL functions to be careful with because drivers are allowed to make them behave slowly". |
|
Ya I guess you cant make assumptions about memory bandwidth. But either way, OpenGL 3.1+ mandates the use of VBOs as far as I understand it, and I can't think of any way to implement them faster than the way I have it in that vbo5 branch with glMapBufferRange (without some kind of major rewrite of how the draw calls happen). |
|
Think about it from the point of view of game engines. To a game engine, a VBO is a piece of, for archetypical example, model data that sits in memory for quite a while. Most drivers only make VBO write access fast when it's created a specific way, and have high latency, even if bandwidth is high. Calling a function that requires a VBO to be in a consistent state induces high latency in such an access method, if you recently modified it. Latency is the big problem for things like emulators using modern GL. You have to be exceptionally careful about reusing VBOs or calling functions that require them to be in a consistent state before said function can do its job and return. |
|
For me the vbo5 branch (glMapBufferRange) seems to perform just as good as the old way on my Mali device. I can't believe how poorly the Adreno devices I have perform, they have awful drivers. Anyway I'd need to do more testing but I'm willing to bet that the VBO approach performs the same as client side arrays on desktop OpenGL. I think the best way forward would be to use client side arrays on GLES 2/3 and VBOs on regular OpenGL |
|
That's probably a good idea. If GLES allows them, it allows them for a reason. There will probably be more room for optimizing VBOs - you can always do better with modern GL than oldschool GL on modern desktop GPUs - but that can come later. What's the general flow of data from the microcode HLE (where it determines drawing commands and parses their state) until it gets around to the GPU? My old fork just replaced the oldschool GL with 1:1 modern GL equivalents, and it was pretty slow, maybe 80%-50% the speed of forcing mesa to (crashily) run the compat profile version. |
|
@wareya if you ever get a chance your shoukd try https://github.com/loganmc10/GLideN64/tree/vbo5 for performance, it supports the core profile, I'd be curious how it performs for you |
|
It runs at full speed, but I don't know how fast it is aside from that. |
|
@loganmc10 Are these changes enough to make the code compatible with 3.2 core profile? mupen64plus should be able to provide necessary core profile if you provide it with required minor and major GL version.
N64 display list usually pretty logical:
Plugin does not use GL until some Triangle command appears. Plugin tries to cache polygons, which share the same setup and draw them all by one draw command. drawTriangles setups pixel pipeline and textures, setups glVertexAttribArray and calls glDrawElements. |
These changes are enough to make the code compatible with 3.3 core profile. 3.3 is still used in places in shaders. However, mesa on linux supports 3.3 core right now, so it might be good enough. I don't know about OSX. There are a couple changes that have to be made, but they're very minor: wareya@f5ef938 |
|
@gonetz Yes I've tested this with RetroArch, which can request a core profile, and it looks like @wareya knows the changes to make to allow mupen64plus to do the same. It still needs thorough testing, anything that issues a glDraw call (LLE triangles, DMA triangles, whatever drawLines deals with, texrects, post processing, etc..) could be affected, and I'm not sure what games trigger what situations. |
|
Note: GL defaults to the core profile. mupen64plus defaults to the compatibility profile because of its OSD. m64p is the only place where you have to specifically request a core profile. |
|
ok I made a "vbo" branch: https://github.com/loganmc10/GLideN64/tree/vbo with the commits squashed together and VBO's disabled for "GLESX" |
|
I tested this with |
|
In GLupeN64 you need to define CORE, so in the Makefile right after "-D__VEC4_OPT" add -DCORE |
|
Thanks, that worked, I was able to get to the Dawn of the first day in Majora's Mask without any significant issues. |
|
This should be fixed now since the code refactor |
|
Who can test? |
|
The laptop I use runs Fedora and uses an Intel GPU, switching to using a core profile solved this problem for me. |
|
Ok, I close it then. It always can be reopened if the problem still exists. |
But other video plugins will actually work on Mupen64plus. I have also tried to build the source, but (aside from few compilation errors that I have had to manually fix) GLideN64 still doesn't work.
In your blog you have said that GLideN64 now supports OpenGL 3.3, which is the higher version supported by the Mesa driver.
My system:
Debian GNU/Linux Jessie 8.0
Intel i7-4770K with HD Graphics 4600
The text was updated successfully, but these errors were encountered: