[garbear]

New build works great and it looks like on LE12 all the visual glitches are fixed around shaders.

 

I've tested the Windows build and it seems that my blind changes to the DirectX version don't break anything. The bugs #5 and #8 seem to be fixed on Windows as well.

OK, well Windows shaders were only not merged because of shader file syncing. And now we have working Windows and LibreELEC shaders? Too bad shader file sync is still stopping us from merge.

IMHO updating the shader folder from time to time with the release of the new version of the add-on should be fine.

A solution? Sync the files manually in the git repo between releases!

@garbear Please note that there are still known issues and many multipass shaders are not rendered correctly when compared to RetroArch.

That's what "Known Issues" are for. You can see I updated the release notes. Anything that's unready with problems is just something that's ready with known issues.

One of the things the team has decided is, if a feature is complete for one platform, it can simply go in and not worry about other platforms. Are we at this point with shaders?

[KOPRajs]

One of the things the team has decided is, if a feature is complete for one platform, it can simply go in and not worry about other platforms. Are we at this point with shaders?

No, actually the single pass shaders are now working on every platform (OpenGL, OpenGL ES and DirectX) with no side effects or GUI issues.
On Windows some of the multipass shaders seem to work better, but shaders with LUTs are not.
In OpenGL/GLES shaders with LUTs now works better and multipass shaders also works better then before, but there are still issues in the multipass rendering pipeline.

I can't do much for the Windows part, but I haven't finished with the GL/GLES yet.

I've updated the WIP patch yesterday, but there is still something missing to get the multipass shaders fully working:
https://github.com/KOPRajs/xbmc/commits/...haders-v4/

This is not a single issue to solve, the whole rendering chain for multipass shaders seems broken on several places:

It starts with the creation of the FBO textures for every shader pass here: https://github.com/KOPRajs/xbmc/blob/8c0...L.cpp#L223
There are parameters read from the preset (type, format, scale, wrap and filtering of the destination framebuffer) being determined, but then they are being passed to an empty CGLTexture object and they are never being used: https://github.com/KOPRajs/xbmc/blob/8c0...L.cpp#L296
The texture is not even created here, instead it is created in CreateFBO() here: https://github.com/KOPRajs/xbmc/blob/8c0...GL.cpp#L16
The textures for all passes are given the same parameters regardless of what is read from the shader preset file (width and height are simply set to the screen resolution for every pass, filtering to GL_NEAREST, texture format to GL_RGB).
Even if the parameters were used, they are computed wrong. According to the source of RetroArch some of the parameters should be read from the next pass, not the current one (e.g. filtering and wrap type).
When fixing this, I've also done the TODO mentioned here (https://github.com/KOPRajs/xbmc/blob/8c0...L.cpp#L144) and I have removed the last shader texture, because the last pass is rendered directly to the backbuffer, so there is no need to create a framebuffer for it. So now there is no framebuffer and no textures created at all for the single pass shaders.
But we are still missing something and the render seems blurry compared to RetroArch.

[garbear]

One of the things the team has decided is, if a feature is complete for one platform, it can simply go in and not worry about other platforms. Are we at this point with shaders?

No, actually the single pass shaders are now working on every platform (OpenGL, OpenGL ES and DirectX) with no side effects or GUI issues.

I love seeing the progress so far. I'm just wondering at what point we open a YOLO PR for shaders. Kodi has a high bar on quality, a low bar on completeness. There's no downside to upstreaming all the shader work, as we can still do whatever fixes/improvements we want but far more v22 users get to experiment with shaders. And not gonna lie, I've kept 5K lines rebased on master for 7 years. I'd love to see the work merged to reduce my technical debt liability. 5K lines merged is 5K lines less I maintain (which is currently about an hour a month I need to rebase).

[KOPRajs]

Kodi has a high bar on quality, a low bar on completeness. There's no downside to upstreaming all the shader work, as we can still do whatever fixes/improvements we want but far more v22 users get to experiment with shaders.

