Update Granblue Fantasy Relink for 2.0.2

[Hiyajomaho-num9]

I have fixed the following issues:

1. Refresh the game signatures and make scan failures safe.
2. Fix DLSS reset handling and sub-native scaling performance while keeping the Windows-only sources clean in upstream CI.

[Izueh]

just one questions, what are the _Win32 per-processor guards for?

[Hiyajomaho-num9]

just one questions, what are the _Win32 per-processor guards for?

I added them because the cpp-linter job runs on Ubuntu, and I was concerned it might fail while parsing the Windows-specific D3D11 sources. Upon further reflection, that was overly defensive and effectively excluded those files from linting, so I’ll remove the guards. Thanks for pointing this out.

[Jcarboo]

Have tested and reviewed the code, can confirm it works and is safe.

[Hiyajomaho-num9]

Have tested and reviewed the code, can confirm it works and is safe.

Thanks for testing and reviewing this PR.

My manual testing was mainly limited to:

1. Switching focus with Alt+Tab.
2. Switching between fullscreen and windowed modes.
3. Hot-switching DLSS models/presets and changing the render scale.

While testing the third case, I found the following issue. One sequence that reproduced it was:

1. Enable DLSS at a sub-native render scale.
2. Set Super Resolution to None.
3. Enable DLSS again.

After this sequence, Super Resolution could fail to resume correctly, while the frame rate dropped to approximately 24 FPS.

Further isolation showed that the underlying performance cliff was not caused by DLAA or by a particular DLSS model. It occurred at sub-native render scales: when SR was set to None or was suppressed, Luma was still intercepting the game's native Temporal Upscale (TUP) draw. This unnecessarily redirected and split GBFR's deferred command-list path, potentially serializing work that the game normally records in parallel.

I fixed this in the Temporal Upscale branch of Source/Games/Granblue Fantasy Relink/main.cpp by leaving the game's native draw and command-list scheduling untouched when no SR implementation should run for that frame:

if (device_data.sr_type == SR::Type::None || device_data.sr_suppressed)
{
   return DrawOrDispatchOverrideType::None;
}

When DLSS or FSR is active, Luma still replaces the native TUP path as intended. After applying this change, I repeated the same switching sequence and could no longer reproduce the 24 FPS performance drop.

[Izueh]

Have tested and reviewed the code, can confirm it works and is safe.

Thanks for testing and reviewing this PR.

My manual testing was mainly limited to:

1. Switching focus with `Alt+Tab`.

2. Switching between fullscreen and windowed modes.

3. Hot-switching DLSS models/presets and changing the render scale.

While testing the third case, I found the following issue. One sequence that reproduced it was:

1. Enable DLSS at a sub-native render scale.

2. Set Super Resolution to `None`.

3. Enable DLSS again.

After this sequence, Super Resolution could fail to resume correctly, while the frame rate dropped to approximately 24 FPS.

Further isolation showed that the underlying performance cliff was not caused by DLAA or by a particular DLSS model. It occurred at sub-native render scales: when SR was set to None or was suppressed, Luma was still intercepting the game's native Temporal Upscale (TUP) draw. This unnecessarily redirected and split GBFR's deferred command-list path, potentially serializing work that the game normally records in parallel.

I fixed this in the Temporal Upscale branch of Source/Games/Granblue Fantasy Relink/main.cpp by leaving the game's native draw and command-list scheduling untouched when no SR implementation should run for that frame:

if (device_data.sr_type == SR::Type::None || device_data.sr_suppressed)
{
   return DrawOrDispatchOverrideType::None;
}

When DLSS or FSR is active, Luma still replaces the native TUP path as intended. After applying this change, I repeated the same switching sequence and could no longer reproduce the 24 FPS performance drop.

Can you make a separate PR for this change. I took your changes along with some others and pushed the. I marked you as co-author. make a PR for this from new master branch if you don't mind I will close this PR now.

[Hiyajomaho-num9]

Have tested and reviewed the code, can confirm it works and is safe.

Thanks for testing and reviewing this PR.

My manual testing was mainly limited to:

1. Switching focus with Alt+Tab.
2. Switching between fullscreen and windowed modes.
3. Hot-switching DLSS models/presets and changing the render scale.

While testing the third case, I found the following issue. One sequence that reproduced it was:

1. Enable DLSS at a sub-native render scale.
2. Set Super Resolution to None.
3. Enable DLSS again.

After this sequence, Super Resolution could fail to resume correctly, while the frame rate dropped to approximately 24 FPS.

Further isolation showed that the underlying performance cliff was not caused by DLAA or by a particular DLSS model. It occurred at sub-native render scales: when SR was set to None or was suppressed, Luma was still intercepting the game's native Temporal Upscale (TUP) draw. This unnecessarily redirected and split GBFR's deferred command-list path, potentially serializing work that the game normally records in parallel.

I fixed this in the Temporal Upscale branch of Source/Games/Granblue Fantasy Relink/main.cpp by leaving the game's native draw and command-list scheduling untouched when no SR implementation should run for that frame:

if (device_data.sr_type == SR::Type::None || device_data.sr_suppressed)
{
   return DrawOrDispatchOverrideType::None;
}

When DLSS or FSR is active, Luma still replaces the native TUP path as intended. After applying this change, I repeated the same switching sequence and could no longer reproduce the 24 FPS performance drop.

Have tested and reviewed the code, can confirm it works and is safe.

Thanks for testing and reviewing this PR.
My manual testing was mainly limited to:

1. Switching focus with `Alt+Tab`.

2. Switching between fullscreen and windowed modes.

3. Hot-switching DLSS models/presets and changing the render scale.

While testing the third case, I found the following issue. One sequence that reproduced it was:

1. Enable DLSS at a sub-native render scale.

2. Set Super Resolution to `None`.

3. Enable DLSS again.

After this sequence, Super Resolution could fail to resume correctly, while the frame rate dropped to approximately 24 FPS.
Further isolation showed that the underlying performance cliff was not caused by DLAA or by a particular DLSS model. It occurred at sub-native render scales: when SR was set to None or was suppressed, Luma was still intercepting the game's native Temporal Upscale (TUP) draw. This unnecessarily redirected and split GBFR's deferred command-list path, potentially serializing work that the game normally records in parallel.
I fixed this in the Temporal Upscale branch of Source/Games/Granblue Fantasy Relink/main.cpp by leaving the game's native draw and command-list scheduling untouched when no SR implementation should run for that frame:

if (device_data.sr_type == SR::Type::None || device_data.sr_suppressed)
{
   return DrawOrDispatchOverrideType::None;
}

When DLSS or FSR is active, Luma still replaces the native TUP path as intended. After applying this change, I repeated the same switching sequence and could no longer reproduce the 24 FPS performance drop.

Can you make a separate PR for this change. I took your changes along with some others and pushed the. I marked you as co-author. make a PR for this from new master branch if you don't mind I will close this PR now.

Yeah, no problem. As long as it gets the project fixed, I’m okay with however you want to handle it.