xBR algorithm tutorial

RetroArch Additions Shaders
#125

your guess was right, the reason why you can’t run the shader is that it requires a more recent GPU, due to the high register requirement of the shader in its current version, as you can see it in the error message. specifically, there are not enough registers available to store t8 and t9 in the vertex shader so that the fragment shader can use them. you only have 11 registers available per shader but xbr wants to use at least two more.

you could however move all the pre-calculations ( t0 to t9 at least ) from the vertex to the fragment shader, that way the compiler will hopefully be able to optimize register usage and run on your GPU.

EDIT : this is a modified version that should work for you: link

#126

thx a lot aliaspider. yeah it’s working now. what’s funny though that with d3d9 I got an distorded picture but it’s fine with ogl. with the xbr-lvl3-multipass shader it’s the other way around. don’t know what’s the reason for that, the log shows nothing wrong.

#127

All fixed on repo. Tks, aliaspider!

#128

It’s not working on my HTPC at all. It’s an AMD A-10 5700 with a Radeon HD7660D with latest 13.9 WHQL driver on Windows 8.1 pro 64bit (and latest RetroArch 64bit Version 20131013. OpenGL looks like Nearest, without filters. Sometimes vertikal lines, which are wrong. D3D9 have a shifted square in the down-left corner.

On my PC with GTX480 it looks fine with OpenGL (after the fix from aliaspider). Same problem with D3D9 like above. btw. lv3 and lv2 also not working on my AMD.

#129

Does it worked before the last two fixes?

Where did you get them? Directly from the repository or along Retroarch installation?

If you’ve got with Retroarch, then you’re using the old versions without the last fixes.

#130

I don’t have the old version anymore and can’t test (because you replaced with the fix). I took it from here: https://github.com/libretro/common-shad … -multipass The lv4 isn’t yet in the RetroArch package. lv3 and lv2 I tested from the RetroArch package (so I guess the old version). So it seems the old and the new versions don’t work with my AMD configuration.

#131

No idea what could be wrong. Are you loading the shaders through the cgc preset?

Try the cg2glsl.py script.

#132

I am loading xbr-mlv4.cgp All I can do is show you some screenshots: http://i.imagebanana.com/img/eovoripu/1.png Should be loaded correctly.

Thats the result in OpenGL: http://i.imagebanana.com/img/ijn6urap/2.png notice the tiny lines and dots in the logo

and DirectX: http://i.imagebanana.com/img/e2tqewyh/3.png

I don’t know what I have to do with cg2glsl.py.

#133

Change that default filter to nearest:

defaul filter --> nearest

And then click “Apply Shader Changes”.

#134

Don’t work. Same result like on the screenshots.

#135

Your only option is to use cg2glsl.py script to convert the shader.

Ask hunterk how to do this.

#136

cg2glsl.py can be annoying to setup in windows if you have never used a python shell before so you can have my already converted shaders to test

https://anonfiles.com/file/adb86144c5954ecb73000ab9f52ac24f

obviously glsl is only compatible with opengl so don’t even try directx. Works fine on linux with open source r600 driver so if they don’t work on windows it could be a driver compiler error. In any case give these a shot and report back. Also try using integer scale as this can sometimes solve annoying lines in opengl.

#137

Thank you for helping me! This looks much better: http://i.imagebanana.com/img/9jsx5ano/4.png

but there are still little lines, also with enabled integer scale (c at Micro or b at Turbo). Without Integer Scale much worse.

In my normal PC I don’t have these lines (with and without integer scale).

#138

need some help. I wanted to combine the xbr multipass shader (mlv4) with my newest mdapt version. it’s again a similar problem we already discussed here, but I don’t know how to solve it. the issue is, that besides the first passes are correctly configured for mdapt, the following xbr passes just ignores them and uses the original raw picture instead, so mdapt has no effect on the final result. it’s just weird, here is the cgp I used:

shaders = 8

shader0 = mdapt-pass1.cg
filter_linear0 = false
scale_type0 = source
scale0 = 1.0

shader1 = mdapt-pass2.cg
filter_linear1 = false
scale_type1 = source
scale1 = 1.0

shader2 = mdapt-pass3.cg
filter_linear2 = false
scale_type2 = source
scale2 = 1.0

shader3 = mdapt-pass4.cg
filter_linear3 = false
scale_type3 = source
scale3 = 1.0

shader4 = xbr-mlv4-pass1.cg
filter_linear4 = false
scale_type4 = source
scale4 = 1.0

shader5 = xbr-mlv4-pass2.cg
filter_linear5 = false
scale_type5 = source
scale5 = 1.0

shader6 = xbr-mlv4-pass3.cg
filter_linear6 = false
scale_type6 = source
scale6 = 2.0

shader7 = xbr-mlv4-pass4.cg
filter_linear7 = false
scale_type7 = source
scale7 = 2.0
#139

Sp00kyFox,

xBR passes 2, 3 and 4 need to access the original texture. As you're passing mdapt before it, the "new" original texture for these xbr passes is now the result of mdapt pass4, which is PASS4 according to the cg shader specs from maister.

So, you have to open xbr passes 2, 3 and 4 and replace all ORIG terms by PASS4 for it to run correctly.

BTW, this won’t be necessary when next RA releases, because maister has implemented the feature of accessing the previous pass output.

#140

that was an easy fix, thx!

#141

Is there a way to have a xBR shader that works at far less intensity? Maybe 25% or lower? Would this be the right place to ask?

#142

I’m not sure what you mean by ‘intensity’. Like, it’s too bright?

#143

The degree to which it is attempts to smooth pixilation. Right now the aim is perfectly smooth edges. What if, however, a xbr shader was made that tried to smooth pixilation by a mere fraction of what it currently attempts? That way it could be simply one minor effect and paired with other shaders. The attempt right now is to use xbr to create a perfectly smooth image alone by itself. But what I’d like to try is to have a far less intense xbr shader and to pair it with several others.

#144

you could use the xbr versions with lower levels or xbr-hybrid which is a combination of xbr and reverse-aa. otherwise I don’t think this is a trivial change according to the algorithm explanation by hyllian. xBR makes a binary decision whether a bunch of pixels are building an edge or not and if that’s the case then it will be interpolated. there is no strength parameter, only a similarity threshold (see annex1 in the first post of this thread).