Update to upstream #127
Update to upstream #127
Conversation
… (#6925) * sw_framebuffer: Take factors into account for min/max blending * renderer_gl: Take factors into account for min/max blending * Address review comments * gl_shader_gen: Fix frambuffer fetch on qcom and mali * renderer_opengl: Add fallback path for mesa * gl_shader_gen: Avoid emitting blend emulation if minmax_factor is present
* renderer_gl: Use explicit bindings * gl_state: Match shadow order with vulkan
* video_core: Use epsilons for clip planes * video_core: Add comments
* gles: reorder framebuffer fetch extension directives * Address review comments
* code: Prepare frontend for vulkan support * citra_qt: Add vulkan options to the GUI * vk_instance: Collect tooling info * renderer_vulkan: Add vulkan backend * qt: Fix fullscreen and resize issues on macOS. (#47) * qt: Fix bugged macOS full screen transition. * renderer/vulkan: Fix swapchain recreation destroying in-use semaphore. * renderer/vulkan: Make gl_Position invariant. (#48) This fixes an issue with black artifacts in Pokemon games on Apple GPUs. If the vertex calculations differ slightly between render passes, it can cause parts of model faces to fail depth test. * vk_renderpass_cache: Bump pixel format count * android: Custom driver code * vk_instance: Set moltenvk configuration * rasterizer_cache: Proper surface unregister * citra_qt: Fix invalid characters * vk_rasterizer: Correct special unbind * android: Allow async presentation toggle * vk_graphics_pipeline: Fix async shader compilation * We were actually waiting for the pipelines regardless of the setting, oops * vk_rasterizer: More robust attribute loading * android: Move PollEvents to OpenGL window * Vulkan does not need this and it causes problems * vk_instance: Enable robust buffer access * Improves stability on mali devices * vk_renderpass_cache: Bring back renderpass flushing * externals: Update vulkan-headers * gl_rasterizer: Separable shaders for everyone * vk_blit_helper: Corect depth to color convertion * renderer_vulkan: Implement reinterpretation with copy * Allows reinterpreteration with simply copy on AMD * vk_graphics_pipeline: Only fast compile if no shaders are pending * With this shaders weren't being compiled in parallel * vk_swapchain: Ensure vsync doesn't lock framerate * vk_present_window: Match guest swapchain size to vulkan image count * Less latency and fixes crashes that were caused by images being deleted before free * vk_instance: Blacklist VK_EXT_pipeline_creation_cache_control with nvidia gpus * Resolves crashes when async shader compilation is enabled * vk_rasterizer: Bump async threshold to 6 * Many games have fullscreen quads with 6 vertices. Fixes pokemon textures missing with async shaders * android: More robust surface recreation * renderer_vulkan: Fix dynamic state being lost * vk_pipeline_cache: Skip cache save when no pipeline cache exists * This is the cache when loading a save state * sdl: Fix surface initialization on macOS. (#49) * sdl: Fix surface initialization on macOS. * sdl: Fix render window events not being handled under Vulkan. * renderer/vulkan: Fix binding/unbinding of shadow rendering buffer. * vk_stream_buffer: Respect non coherent access alignment * Required by nvidia GPUs on MacOS * renderer/vulkan: Support VK_EXT_fragment_shader_interlock for shadow rendering. (#51) * renderer_vulkan: Port some recent shader fixes * vk_pipeline_cache: Improve shadow detection * vk_swapchain: Add missing check * renderer_vulkan: Fix hybrid screen * Revert "gl_rasterizer: Separable shaders for everyone" Causes crashes on mali GPUs, will need separate PR This reverts commit d22d556. * renderer_vulkan: Fix flipped screenshot --------- Co-authored-by: Steveice10 <1269164+Steveice10@users.noreply.github.com>
* vk_platform: Check if library was loaded * pica_to_vk: Dont crash on unknow blend equation
…g it (#6982) Co-authored-by: Vitor K <vitor-kiguchi@hotmail.com>
* build: Fix compiling citra-qt for iOS. * Update src/citra_qt/configuration/configure_general.cpp Co-authored-by: Tobias <thm.frey@gmail.com> --------- Co-authored-by: Tobias <thm.frey@gmail.com>
…ionActivity intent (#6996)
* gsp: Downgrade StoreDataCache log to trace. * gsp: Mark StoreDataCache parameters as maybe_unused
…E:Fates Symbols (#6995)
I definitely disagree here, the old core is not available for any apple platform and I don't think getting it working on Mac should hold up making the new version available on the other platforms. |
|
@warmenhoven doesn't it already work on Mac and Linux? It's just Windows and Android that were having issues with this build, no? Those two are probably the highest priority OS-es |
|
Not Mac. There is currently no citra core for Mac, and this PR does not create it on its own. |
|
You can check windows build |
Ah, wasn't aware of Mac being a non target. I don't use Mac for gaming. Apologies for the confusion. Now that Windows build exists, Android still remains ig? |
Tried it but it crashes RetroArch on windows |
I tried too but retroarch not load the core. |
There is only one thing, that I want say to you - FUCK YOU (try to do something, but not complain) |
|
Thanks. You too 😊 And also, thank you for your hard work on this ticket. It was very exciting for me to see progress on the Citra core after so long, so I definitely appreciate your effort and initiative in this PR. I understand you've been doing this on your free time out of the kindness of your heart and no one's paying you for this. Not everyone has the grit and expertise required for such a Herculean task. If I've offended you in any way, I sincerely apologize and I hope you can have it in your heart to forgive and move on. One thing we tend to forget is the person on the other side of the screen, and the diverse lives they live and the different circumstances they may be facing. I wish you the best of luck going forward for this issue and with your career, and I hope the RetroArch project keeps thriving as it always has been. Peace~ and happy holidays to all. 🎉 |
|
I was able to get this PR to compile on Mac using basically the same build script as is used for Linux (the shared library extension is |
|
Vulkan support is broken now but need a little work I think. Unfortunately I am not a specialist in rendering.
No, just was drunk and aggried to "do not merge it till everything in the world will be fine" 😄 |
|
Ok, just to clarify, I didn't mean everything in the world when I said "everything". I meant we need to make sure it at least builds for and runs games on the two major platforms for gaming - Windows and Android. I use neither (Linux/iOS only) but I was assuming that most people who use Libretro would be on one of those. Now, when I said that, in that moment I forgot how git works. My suggestion was scope creep. This ticket is just for updating to latest Citra. We can create separate tickets to ensure that it works on different platforms, which I remembered later. So yeah, if things build and run on Linux (or whatever OS you're on) then that's fine for this ticket I suppose. That's why right after that I suggested merging ASAP so we can move on to debugging specific platforms in their own tickets. Whatever the case, we do need to eventually ensure it works on Android and Windows, since a lot of retro emulation devices use those systems like Retroid, Anbernic, AYN, etc. (and now Asus ROG, Lenovo, etc.) That's all I was suggesting. As for me not contributing more significantly:
Anyway, now I'm done with my co-op and can test on these platforms:
|
It is not matter. Yes, sometimes LbretroAdmin appears with inarticulate "is this meargable" and goes to the sunset. |
Is there anything else left to do for this PR? If not, my suggestion would be to try contacting LibretroAdmin directly and officially asking them to merge this PR. There's a chance they think there's still something left to do here and were waiting on you to explicitly contact them first; you never know. :) |
|
There is no personal messages in github. |
|
@zorn-v I just posted about this in the Libretro discord |
|
Just for information (I may be wrong) - emu creators don't like to be "another core" (donations etc.) |
|
@zorn-v sorry I didn't understand what you meant. I talked about it in the libretro discord since the mods over there usually help with cases like this since at least some of them have merge permissions |
|
Needed to develop some sort of donations in libretro I think |
I mean developers of emulators are sabotaged any integration 😄 |
|
Yeah, it may be just refactoring, but why now ? |
|
Sorry for not having seen this before. You can always contact us on Discord (send a friend request to BoardsOfCanada on the libretro discord, or talk to hunterk in DM who can point you to me). I will hit the merge button on this. |
|
Just for clarification, is it proven this PR works on Windows, Linux and the platforms we have builds for? If not we will have to revert. |
|
It does not build on the buildbot so I unfortunately have to revert it. While I appreciate the attempt to try to rebase, it needs to be better than the core that already exists, it needs to build and it needs to compile on our buildbot. https://git.libretro.com/libretro/citra/-/jobs/4672105 Reverting this for now. You can submit a new PR that does work but I suspect more testing and manual labor is needed here on the end of the PR submitter. |
|
In case it helps, here is a pipeline of the current build (before your PR) which does build correctly - https://git.libretro.com/libretro/citra/-/pipelines/246081 Maybe it will help you ensure that things build correctly with whatever new PR you make. But again, I need to stress that the core should be better or equal to the core that already exists, and should not be a plain regression on the platforms that we already cover. |
|
Taking a very quick look at getting this working on the buildbot: https://github.com/warmenhoven/citra/tree/warmenhoven/dev/rebase It looks like cryptopp requires cmake 3.20 but the buildbot only has 3.18 (actually one of the builders only has 3.10 but there's a straightforward workaround for that). |
|
Can we have a scenario where the docker supports both cmake 3.20 and 3.18 but without too much extra disk space being used? |
Currently I am stuck at point where
emu_instance->hw_render.get_proc_address('glGetString')returns NULLHere https://github.com/zorn-v/citra-libretro/blob/a2c75ccbc82adbd00bc3256b15315a2f4bffda42/src/citra_libretro/citra_libretro.cpp#L615
Any ideas ?