citra
citra copied to clipboard
AMD 22.7 workaround ... maybe
This works, although we "lose" ALLOW_SHADOW (assuming it was working before?)
GLAD_GL_ARB_shader_image_size
is false.
I don't understand why ALLOW_SHADOW is kept these days. Back when OpenGL ES 3.2 was bleeding edge it made sense to check for these features but nowadays almost every OpenGL driver supports image load/store operations. The mobile device requirements to run Citra are also pretty high already and I don't think any user would appreciate playing their games without shadow mapping. I propose to drop this and just throw a device unsupported error if GL_ARB_shader_image_load_store or GL_ARB_shader_image_size are not supported.
GL_ARB_shader_image_size is not supported on AMD's drivers in a 3.3 context. According to the official Khronos spec, this technically requires a 4.2 context and never should have worked.
I propose to drop this and just throw a device unsupported error if GL_ARB_shader_image_load_store or GL_ARB_shader_image_size are not supported.
Or just add an option as hack to bump shader version tag to 420 or 430 which fixes the issue with 0 change to the if statements.
That would work but relies on driver behavior that is not explicitly defined by the specification. The proper fix would be the bump the context version to 4.2. I don't see any reason against this, as the emulator uses different paths to initialize desktop OpenGL and ES.
I propose to drop this and just throw a device unsupported error if GL_ARB_shader_image_load_store or GL_ARB_shader_image_size are not supported.
Or just add an option as hack to bump shader version tag to 420 or 430 which fixes the issue with 0 change to the if statements.
That appears to require a 4.2/4.3 context as well (which I'm not against, given the sorry state of macOS these days)
I propose to drop this and just throw a device unsupported error if GL_ARB_shader_image_load_store or GL_ARB_shader_image_size are not supported.
Or just add an option as hack to bump shader version tag to 420 or 430 which fixes the issue with 0 change to the if statements.
That appears to require a 4.2/4.3 context as well (which I'm not against, given the sorry state of macOS these days)
Bumping the context could also allow for further improvements to the OpenGL backend, biggest of which is ARB_direct_state_access imo
@xperia64 I'm not seeing Shadow might not be able to render because of unsupported OpenGL extensions.
warning on logs with older drivers, so it definitely seems to be have been supported. There are other places we check for the extensions to populate the uniform, so shadow would've been lost before this change. https://github.com/citra-emu/citra/blob/master/src/video_core/renderer_opengl/gl_rasterizer.cpp#L58
According to the official Khronos spec, this technically requires a 4.2 context and never should have worked.
As far as I understand extensions can be used on old opengl contexts too, we use GL_ARB_get_program_binary introduced in 4.1-ish for shader cache.
As far as I understand extensions can be used on old opengl contexts too, we use GL_ARB_get_program_binary introduced in 4.1-ish for shader cache.
Extensions appear to have version requirements too, and get_program_binary as an extension calls out 3.0 as a requirement, while image_size calls out 4.2
I see, i wonder why they and other vendors support it then, just a quality of life feature? (i can understand nvidia because they like to make their own spec.)
I'll tag it to canary for now, while we contemplate dropping macos support.
I test it in 10 games on canary 2217, it work fine, but the emulator random stops responding for 1-2 seconds. Perhaps this is due to the compilation of shaders, but even in warioware this happens.
And i have slideshow if use 4x+ resolution in MGS3, the RAM value jumps back and forth 2-8 gigabytes. In 3x native everything is fine and use only 840MB of RAM are occupied.
In resident evil mercenaries 3D, i have fullspeed in 9x resolution. Windows 11 Pro x64 21H2 AMD Ryzen 5 3600 4.2 Ghz MSI Radeon VEGA 64 8 Gb HBM2 2x8 Gb DDR4 3200
Untagged, conflicts with #6103