[BUG]: Graphical artifacts when running at an Internal Resolution higher than 1x Native

[matheuswillder]

Describe the Bug

The bug report template states that issues related to upscaling are not being accepted at this time, however, since this occurs specifically in the PCEE2 core only and not in standalone PCSX2, I decided to go ahead and file it, as it seems something coming from the PCEE2 core side. Please feel free to close this issue if it is irrelevant, no hard feelings.

As the title says, when running any game at an Internal Resolution higher than 1x Native, the game runs without performance issues, but exhibits graphical artifacts that do not occur in PCSX2. Recordings below.

Reproduction Steps

With the core with the default settings, open any game, go to Core Options>Graphics>Internal Resolution, and change it from 1x Native to anything higher (e.g., 3x Native). The changes take effect on the fly, but I only noticed the issue after closing the game and opening it again, from that point on, any game (including even the BIOS intro) exhibits the same graphical artifacts seen in the recording below.

Expected Behavior

Game runs without graphical artifacts, even at a higher Internal Resolution, just like the standalone PCSX2 does.

PCSX2 Revision

v2.7.523

Operating System

Linux (64bit) - Specify distro below

If Linux - Specify Distro

Debian

CPU

AMD 5 8600G

GPU

AMD Radeon 760M (iGPU)

GS Settings

Everything was at default settings, except for Internal Resolution, which is necessary to reproduce this issue.

Emulation Settings

Also, everything was at default settings, but changing options here didn't alter the result (such as enabling or disabling the "Skip BIOS" option, the issue then appears in the BIOS as well).

GS Window Screenshots

