several older games refuse to work with update 6.5.1

I have a few games, that refuse to launch with reshade, after update namely:

GTA San Andreas
Need for Speed Hot Pursuit 2
Far Cry

Reverting back to 6.4.1 fixes it with all 3. 

• Platform: Ubuntu 22.04 LTS + Proton (GE-Proton or Steam Proton)
• Symptom: Splash screen loads, then hard crash
• Log error:

  E5017: Aborting due to not yet implemented feature: SM1 non-float expression

• Fix: Rolling back to ReShade 6.4.1 (or earlier) resolves the crash

 

ReShade 6.5.1 error output on Far Cry 1 and other older D3D9/SM2 games (via Proton):

<anonymous>:21:13: E5017: Aborting due to not yet implemented feature: Instruction type HLSL_IR_IF.
<anonymous>:23:15: E5017: Aborting due to not yet implemented feature: SM1 non-float expression.
<anonymous>:24:13: E5017: Aborting due to not yet implemented feature: Instruction type HLSL_IR_IF.

...

23:29:39:595 [ 572] | ERROR | Failed to compile '.../Shaders/Layer.fx':
error: E__PostProcessVS: <anonymous>:19:15: E5017: Aborting due to not yet implemented feature: SM1 non-float expression.
<anonymous>:20:13: E5017: Aborting due to not yet implemented feature: Instruction type HLSL_IR_IF.

...

23:29:39:596 [ 576] | ERROR | Failed to compile '.../Shaders/PD80_03_Levels.fx':
error: E__PostProcessVS: <anonymous>:29:15: E5017: Aborting due to not yet implemented feature: SM1 non-float expression.
<anonymous>:30:13: E5017: Aborting due to not yet implemented feature: Instruction type HLSL_IR_IF.




Reverting to ReShade 6.4.1 solves the crash completely on the same setup. It looks like ReShade’s SM1/SM2 parser in 6.5.1 rejects valid instructions that worked in earlier builds.

Another one on the list:

Star Wars Battlefront 2004 (similar, but not exact same error), i use crosire d3d8to9, with Reshade 6.4.1 works well all shaders are loading. Switching to 6.5.1 all shaders fail to compile

On Star Wars Battlefront (Classic, 2004) using ReShade 6.5.1 via d3d8to9, all shaders fail to compile. Many throw:

E5017: Aborting due to not yet implemented feature: Ternary operator.

E5005: Function "step"/"tex2Dlod"/"radians" is not defined.

E3020: cannot sample from texture that is also used as render target in the same pass.

I also repeatedly get:

WARN | Reference count for IDirect3DDevice9 object ... is inconsistent! Leaking resources ...


Same game and setup works perfectly under ReShade 6.4.1.

API: DirectX 8 converted to 9 via d3d8to9 (crosire)

Platform: Steam + Proton GE (Linux)

GPU: RTX 3050 Laptop, NVIDIA 535.xx

Can provide more logs if needed.

