[GSoC 2019] RetroPlayer: OpenGL back-end for shaders #114
Conversation
gusandrianos
force-pushed
the
retroplayer-shaders-gsoc19
branch
8 times, most recently
from
e4c7260 to
e6e3dab
Compare
gusandrianos
changed the title
|
@KostasAndrianos can you cherry-pick these 7 commits? 327d997~7...327d997 |
gusandrianos
force-pushed
the
retroplayer-shaders-gsoc19
branch
5 times, most recently
from
f5e103b to
def1361
Compare
|
|
||
| unsigned int numPasses = static_cast<unsigned int>(m_passes.size()); | ||
|
|
||
| for (unsigned shaderIdx = 0; shaderIdx < numPasses; ++shaderIdx) |
There was a problem hiding this comment.
Lines from here to 267 are copied as-is from D3D and should be moved to common code since they're not backend specific. Probably just a method with the passes as input and the scaled size as output.
There was a problem hiding this comment.
Yes, there's lots of places where common code can be factored out. The good news is duplication got us this far, and now these places are easy to find.
gusandrianos
force-pushed
the
retroplayer-shaders-gsoc19
branch
from
79b1e74 to
d23157e
Compare
| @@ -76,6 +85,8 @@ namespace RETRO | |||
|
|
|||
| virtual void Render(uint8_t alpha); | |||
|
|
|||
| std::map<CRenderBufferOpenGL*, std::unique_ptr<RenderBufferTextures>> m_RBTexturesMap; | |||
There was a problem hiding this comment.
Missing the header <memory>; added in gusandrianos#2
| if (it != m_RBTexturesMap.end()) | ||
| { | ||
| rbTextures = it->second.get(); | ||
| } else { |
There was a problem hiding this comment.
Style infraction; fixed in gusandrianos#2
gusandrianos
force-pushed
the
retroplayer-shaders-gsoc19
branch
from
e461396 to
db8f7fc
Compare
| namespace KODI | ||
| { | ||
| namespace RETRO | ||
| { | ||
| class CRenderContext; | ||
| class CRenderBufferOpenGL; |
There was a problem hiding this comment.
Alphabetize to reduce likelihood of git conflicts
garbear
force-pushed
the
feature_shaders_gl
branch
4 times, most recently
from
7d3fc5e to
7368539
Compare
garbear
force-pushed
the
feature_shaders_gl
branch
from
d58a368 to
b80fd1e
Compare
gusandrianos
force-pushed
the
retroplayer-shaders-gsoc19
branch
from
ecb8114 to
b8b6546
Compare
|
Ok, so I've got the GL environment back online and I've successfully built Kodi with the latest patches. Since it contains both the GL support and the Achievements, I need the game.libretro with API 5.0.0. Where do I find the latest sources? Also, might be worth to note that I needed to manually downgrade Flatbuffers. It seems that it was updated to 23.3.3 for Omega: xbmc@35be40d I was not able to build your current branch against it and I needed to downgrade it back to 2.0.0. |
I've found it here: https://github.com/kodi-game/game.libretro/tree/retroplayer-omega |
|
So, I've successfully runtime tested the latest patches for both GL and GLES and I've got the shaders working. No idea why it renders black on macOS for you. Can you please find out in which version it stopped working? While getting the GL environment back online, I've found out some unfinished work left in the local repo, so I'll try to finish this now and maybe I'll try to sync the rest of the shader code between DX and GL. |
If my branch is hard to build it's because I've backported over a hundred PRs to keep the work on top of the history able to be applied cleanly against Sadly, I wanted both v21 stability for my main build running the apartment, and zero technical debt for all the RetroPlayer work. That's lead to the nightmare of
Unfortunately I've only been working on macOS ARM since my workstation was in pieces on my floor needing a new CPU, which is basically since that November release, so I've never seen shaders work on macOS ARM. Luckily Kodi has a policy that broken platforms don't block working platforms.
Syncing the shader code is needed to open our shader PR, and is the last step before DX is ready to upstream. The bigger problem is syncing code between GL and GLES. xbmc#25207 broke our GL/GLES shaders instantly. I had to #ifdef a GLES texture into the GL code. That's right, GLES became dependency of all GL platforms! We clearly can't have that, and GL/GLES need to be refactored so that GL uses GL textures and GLES uses GLES textures. |
I'm not sure that the issue with Flatbuffers is related to your branch. It seems that the build script was updated with the new version of Flatbuffers (in master), but the savestates code in Kodi is not compatible with it. P. S. I started the work on the code clean up and syncing the DX and the GL files. For now I'm not sure what would be the best way to get rid of the GLES ifdefs. If we split the GL and GLES code, there is going to be a lot of duplicate code. It actually does not seem to be that bad with the ifdefs to me. |
I've been meticulous in backporting all flatbuffers stuff from master to my branch. Cleaning the repo and rebuilding from scratch could fix the problem.
Kodi has faced the problem in the past. We agreed that while duplicate code should be avoided, it's sometime beneficial to take on lots of duplicated code to focus on cleaning up architecture and achieving good code separation. Architecture is far more important than code duplication. |
|
I've done the clean up and the sync between DX and GL code: There are no real changes in the code apart from a few removed lines that were not in use, removed old comments, removed unused declaration created by the copy/paste from DX to GL etc. I've synced the headers and then sync the order of functions to match the headers, synced comments, white spaces etc. This time I've done proper testing in both Windows and Linux (GL/GLES). EDIT: Even when you look a hundred times, you always find another thing to fix just after you post the changes. I needed to amend the commit once more, sorry. |
|
Really nice cleanup. This is definitely needed, as shaders are still largely student code (absolutely no shade on students, they're just by definition learning the styles and abstractions used across the codebase). The more cleanup like this we do, the less work reviewers will have, and the quicker it'll be merged. I think the only big problem left is that we absolutely cannot do my hack when rebasing on xbmc#25207: --- a/xbmc/guilib/CMakeLists.txt
+++ b/xbmc/guilib/CMakeLists.txt
@@ -164,8 +164,10 @@ set(HEADERS DDSImage.h
XBTFReader.h)
if(TARGET ${APP_NAME_LC}::OpenGl OR TARGET ${APP_NAME_LC}::OpenGLES)
- list(APPEND SOURCES Shader.cpp)
- list(APPEND HEADERS Shader.h)
+ list(APPEND SOURCES Shader.cpp
+ TextureGLES.cpp)
+ list(APPEND HEADERS Shader.h
+ TextureGLES.h)
if(TARGET ${APP_NAME_LC}::OpenGl)
list(APPEND SOURCES GUIFontTTFGL.cpp
@@ -178,11 +180,9 @@ if(TARGET ${APP_NAME_LC}::OpenGl OR TARGET ${APP_NAME_LC}::OpenGLES)
if(TARGET ${APP_NAME_LC}::OpenGLES)
list(APPEND SOURCES GUIFontTTFGLES.cpp
- GUITextureGLES.cpp
- TextureGLES.cpp)
+ GUITextureGLES.cpp)
list(APPEND HEADERS GUIFontTTFGLES.h
- GUITextureGLES.h
- TextureGLES.h)
+ GUITextureGLES.h)
endif()
endif()That's the GL/GLES separation I was talking about. Once that's solved, we can start thinking about a PR. |
|
I'm not able to help with this. To be honest, I'm not a real developer myself, more like an older student. However, I can probably finish the left over work from last year, so expect a few more updates in the next days. Hopefully this time it is going to be something actually visible for the users. P. S. I've updated the clean up commit, so please make sure you'll get the latest version from the https://github.com/KOPRajs/xbmc/tree/retroplayer-21.1 branch. |
|
Cool, clean and fix away. As a future project I'll do the GL/GLES separation. Kodi v21.2 is going to be released in the next few days. When it's out I'll pull all your changes and do a 21.2 RP release. |
|
I've added another piece of the puzzle which brings us closer to full support of RA shader presets: The "Fix GLSL header and version" commit address 2 issues:
Relevant RA source part for comparing the logic can be found here: Supported GLSL version table can be found here: I've tested it on both GL and GLES and it seems to work fine. P. S. Sorry for adding yet another GLES ifdef, at least this one should be easy to split.
|
|
Nice! I just released all our work. https://github.com/garbear/xbmc/releases/tag/retroplayer-21.1-20250114 |
|
Why are the GL shaders disabled in the latest builds? Are you planning to upstream the DX shaders only? A year ago, when I started fixing the most visible bugs in the GL shader code, I've proposed a change in the video filters UI. It is at the end of this post and then several posts below there are even pictures and mockups. What do you think about the proposed change in the UI? I still believe it is needed and that it should be done before the PR, because it actually removes the translated strings for the shaders. I'm probably not able to do the new UI myself, but at least we should remove the translated strings and fallback to filenames. There are many shaders that actually doesn't have any name apart from the filename. P. S. Have you tested the latest changes on the macOS? |
We had a bug reported by a user that I see on my macbook, where textures get all messed up. Here's the report: https://forum.kodi.tv/showthread.php?tid=378606&pid=3222009#pid3222009 I reverted just shaders so we can see if it fixes the glitch to narrow it down to one of our commits. I'll post a screenshot below.
Good idea. We can check if this exists and use it, else fall back to the shipped XML in user add-ons, else fallback to the shipped XML in system add-ons.
I hesitate to make shaders editable in the UI. It adds a lot of UI complexity, vs plopping files into userdata and editing an XML file and having them automatically show up. The thing I appreciate most about the current dialog is how simple it is. UI code is expensive, XML code is cheap.
Agreed, getting rid of strings would be good. We could just show the filename without suffix.
I'll test it now. |
|
Shaders work on macOS now! Here's what happens with the glitch: When I browse shaders and return to the GUI, textures get messed up. Sometimes it's minor glitches 
Sometimes it's the whole UI 
The first image was after loading a shader or two, the second image was after I scrolled through all of them. I may or may not have seen this glitch after playing a game without showing any shaders, which would be a bug in the GL renderer. |
|
Ok, so first of all we need to know, if it is related to the shader support. Unfortunately, I'm not able to reproduce this on Linux. Second, we need to know what GL renderer is being used by the RP on your macOS: DMA, GL, GLES? Can you try to switch between GL and GLES build? |
Have you seen the mockup pictures? The dialog is still the same, we would only need to add a context menu and the Add button either to the context menu or re-use the design from savestates as shown on the picture. |
You're right, it's a manageable amount of UI work. I like the idea, it's pretty cool. |
|
I've added new changes. Please test these on the macOS, if you can. Apart from even more clean ups and minor fixes, we now have working sRGB framebuffer support on GL (I've tested it on cubic-gamma-correct.glslp and now I get the same output when compared to RA). In theory it should work on GLES3 as well (GLES2 is not supported), but I haven't found any shaders using sRGB and being compatible with the current state of support in RP, so I can't verify if it actually works for GLES. Here is a summary of known issues and features, that we are still missing:
Anyway, a lot of shaders are working for both DX and GL/GLES. When we hunt down the GUI corruption bug, we are IMHO ready for the merge. It would be nice to have the proposed UI update before the merge as well + the GL / GLES refactor and split. |
|
Nice, stellar progress! I did a new release with GL/GLES shaders enabled. I marked the one with them disabled as a test release, and linked to it for testers. The release includes all your work available at the time, which was up until Thanks for being so detailed in your summaries. I reference everything I can find when making presentations for the team! I'll give the commit a try on macOS. |
|
I've updated the summary a bit more. To be honest, I'm writing the summary primary for myself, so I don't forget already discovered issues, but it can serve as a starting point for anyone else trying to fix more shaders.
Does this version solve the GUI issue?
How about this? |
|
Sorry, I've been consumed with being Release Manager the last few days. I've broken so many things! Not to mention incurring extra server costs and breaking binary add-ons for all windows installs. Anyway, I'll try your latest branch on macos now. After 21.2 goes out today I'll do another release with your latest work. |
|
Shaders work great on macOS now. A couple are still black. The texture corruption still persists after using shaders. 
|
|
What API are you using? GL or GLES? Can you try switch between those and see if the corruption occurs on both of them? And how about the testing version without shaders? Does it solve the corruption? |
|
macOS uses GL. But keep in mind we #ifdef in GLES textures. I don't think I can run in GLES on macos. No corruption without shaders. |
|
I would be surprised if you can't build it for GLES on macOS. Just try to switch gl for gles upon configure and rebuild. |
|
macOS is a depends build and configure is done in EDIT: I think I found it. |
|
It seems that you are right and you really can't use GLES context on macOS. At least we know that the corruption occurs on the GL core profile. I've just noticed that your current builds are missing the xbmc#22211. Can you try to include it and then test the shaders on macOS? P. S. I'm currently trying to figure out how to implement the dynamic shader uniforms (number 2 and 3 from the TODO list above). It seems that we might need to change the logic and structure of the SetShaderParameters() again for both DX and GL because it is going to need access to the other shader passes. |
I'll give local VAOs a try again, but I now remember I removed it in 2022 hunting the same graphical glitch, which I got on my Intel macbook all the way back then. I remember the macOS glitch happening when games were played on my RetroPlayer branch, possibly without loading any shaders. It was only my branch (which had VAOs), not vanilla Kodi. At the end of the day, Apple's OpenGL is from like 2017, so this might be a bug that has to be hunted on a macbook.
I like the work you've done to unify GL and DX so far. Further refactoring is welcome, especially if slightly different architecture is needed. Ideally more of the stuff should be put behind an IInterface, which enforces sharing of logic. But that increases code size, so such abstraction isn't always worth it. We currently only have basic abstraction in the shader code, which is fine to upstream, but IMO more abstraction would make the code clearer by sharing some logic between the graphics APIs. |
|
I wanted to simply remove the DX specific functions from the GL code, before I started implementing changes needed for the frame uniforms (issue 2 and 3 from the TODO list), but I ended up doing another round of cleanups all around. The two new commits don't add anything for the user. If we are lucky, they don't break anything neither: Now I can finally try to implement something useful to get the remaining GLSL shaders working. EDIT: Tested on both DX and GL and it seems to working as expected. |
Description
This PR extends the functionality #86 brought to RetroPlayer by introducing support for other platforms through an OpenGL implementation.
The code in this PR is part of this GSoC project
In short, this code adds support for multi-pass shader presets, as defined in the libretro spec, which opens a whole new world of customization to the look and feel of games, through the massive amount of presets available in this format.
While the spec is written with cg shaders in mind, it is also extended to GLSL and slang shaders.
You can read more about the current state of my solution, what works and what doesn't(yet), here.
Motivation and Context
Shaders can be used to:
Of course, the list goes on. Most importantly, shaders can be used to elevate the gameplay experience and make it more immersive. A game can either look like it's being displayed on a CRT or a Gameboy or an LCD monitor or be upscaled and viewed on a 4K monitor, the possibilities are endless.
Regarding the commits in this PR.
I should mention that the last commit that falls under the GSoC umbrella is this one. Anything that follows it should not be considered as part of the GSoC project.
Let's give you some context about each commit.
The first three commits are setting up the relevant parts of code for usage in the next commit.
The fourth commit contains all the work that involves the processing and rendering of the shader presets.
The fifth commit connects the code to RetroPlayer.
How Has This Been Tested?
I took a brute force approach by testing almost every preset in the glsl-shaders repo. It has only been tested on Linux and it is unknown if it works on other platforms that use OpenGL.
To test this code yourself
game.shader.presetsbinary add-on/your/kodi/directory/addons/game.shader.presets/resources/libretro/glslShaderPresetsDefault.xmlin the resources directory with this file. This is a temporary workaround, I will update the add-on to choose the correct file depending on the situation.Screenshots (if appropriate):
Here's a video that demonstrates what these changes do.
Types of change
Checklist: