ScaleFX x9 Crash Issue with Psx Beetle Core

[shinra358]

ScaleNX does a very nice job replicating xBRZ effects. But it only works perfect with 2D only games that don't have any stretched texturing going on. xBRZ actively scales any texture on the fly while scalenx does so after the fact causing some 3D elements to not look so good as if xBRZ was handling it. So I would like to ask for xBRZ up to 6 inside of this core. Thanks in advance.

[wingedonezero]

Xbrz is included already 2x to 6x. Should close this issue.

[hizzlekizzle]

I believe shinra358 was specifically requesting per-texture filtering, which I recently added (SABR and xBR), so yeah, closing.

[shinra358]

Makes no sense why this was closed. sabr and xbr is NOT xbrz. Mupen64plus has xbrz and I would like it for this as well.

Xbrz is NOT in this core at all.

[hizzlekizzle]

xBRZ is a CPU filter, we're using per-texture shaders. There is a port of xBRZ to shader but it's not efficient enough to run per-texture. SABR and xBR are the closest you're going to get from me, at least.

[shinra358]

as I said, the n64 core uses the cpu filter. sabr and xbr suck and are not the same and the xbrz shader you have is not real xbrz. Ive already tested this in your forums and compared it to real xbrz and scalefx. scalefx is 100% identical to the real xbrz while the xbrz shader is no where near it. Try yourself with the mario kart snes title screen, you'll see. And as I told you before, scalefx shader crashes the emu if your internal resolution is higher than x1. Therefore it would be best that the real cpu xbrz be implemented like it is on certain standalone psx emus. sabr and xbr aren't even in the same league.

[andres-asm]

the N64 core is a different core with different architecture hence the reason for it to have per-texture filters, this one has a shader pipeline so we implemented per-texture shaders.

You can't just copy-paste code from one codebase to another and hope for the best. XBR doesn't suck at all either, and without it XBRz would have never existed. You need a magnifying glass to tell one from the other.

[shinra358]

every core has a different architecture. so does every emu. yet in each standalone, xbrz is still implemented... fixing the crash from scalefx, then there would be no problem, issue, or concern. without this, there's no need to move from epsxe.

[andres-asm]

What crash? you're speaking of different things. Texture filtering like on PPSSPP and PeteOGL2 is not the same as the postprocessing passes we add at the frontend level.

If something's crashing then give us a log of the crash.

[shinra358]

I asked for xbrz because maybe if that's added then you guys maybe can fix the crash from using scalers when doing it. That is literally the only reason I'm asking for it for this core because scalefx crashes the emu when this core (both hardware and software) crash when using a resolution greater than x1 as I stated above.

Use scalefx x9 shader on either core in vulkan or opengl and set the internal resolution to greater than x1. There will be your crash. I don't even know why you're talking about texture filtering. Epsxe has xbrz.

[andres-asm]

What do you want? texture filtering? or postprocessing? You are still mixing up things.

I just tried beetle psx hw at 2x with scalenx (2xplus) and it's working fine.

[shinra358]

I clearly said scalefx x9 shader not 2xplus. I am not mixing anything up. scalefx and xbrz visually look the EXACT same as I stated above. I don't care how I get this effect whether cpu scale or postprocessing I just would like either one method to be implemented or one method to be fixed for this core.

[andres-asm]

Check the OP you said ScaleNX. You understand it's scaling at 9x right? do you even have enough VRAM for that?

We won't put any effort on cpu filters.

[shinra358]

i've asked for this to be fixed alot so excuse me if I thought I wrote that in this particular one. but scalefx stuff is in the scalenx thread on the forums so I was on the mindset that they were the same thing but upgraded. but the particular one in question is scalefx x9.

[andres-asm]

Even a GTX 970 runs out of registers with that shader at more than 1x. It's perfectly normal. It's too much for your GPU.

[shinra358]

but it only does this for these new cores that are coming out. It works fine for most of the retro game cores, and no crashes with the mupen n64 core (the only other core I use that has the ability to increase internal resolution). My gpu is a 980m. Processor is i7-4960x. I have 32gb of 1600ghz corsair vengeance ram. It works just fine on all the retro cores except some of them crash when using vulkan only. but this core crashes when using both vulkan and opengl so that can't be the reason for the crash. even the ppsspp core works fine with the shader.

[andres-asm]

Of course, the soft cores all render at small resolutions. It's running out of memory, that's all. It doesn't matter that you have 32GB RAM. The big framebuffer scaled 9x is too much for your GPU.

[andres-asm]

Try MAME with the alternate renderer, the same thing will happen since that uses a 1600x1200 framebuffer.

[andres-asm]

Wait what? you have a desktop CPU and a mobile GPU? what's this one of those desktop replacement laptops?

[shinra358]

but I'm using the hardware core. tried mame just now with the 2014, 2016, and one with no year on it. It works fine in vulkan with the scalefx x6 shader.

Yes, it is a desktop replacement laptop. Cost me 3200 bucks in 2012.

[andres-asm]

With the alternate renderer?

It doesn't matter if it's the HW core IT MAKES NO DIFFERENCE. I'm being very verbose with my explanations but it seems you don't want to listen/read

[shinra358]

i chose opengl and vulkan with mame. no crash.

mednafen virtualboy core does this too with vulkan. but not with opengl. seems like things from mednafen are having this issue.

[andres-asm]

I give up... you're not even trying to understand.

[shinra358]

you asked me a question. I answered it. You say xbrz can't go on because of the architecture, yet the xbrz code is right there open sourced.

So how are you going to say do this and it should crash too with scalefx x9. But it doesn't with what you told me to do yet still say I'm not trying to understand?

[shinra358]

why doesn't it crash when rez is x1 with scalefx is on. Yet it crashes on x2 when scalefx is on x1 instead of x6?

[andres-asm]

1. It doesn't crash here on a 970 with scalefx.glslp with the vulkan renderer at 4x IR
2. scalefx.glslp is already 3x so we're looking at 12x framebuffer size
3. at x9 I guess the number of passes makes it run out of registers or something like that. It works at 2x + scalefx (9x) on my gtx1080

[shinra358]

Please test with the specific shader that says scalefx x9. Also, shouldnt you be using the .slang for vulkan?

[andres-asm]

That was a typo, it was slangp, and I did that, I already said so in number 3

[shinra358]

so why does having scalefx x9 at x1 crash when internal rez is x2 or higher. Wouldn't x1 mean that scalefx wouldn't be doing anything?

[andres-asm]

scalefx x9 is NEVER 1x... it's nine x

[shinra358]

spookyfox said that it's really not x9 that's just something he named it. He gave an explaination but I don't remember what he said. But I was referring to it having options which let's you choose the multipliers inside of that shader.

[andres-asm]

I'm checking the passes, there re two 3x passes, and the rest are 1x... hence 9x. Just checked, there is no scale inside the shader...

Anyway, I'll let someone else take over I have spent too much time on this already.

[shinra358]

so I used the normal scalefx and set the rez to x4 via the internal rez settings in the core. In FFVI, it made the graphics look like you were looking through a stained glass church window. Not good at all. Then I switched game to ape escape, a 3D game. It crashed. Meanwhile, xbrz x6 works just fine in vbam, epsxe, pj64, mame, ppsspp and you're telling me that I'm supposed to buy that the normal scalefx crashing on just 4x internal core rez is because MY pc is not tough enough even though I play on 4k all the time and my card has 8gb of vram.....? That just doesn't make sense.

So tell me why it's impossible to implement xbrz in the core from open source xbrz code.

[andres-asm]

I didn't say your PC isn't "tough" enough for xbrz x6. Different filters / shaders have different demands. I didn't say it could not be done either. I said we're not interested in adding CPU filters. We have a very flexible shader pipeline there is no point on doing CPU filtering for us.

Regarding the crashes... well. It shouldn't crash. But since you haven't provided us with a trace or anything to work with, there is nothing we can do.

[shinra358]

what would you like me to give you. I've given stuff in other threads on the forum about it, tell me what you want me to give you.

[rz5]

So tell me why it's impossible to implement xbrz in the core from open source xbrz code.

@shinra358, let's write out some context for what you're asking, ok?

In the beginning, a wizard named Hyllian wrote a GPU program (a shader) in the Cg language, which took in a picture and scaled it according to his algorithm (xBR) - one that smooths out edges while taking in consideration the nature of 8/16-bit retro games (pixel art, low resolution, blocky when upscaled with nearest neighbor algo).

xBRZ is a modified version of xBR, originally written in C++ (a 'filter') by the author Zenju. Read more about the xBR family of scaling algorithms here: https://en.wikipedia.org/wiki/Pixel_art_scaling_algorithms#xBR_family

In RetroArch, available to you is a plethora of shaders that implement several xBR-family algos. Most, if not all of the xBR family are available to you in Cg format (including xBRZ, look at https://github.com/libretro/common-shaders/tree/master/xbrz). Some versions have been ported from Cg to slang and GLSL.

There is also a limited number of filters, of which 2xBR is one of them (look at https://github.com/libretro/RetroArch/tree/master/gfx/video_filters). But you should prefer shaders as opposed to filters, emulators in general rely on your CPU's horsepower and shaders run on your GPU.

If it's to filter all of the screen with xBRZ, load up the non HW version of beetle-psx and load e.g. the 6xbrz-linear.cgp shader preset.

If it's to filter only the 2D elements, then if you got to read the wikipedia entry, you know that "Super xBR+3D is a version with a 3D mask that only filters 2D elements".

If it's to filter each texture with xBRZ, it's not available yet. Per-texture filtering requires that the hardware renderer of an emulator be structured and written in a way that is extendable, which is fortunately the case in beetle-psx's HW renderers. simias, Twinaphex and hunterk hacked at it and the choices you have at the moment are the result.

So tell me why it's impossible to implement xbrz in the core from open source xbrz code. Quoting this again to end with the following: don't be afraid to get your hands dirty, don't be dissuaded because you don't know how to do it either. Like you said, it's open source, start by looking at what those 3 guys did to get the different texture filters inside the GL renderer of beetle-psx.

EDIT: At one point, xBRZ per-texture filtering was tested but it had terrible performance despite it looking very similar to xBR. https://github.com/hizzlekizzle/beetle-psx-libretro/commit/5ebfc1e8eca0d980fdb19b152cd57d4e2a4c6ffb

And in the future be careful of how you phrase your requests - the way you phrased your answers in this thread can be perceived as if you are entitled to have this to work...

[shinra358]

I mentioned earlier that i knew xbrz came from the xbr family. xbr in no way looks as good as xbrz/scalefx x9.

What I'm waiting on now is what fr500 wants me to give him so that I can do so.

[ghost]

EDIT: At one point, xBRZ per-texture filtering was tested but it had terrible performance despite it looking very similar to xBR. hizzlekizzle/beetle-psx-libretro@5ebfc1e

You didn't read .....

[shinra358]

would you stop derailing the fucking thread!? Obviously YOU didn't read when you can clearly read that I said that xbrz performance does well in other standalone emus. So if it has terrible performance, that means there's something in the program it's been junctioned to that makes the performance terrible.

now if you really want to be productive, then tell me what log I need to provide for the above request of fr500. Otherwise, stop making trouble to then tell me that I'm the one making the trouble. You remind of of that looney toons bulldog with the tiny one always following behind saying "let me at em, let me at em....."

We aint talking about xbrz right now if you were reading. we're talking about fixing the crash from a shader.

[rz5]

@shinra358 As it was described to me, the Cg versions of xBRZ (and by extention the GLSL version) are much slower than the xBR/SABR shaders because the author did a simple port, one that resembles the original C++ version line by line. The original is optimized for a multicore CPU; the Cg/GLSL versions are NOT optimized for modern GPUs.

About the crashes related to changing core options like the internal resolution and texture filtering: it's a known bug that, on Windows, beetle-psx-hw crashes when using the GL renderer and changing specific core options like internal resolution upscaling/texture filtering. If I had to guess what the bug is, it's about how the GL state is improperly cleaned and, as a consequence, rebuilt with errors.

I asked for xbrz because maybe if that's added then you guys maybe can fix the crash from using scalers when doing it.

If that were RE-added, the crashes wouldn't be fixed.

[andres-asm]

It's crashing for him with vulkan @shinra358 we need a stacktrace / backtrace of the crash.

That said, that fixes nothing related to XBRz.

[shinra358]

for this core, it crashes for me in vulkan and in opengl with each respective .slang and .cg versions when the internal rez is above x1. What's the cmdline options to create the logs? I don't remember.

i understand what you guys mean about changing the rez mid game. but when it crashes, the shader effects stick. so when I start up the game again, it will crash immediately because the settings from the crashed state remained the same.

So usually when I get said crash, I'd have to go in the cfg file and re-edit the core manually to be back on rez x1.

[shinra358]

<---save as and rename to rar.

I found something out. some of the crashes are do to loading the game through the xmb in vulkan for the older systems/cores. but when I load them directly, it doesnt crash!

rar contains: -mame both opengl and vulkan dont crash direct load nor xmb load

-beetle crashes regardless on opengl and vulkan if int rez is x2 or higher

-mednafen vb doesnt crash on opengl regardless but crashes when game is loaded through xmb but not when directly loaded when on vulkan

-.sega cd picodrive crashes on vulkan only when loaded through xmb. direct load is fine. and opengl is fine regardless

-mupen64plus is fine regardless and this was with high rez AND high rez texture pack.

-snes9x fine on opengl regardless. crashes on vulkan when loaded through xmb. doesn't crash on vulkan when game is loaded directly.

Wierd about the xmb thing. all with scalefx x9*

[shinra358]

So? I've given you logs. What can you say about it?

[shinra358]

So since there hasn't been any more responses, I took it upon myself to finally test the crashes that dealt with playing through the xmb. The newest version fixes that problem. VB nor the sega games I mentioned above no longer crash when starting through the xmb. So now only the psx scalefx+>1x resolution crashes remain.

So now I'm asking, if the program detects that too much whatever is being used, it can use the maximum allowed and display what it can at that maximum instead of downright crashing. I'm sure something that be done like that since no other thing crashes because of using a scaler filter but retroarch and this core.