You need to replace the d3dcompiler_47.dll Proton/Wine uses with the one from Windows, this is not a ReShade problem (it's just that ReShade 6.5+ loads it from C:\Windows\system32 or whatever that maps to in Wine, rather than from current PATH, which in your case appears to map to the Wine variant of d3dcompiler_47.dll, rather than the correct one).

Will test and revert back in a minute. Thx for the kind hint

Update: Working Fix for Shader Compilation Failures in ReShade 6.5.x on Older Games

Just finished testing extensively under Wine/Proton (Ubuntu 22.04) with GTA San Andreas and other D3D9/SM1 titles. Here’s the clear outcome:

Problem Recap
ReShade 6.5+ introduced changes to how the HLSL/FX compiler is loaded:

It now loads d3dcompiler_47.dll from C:\Windows\System32, ignoring the local game directory.

This breaks compatibility when using Wine’s stubby version of the DLL.

Even after replacing it with the correct Windows-native DLL (verified SHA1 + Wine override in place), shader compilation still fails with:

E5017: Aborting due to not yet implemented feature: SM1 non-float expression
E5017: Aborting due to not yet implemented feature: Instruction type HLSL_IR_IF


It seems these errors do not originate from the Microsoft HLSL compiler DLL, but they're coming from ReShade's internal FX parser

So even with the correct compiler DLL, ReShade 6.5.x:

Will still fail to compile many older .fx shaders

Particularly those using non-float SM1 logic or outdated instructions

Confirmed Fix for now
Reverting to ReShade 6.4.1 resolves the issue entirely.

All previously failing shaders (e.g., qUINT_mxao.fx, FakeHDR.fx, Bumpmapping.fx) now compile and run fine.

Works correctly under Wine/Proton with or without system overrides.

No shader model or instruction limitations encountered.

I also tested using a verified copy of d3dcompiler_47.dll from a native Windows 10 system and replaced the version in my Proton prefix. The SHA1 matched official Microsoft binaries, and Wine’s DLL load logs confirmed it was used.

Even so, the exact same SM1-related errors persisted — including E5017: non-float expression and E5005: radians not defined.

Those errors do not originate from from ReShade. It's still not using the correct one (which would not produce those errors, those "non-implemented" errors are from the Wine implementation). Nothing in ReShade FX compiler changed here, the only thing that changed is how d3dcompiler is loaded: You can compare the generated HLSL and will see it's identical between 6.4 and 6.5.

Let me test on a Windows machine once, but might take me a few days. Thanks a lot for the kind feedback

Hi @crosire,

I’ve done extensive testing across multiple games and environments, and I’m seeing consistent shader compilation failures in ReShade 6.5.0 and 6.5.1 — not just in one title or API, but across both D3D9 and D3D11 games under both Proton and Wine.

Test Cases:
GTA San Andreas (D3D9) – HOODLUM v1.0

Tested with multiple Proton versions (GE 8, GE 10-1) and Wine 9.x

Hitman (D3D11) – Standalone DX11 build via Steam with Proton 9

💻 Environments:
Proton-GE 8.x, GE 10-1, Steam Proton 9, and Wine 9.x — all tested

Clean Wine/Proton prefixes

No ENB, no d3d wrappers, no overlays

Using official reshade-shaders repo from GitHub

Valid ReShade.ini and preset paths confirmed

✅ ReShade 6.4.1 (same config):
Shaders compile successfully

Techniques appear and are selectable

Effects render normally in-game

❌ ReShade 6.5.0 / 6.5.1:
UI loads without issue

Shader list appears, but:

All shaders are red/grayed out

Compile errors shown in UI/logs, e.g.:

E5002: Static variables cannot have both numeric and resource components
Affects even simple official shaders like Clarity.fx, Tonemap.fx, FakeHDR.fx

“Reload all effects” does not resolve it

Reproducible Pattern:
Occurs across multiple games and APIs (D3D9, D3D11)

Reproducible in both Wine and Proton (across several versions)

Happens with official shaders only, too (i have a few added from other sources)

Using internal compiler and with d3dcompiler_47.dll override — no difference

Downgrading to ReShade 6.4.1 immediately restores full shader functionality


I understand ReShade 6.5.x introduced stricter HLSL parsing. That’s fine — but currently, even official shaders fail to compile under Wine/Proton. Is this expected behavior due to HLSL compliance, or could there be an unintended regression in how shaders are parsed or handled under Wine-like environments?
Override in Proton or Wine with .dll's provided from Reshade doesn't help here. I have tested with Proton 8-27, 10-1, Wine 9.x, Steam-Proton 9 and also several games (d3d8, d3d9 and d3d11). The behaviour is always the same. 

I apologize that I haven’t yet had time to test this on native Windows. I trust that it works fine there as designed. But if possible, could you confirm whether ReShade 6.5+ depends on any specific .dll, compiler version, or environment component that must be present for shader compilation to work properly under Wine/Proton?

I’d appreciate any guidance and would be happy to run tests or provide further logs if needed.

Thanks again!

Again, the HLSL generation between 6.4 and 6.5 did not change, ReShade generates the exact same code, which is then passed on to d3dcompiler. The only thing that changed is where d3dcompiler is loaded from (specifically "LoadLibrary("d3dcompiler_47.dll")" was changed to the equivalent of "LoadLibrary("C:\Windows\system32\d3dcompiler_47.dll")").
I have gotten report from other Proton users that they are not seeing problems, indicating a potential setup issue causing the wrong d3dcompiler to be used. The Wine implementation of d3dcompiler is missing various required features and not supported, it has to be the original one from Microsoft. There isn't anything I can do really if the wrong d3dcompiler is being used. I'm not familiar enough with Proton to troubleshoot why it's not using the right DLL though.

Thanks for the kind and detailed feedback.
Let me get a good .dll and will try it again. I thought the with reshade delivered d3dcompiler_47.dll would be ok to use, eventually have to try it with a native one.
If not will wait for an update. eventually a quirky failure wiht my system.
Btw. amazing work you have delivered with reshade. Never thought i could get my old titles such a nice overhaul.

Ok, native or not, it's the same result.
Since 6.4.1 works well, we might just forget about it for now and wait if it resolves with updates.
Eventually a quirky issue with my system.

Thanks for continued support and inputs.