Crtl-lottes-multipass in GLSL format?

RetroArch Additions Shaders
#1

Hi,

I’ve using for a while the crt-lottes shader, but noticed frame dropping from time to time. I’ve read about its multipass version and decided to use it but it seems it doesn’t work. After looking at it, I’ve noticed that its GLSL version is missing files inside the shaders/crt-lottes-multipass folder; it only has a linearize.glsl file. I guess that’s due to the cg2glsl.py script since it’s incapable to reference some variable that I guess they come from the previous pass.

Is it possible to have a GLSL version of it? Thanks.

#2

It should normally get converted automatically but something must be causing the script to fail. I’ll have to look into it. However, this might be a good test for our vulkan-to-GLSL conversion plan. Either way, I’ll see what I can come up with.

#3

Hi ! +1 :slight_smile: I actually need it too ! Thanks a lot ! :slight_smile: I didn’t manage to convert it but I am a bit clueless on this subject.

“1 shaders converted successfully. 10 shaders failed.”

For instance, when converting crt-lottes-multipass.glsl I get : "CGC: <stdin>(158) : error C1008: undefined variable “PASSPREV1”

#4

Actually, there are quite a few shaders which cannot be converted and trigger error with cg2glsl. crt-multipass-glsl is an example but there are others (crt-multipass-hyllian for instance). A dozen or so.

#5

I also found that a lot of GLSL shaders (I primarily tested the CRT ones and FXAA) simply don’t work. Does it make sense to open a bug report on those? Is it possible to test loading of these shaders somehow so that broken shaders don’t even get distributed?

#6

The problem is that some of them work some places but not others. All of the ones in my repo have been tested against my laptop but some of them look weird or even fail on some mobile GPUs. So, we would have to test all of them on all platforms (and all devices, for that matter) to find out which ones needed which fixes.

We hope to be able to use SPIR-V reflection to auto-convert the vulkan shaders to whatever lower version of GLSL we want, supposedly with better reliability than our admittedly janky python script that we currently use. No ETA on that, though, unfortunately.

#7

Hi ! Okay, thanks thanks for your reply !

Do I understand correctly : there are hlsl shaders (direct3D stuff ?), cg shaders (nvidia, can be converted), glsl shaders and now vulkan shaders as well ? It’s probably trivial but it’s not mentioned in the wiki :slight_smile: Maybe I should help add things I figured out to the wiki, as I represent “dumb users” :slight_smile:

Meanwhile, I almost solved my issue. I needed crt-lottes-multipass due to a slight lack of performance : I had framedrops (with dbl buffering, xbr + lottes). Now that I added a second RAM module (dual channel) it’s much better in several emulation cores (not all though, a tiny bit of speed is missing so it’s not solved yet). Maybe it’ll get automatically solved with vulkan driver is added to lakka.

It seems cg2glsl doesn’t play along well with multipass shaders. (getting some undefined variables errors). Do you think I could fix it or is it too complicated (as the same shader works in its regular version it must be a superficial issue I guess) ? I used to be a developer 10 years ago or so but never touched opengl stuff / shaders and didn’t touch a single line of code since then :wink:

Thanks again :wink:

PS : I just read on phoronix Intel pushed some new Skylake Vulkan drivers with a big performance boost. So there are several areas of potential performance improvements :slight_smile:

#8

The script has issues with multipass shaders that reference a specific previous pass (that’s what the passprev* variables mean), as well as dropping parameters (this one’s impossible to fix because of how parameters are defined) and failing to copy over LUTs. There may be other issues, too.

The script would need to be modified such that when it sees “passprev-whatever” it spits out the GLSL-compatible syntax. If you’re up to that sort of task, you’re welcome to take a stab at it.

We have Cg shaders and that language is so very close to HLSL that many Cg shaders can be compiled as HLSL with no changes; we have GLSL shaders that include compatibility ifdefs to work with GLES and desktop GL of various levels; and we have the vulkan context’s slang shaders, which are written in GLSL 4.5 but get reflected back to vulkan-native SPIR-V at compile-time.

#9

Hm, okay. I guess things to do with graphics drivers remain hairy. By the way, why can’t Cg shaders be used in OpenGL contexts?

#10

Same reason you can’t use GLSL shaders in a D3D context. It’s an entirely different pipeline.

#11

Hmm, I’m not sure I’m capable of fixing such a complicated shader so that it gets converted properly. If there was a bounty or something I’d contribute :wink:

Back to my performance issues. I made further tests and got really strange results : always using this xbl level 2 fast scaled x3 + crt lottes combinations (Skylake NUC / Lakka / KMS / OpenGL).

  • With double buffering enabled, all FBA games run at 100%, but PSX, NES, Megadrive games are slow (SNES and PCE run at 100%)
  • With triple buffering enabled, everything runs at 100%
  • With triple buffering enabled + a huge (like 12 !) frame_delay, everything runs at 100% !!
  • With double buffering enabled + a tiny (1 or 2) frame_delay, even some FBA games crawl (the games that used to crawl with double buffering when I had only 1 module of RAM, BTW)

How is it possible that a huge frame delay has less consequence than using double buffering ? Theoretically, such a big frame delay means frames have to be calculated in a much smaller amount of time ; while double buffering just needs a consistent calculation time compared to triple buffering (but not necessarily faster performance, if I understood properly).

Overall, I can get a super low input lag by NOT using CRT-lottes as I can have both double buffering and a big frame_delay. But it looks soooo great along with xbr level 2 :slight_smile: So my current compromise is triple buffering + huge frame_delay.

Interesting anyway… :slight_smile:

Edit : even with frame_delay 13 (14 in some cases) it’s still fast (except PSX which needs 10). Makes no sense to me !

#12

Inconsistent frame-times is one of OpenGL’s many shortcomings, actually, and it’s one of the things that’s most improved by Vulkan.