jlrouzies-fr/DLSS5-Feeder v0.7.0

DLSS5-Feeder v0.7.0 - OpenGL support (tested in one game: Worms Ultimate Mayhem, 32-bit)

on GitHub

OpenGL games are now supported, in both bitnesses — the last renderer that still disabled itself. Everything else is unchanged from v0.6.1.

Read this before you get excited

This has been tested end-to-end in exactly one game: Worms Ultimate Mayhem, 32-bit OpenGL, at 4K. That is one data point, not a games table.

The 64-bit OpenGL path shares the same header, the same transport and the same code path, and its interop is proven on hardware by the bundled spike — but no 64-bit OpenGL game has been run. One question is genuinely still open there: whether the DLSS 5 add-on arms its NGX hooks in a process where ReShade loads as opengl32.dll rather than dxgi.dll. On the 32-bit path that question does not arise, because the add-on lives in the 64-bit helper process, where it is long proven. If you try a 64-bit OpenGL game, ReShade.log will tell you: look for D3D12 NGX hooks installed.

Only LumeniteFX Kernel has been shown to compile under ReShade's GLSL code generation. The other four motion-vector providers are untested on OpenGL.

Install

Same pieces as any other 64-bit game, with one difference: ReShade for OpenGL is a local opengl32.dll next to the game exe — pick OpenGL in ReShade's installer and tick "Enable loading of add-ons". No layer, no hook, no registry entry, and no AddonPath setting: add-ons load from ReShade's own directory, which is the game folder.

ReShade 6.8 or newer is required. This add-on needs add-on API version 20; a 6.7.x install offers 14 and will silently refuse to load it. If nothing appears in the overlay, check the first line of ReShade.log.

For a 32-bit OpenGL game, install the x86 ReShade plus dlss5-feed.addon32 and the host64\ folder, exactly as in the existing 32-bit instructions. Install both halves from the same release — the protocol version changed (see below) and mismatched halves now refuse each other with a message instead of misbehaving.

Hybrid laptops: force the game onto the NVIDIA GPU. On the integrated GPU the interop extensions do not exist and the feed disables itself saying so — DLSS could not have run there anyway.

How it works, and why it is not just the Vulkan path again

The DLSS evaluate still runs on a private D3D12 device, because the DLSS 5 add-on only hooks D3D12 NGX entry points. What is new is how the frame crosses: D3D12 creates the shared textures and fences, OpenGL imports them. That direction is forced — GL memory objects are import-only, there is no memory-object export in GL_EXT_external_objects_win32.

Two things differ sharply from the Vulkan transport:

The whole per-frame GL side is raw. On Vulkan, a ReShade api::fence is a VkSemaphore, which let that path hand its imports back to ReShade and keep every queue operation inside ReShade's own locks. On OpenGL an api::fence is documented as "an opaque value" — there is nothing to hand back. So the GL path issues zero ReShade API calls per frame beyond its texture lookups. That is safe here precisely where it was not on Vulkan: OpenGL has no queue object. Every command enters the current context's single in-order stream on the calling thread, and ReShade fires the technique event while it is itself issuing GL commands on that same thread and context. Our calls interleave in program order — there is no lock to bypass, and no barriers are needed at all.

No device hook and no layer. Vulkan bakes extensions in at vkCreateDevice, which is why that path needs an inline hook and ships a fallback layer. OpenGL has no creation-time opt-in: the interop extensions are either in the current context's extension string or they are not, and if they are not, the frame is not being rendered on an NVIDIA GPU. OnCreateDevice needed no OpenGL branch at all.

Protocol v2 (32-bit path)

The 32-bit OpenGL path reuses the same interop header compiled x86, over the existing helper-process protocol — with one change the API forces: the host creates the shared textures, since a GL process cannot export one.

• FeedHello gains client_kind, so the host knows which direction to use.
• FeedBuildAck gains the host-duplicated texture handles and their allocation sizes — a client with no D3D12 device cannot ask for those itself.
• A v2 host still reads a v1 client's shorter hello, and both sides refuse a version they do not understand rather than misparsing it.

The D3D11 32-bit path is untouched and still creates its own textures.

What the sRGB trap did not do

glBlitFramebuffer decodes and encodes sRGB while GL_FRAMEBUFFER_SRGB is enabled, which is exactly the shape of the washed-out image fixed on Vulkan in v0.6.1 (#11). The state guard forces it off for our blits so the bytes move raw, and the build logs the render target's colour encoding. In Worms it reports GL_TEXTURE_2D / GL_LINEAR, so the trap does not arise there and the gl_srgb escape hatch the plan reserved was not needed and is not implemented. If you hit a washed-out OpenGL game, that log line is the first thing to report.

Also in this release

• Two new spikes, spike-gl64.exe and spike-gl32.exe, which round-trip a texture and a fence between D3D12 and OpenGL — in-process and cross-process — through the same header the add-on ships, so a PASS is a PASS for the shipped code. They need an NVIDIA GPU to run, none to compile, and CI builds them on every pull request.
• Measured cost in Worms Ultimate Mayhem at 4K: 0.13 ms/frame of game CPU in steady state.

Files

renodx-dlss5.addon64, nvngx_dlssnr.dll and nvngx_dlss.dll are not redistributed here — see the README.