Recording (if the video doesn't load, right click on it>Save video as..., save it to some folder and open it with a local player):

PCEE2:

Gravacao.de.tela.de.2026-08-31.13-27-54.mp4

PCSX2:

Gravacao.de.tela.de.2026-08-31.14-02-53.mp4

Logs & Dumps

retroarch__2026_08_31__13_26_04.log

[matheuswillder]

Just to add a bit more information here: I was playing Gran Turismo 4 with the PCEE2 core Internal Resolution set to 1x Native, and I noticed that when changing the video output modes within the game settings, this same graphical issue appears. Recording:

Gravacao.de.tela.de.2026-09-01.13-05-48.mp4

I deleted my PCSX2 installation yesterday after switching to PCEE2, but I'm pretty sure that changing the video output doesn't cause those graphical artifacts in PCSX2. But I can reinstall and test it if that would be helpful, just let me know.

[WizzardSK]

Thanks for the detailed report, and for the videos.

Context on how the core upscales: Internal Resolution only sets PCSX2's upscale_multiplier — the GS itself is unmodified. What is core-specific is the present path: there is no window, so the GS renders into a backbuffer that the core sizes to the merged frame (expanded to the target aspect ratio) and hands to RetroArch as a Vulkan image, updating the frontend geometry with it. A change of the output size is the one thing that path reacts to, and that is exactly what changing Internal Resolution — or a game switching video output mode — does, so your two repro paths do point at the same place.

I could not reproduce it here yet: on a current build (Vulkan, RetroArch 1.22.2) Gran Turismo 3 renders cleanly at both 1x and 3x Native. Different GPU vendor than yours, so that rules nothing out.

Three things that would narrow it down:

1. Your log shows a shader preset auto-loaded for the core: Specific shader preset found at ".../config/PCEE2/Playstation 2.slangp". That preset runs after the core hands the frame over and rescales it with its own filter settings, so its behaviour changes when the source size changes — which is exactly when you see this. Could you retest with it removed (Quick Menu → Shaders → off)?
2. Could you post a still comparison of the same screen (e.g. the GT4 Screen Settings dialog, or a paused GTA III frame) from PCEE2 and from standalone PCSX2 at the same Internal Resolution? The two GTA III clips are of different moments, and that intro has heavy motion blur of its own — the standalone clip shows the same smear at 1x — so they are hard to compare directly.
3. Does it also happen with Renderer = OpenGL (Hardware)? That path hands the frame over by a texture blit instead of the Vulkan zero-copy image, so it separates "the GS renders it wrong" from "the present path hands it over wrong".

Also: after you set it back to 1x Native, do the artifacts disappear on a fresh start of the content, or do they persist there too?

[matheuswillder]

Hey, thanks for the reply and for working on this core!

1. I set that shader because I use a global shader for 2D content (NES, SNES, etc.) that doesn't look good with 3D content (PS2, GameCube, etc.). Unfortunately, disabling that shader or even loading any different one doesn't fix the issue.

2. I think it's quite hard to capture a still image for comparison of this issue because, as you can see in the videos above, it happens in a fraction of a second, it's as if the rendered area is constantly getting bigger and smaller, so just focus on the black borders in the videos above, all the rest of the content seems to be rendering correctly, as far as I can tell.

3. I tried now OpenGL as Renderer, and it fixed the issue! Recording and log below, no shader loaded, and Internal Resolution set to 1x Native then changed on the fly to 3x for testing.

Recording:

Gravacao.de.tela.de.2026-09-01.20-11-48.mp4

Log:

retroarch__2026_09_01__20_10_47.log

But after discovering today that Gran Turismo 4 suffers from this issue even at 1x Native on desktop, I checked on my Android device, and the issue is present there too using Vulkan as Renderer. The device is a Samsung Galaxy A55, which uses an AMD GPU customized by Samsung (known there as Xclipse GPU). Unfortunately, although using OpenGL as Renderer is an alternative to fix this issue on the desktop, it is not an option on my Android device, as Samsung's OpenGL drivers are known to be broken. So, if you have any other tips on what I could try or anything that might fix this issue using Vulkan as Renderer, I would be very grateful.

Edit: sorry, I typed the answer a little quickly (I'm very short on free time), so I ended up forgetting to answer some of your questions properly.

Also: after you set it back to 1x Native, do the artifacts disappear on a fresh start of the content, or do they persist there too?

Yes, when setting it back to 1x Native, the issue also disappear on a fresh start of the content.

Also, I tested on my Android and changing the screen options in Gran Turismo 3 does not cause this issue, I also tested it in San Andreas (brightness and widescreen option), this only occurs in Gran Turismo 4 when using 1x Native and changing the video output modes within the game settings, or in any game when changing the core Internal Resolution to anything above 1x Native.

If you don't have Gran Turismo 4 to test, perhaps you can try this by changing the video output settings in the BIOS settings? On Android, when loading the core, there is the "Start Core" option, which will start the BIOS without any game disc inserted and allow you to change the video output options. But I haven't tested this on desktop, I was looking for this option on the but it doesn't seems exist anymore, it seems to have been removed years ago (here: https://forums.libretro.com/t/solved-start-core-option-is-gone/23904).

[WizzardSK]

Thanks for filing it with the recordings and the log — that is what made it possible to get anywhere, and upscaling being off-limits in the template does not apply to something that only happens in this core.

What I have so far:

I could not reproduce it here. aarch64, Adreno/Turnip, Vulkan renderer, GT3 at 1x and 3x, recorded straight out of the core: both clean. So it is not the core mishandling every upscaled frame — either it is driver-specific (you are on RADV), or it needs the kind of effect the scene in your video uses.

One thing your log does show. In your standalone recording the status bar says 1920x1344 (3x) — GTA III outputs 640x448, so 3x is 1920x1344. This core announces 1920x1440 for the same frame, because the libretro present path expands the canvas to the target aspect ratio before handing it over. That means the picture is resampled twice — once by the core, 1344 to 1440, and again by RetroArch onto your screen — where standalone resamples once. I am testing a change that hands the frame over at its native size and lets RetroArch do the aspect correction. That is worth fixing either way, but I want to be honest: soft edges from a double resample are not obviously the same thing as the smearing in your video.

Two things that would isolate it, if you have the time:

1. The same scene three times: this core at 1x, this core at 3x, and standalone at 3x. Your standalone recording switches resolution partway through (it is at 3x early on and 1x by the cutscene), so the two videos as they stand do not line up on one scene, and the cutscene in the standalone clip has visible ghosting of its own at 1x.

2. At 3x in the core, set Core Options > Graphics > Deinterlacing to Off, and then to Weave (TFF). GTA III runs interlaced at 30fps and the trails in your frames look a lot like blend deinterlacing. If Off or Weave makes them go away, the present path is not the culprit and I should be looking at how the core picks the deinterlace mode instead.

No rush on either — I will keep testing the present-path change meanwhile.

[matheuswillder]

Okay, I have some good news: I discovered that DISABLING Settings>Video>Scaling>Integer Scale completely fixes the issue, even on the fly, I can just pause the game while it's running, disable the setting, and it goes away. Could you try enabling this option on your device/hardware, and then test any game by changing the Internal Resolution to see if it happens for you?

I used the artifact file generated from the latest commit for testing, and the problem is still present in it if Settings>Video>Scaling>Integer Scale is enabled.

Anyway, here are the tests you requested (with Settings>Video>Scaling>Integer Scale enabled and then disabled):

The same scene three times: this core at 1x, this core at 3x, and standalone at 3x. Your standalone recording switches resolution partway through (it is at 3x early on and 1x by the cutscene), so the two videos as they stand do not line up on one scene, and the cutscene in the standalone clip has visible ghosting of its own at 1x.

If the video doesn't load, right click on it>Save video as..., save it to some folder and open it with a local player.

Recording PCEE2, 1x Native: the problem is not present:

Gravacao.de.tela.de.2026-09-02.21-13-01.mp4

Recording PCEE2, 3x Native: the problem is present:

Gravacao.de.tela.de.2026-09-02.21-14-23.mp4

Recording PCEE2, Settings>Video>Scaling>Integer Scale set to disabled: the problem goes away:

Gravacao.de.tela.de.2026-09-02.21-15-42.mp4

Recording standalone PCSX2, 3x Native:

Gravacao.de.tela.de.2026-09-02.21-18-09.mp4

I don't code, I'm a bit dumb when it comes to that, but I can grasp a little of what's going on and what you explained earlier. As far as I can tell, the Dolphin core had a similar issue where problems arose when some content/game changed the internal resolution/aspect ratio or internal framerate mid-game, the standalone Dolphin would simply make the switch, whereas the Dolphin core would get stuck in the previous mode. It was fixed here: libretro/dolphin#419

What seems to be happening here is that the PCEE2 core with Settings>Video>Scaling>Integer Scale set to enabled appears to be switching between two upscaling resolutions, a higher one and a lower one, as I mentioned in the comment above, which causes the flickering (that I called "artifacts", English isn't my native language and I didn't think much when I spoke that way, I'm really sorry).

At 3x in the core, set Core Options > Graphics > Deinterlacing to Off, and then to Weave (TFF). GTA III runs interlaced at 30fps and the trails in your frames look a lot like blend deinterlacing. If Off or Weave makes them go away, the present path is not the culprit and I should be looking at how the core picks the deinterlace mode instead.

I cannot see the difference between this changes. But the GTAIII intro was a terrible choice to demonstrate the issue initially, GTAIII had trails even in the original PC launch itself so the game seems to be rendering correctly, but as I had mentioned I was wanting you to focus on the black bars/edges, but perhaps the way I phrased it didn't make it clear at first, again sorry for that.

Please let me know if you need any further testing. And before I go today, just one more thing: I know this core is being maintained separately from the Libretro infrastructure, but just so you're aware, Linux x64 builds stopped over a week ago, which is why I used the artifact generated by the latest commit. Android builds are still proceeding normally at regular intervals at buildbot.libretro.com.