I agree, but I'd still like to try to fix the multipass shader rendering issue before the merge and it would be nice to update the GUI, so we can get a more complete experience. I'd also expect that the code will need some clean up before merging and we are probably going to see bug reports regarding different GL/GLES feature level support on variety of hardware (I've seen a lot of ifdefs regarding iOS etc. when browsing the RetroArch code).

[KOPRajs]

But we are still missing something and the render seems blurry compared to RetroArch.

Fixed in updated 4093d7e by setting the source texture filtering for the first shader pass as requested by the preset.

@garbear Can you please try to create a Windows build from the current version of https://github.com/KOPRajs/xbmc/tree/video-shaders-v4 tree? I have done changes to the DirectX code again, so it needs to be tested.

EDIT: In the last commit I've cleaned up the CShaderPresetGL::RenderUpdate() and CShaderPresetDX::RenderUpdate(). If it works in Windows and if no other changes will be needed to fix the remaining issues, this function should be moved to the common parent as it is now 100% the same for both platforms.

[OmniBlade]

Just installed the x86_64 libreelec test build and it appears I can no longer browse into zip files on emulators that support the vfs such as snes9x but it also doesn't treat them as launchable for emulators that can launch zips directly.

[garbear]

@garbear Can you please try to create a Windows build from the current version of https://github.com/KOPRajs/xbmc/tree/video-shaders-v4 tree? I have done changes to the DirectX code again, so it needs to be tested.

I'll do builds when I get a chance! Just force push to your branch and I'll grab the latest for each round of builds.

Just installed the x86_64 libreelec test build and it appears I can no longer browse into zip files on emulators that support the vfs such as snes9x but it also doesn't treat them as launchable for emulators that can launch zips directly.

 When I get a chance I'll try to repro.

[garbear]

I'll do builds when I get a chance! Just force push to your branch and I'll grab the latest for each round of builds.

I'm doing builds now. Less commits makes it easier, and the PR is gonna require commit organization, so I hope you're familiar with interactive rebase

[garbear]

Test builds are up! https://github.com/garbear/xbmc/releases...1-20240502

[sunlollyking]

@KOPRajs - Just tested Garbears new builds couple questions.

I can't seem to add new shaders although i'm guessing it's because they're multipass so they currently just show as black - I tested CRT-Royale and added in the xml descriptor.
My other question is once we have the ability to add them what do the name and category number values actually point to ? Is there a table pointing to what the descriptor would be ?

 <preset>
        <path>libretro/glsl/crt/crt-royale.glslp</path>
        <!-- CRT Display -->
        <category>30004</category>
        <!-- CRT Royale -->
        <name>30011</name>
    </preset>

I kept the same category: CRT - and then picked a random number for name and it seemed to then point to an NTSC filter. 

Outside of that on LE12 build works great, all the bugs fixed before haven't regressed it's just these trickier shaders that still don't work. Great work!

[KOPRajs]

Is there a table pointing to what the descriptor would be?

It is a reference to a translated string. You can edit the strings in /storage/.kodi/addons/game.shader.presets/resources/language/.../strings.po file.
Since I would like to see a possibility to dynamically add video filters to the list by browsing files, I've proposed to remove these translated strings for every shader preset and replace them with the filenames in the future.

 

I can't seem to add new shaders although i'm guessing it's because they're multipass so they currently just show as black.

While there are still issues with the more complex presets, there should be a lot of working multipass shaders already.

You can try some of these:
anti-aliasing/advanced-aa.glslp - 2 pass aliasing shader, tested to render 100% the same as in RetroArch in the latest version
crt/crt-geom.glslp - 1 pass CRT shader
crt/crt-easymode.glslp - 1 pass CRT shader
crt/crt-lottes.glslp - 1 pass CRT shader
eagle/super-eagle.glslp - 2 pass scaling shader
scalenx/scale2x.glslp - 2 pass scaling shader
scalenx/scale2xplus.glslp - 2 pass scaling shader
xbrz/xbrz-freescale.glslp - 1 pass scaling shader
xbrz/4xbrz-linear.glslp - 2 pass scaling shader

Some of them are low demanding (suitable for low performance ARM devices), while others make miracles on powerful hardware.

[KOPRajs]

Test builds are up! https://github.com/garbear/xbmc/releases...1-20240502

Unfortunately, it turned out that I've created a new issue in the Windows build (just try any multipass filter, e.g., Super Eagle from the default selection). So I needed to install MS Visual Studio after all to solve the issue. I've amended the last commit with the fix.

[garbear]

New builds for the updated branch now available for Windows. Other platforms are marked "Request a build in the test thread".

@KOPRajs Should I remove "Many multipass shaders are not rendered correctly" from the release notes?

[garbear]

I did a new round of builds after fixing remotes in Android. Builds are on github: https://github.com/garbear/xbmc/releases

[mollyrocco]

hi i would like to add some games to kodi 21 , is there a dummies guide for me to look at many thanks