Recent GRD releases have severely impacted the outputs from the deferred lighting step of our game engine (FreeSpace 2 Open).
The observed effect is that point lights no longer render until the camera position is within the area of lighting influence, in which case the lighting appears to be strongly exaggerated, or close to geometry that occludes the source, in which the light can be observed as a flat colored circle/sphere being rendered through the geometry.
We have run a significant amount of debugging using RenderDoc and could find no issue in our pipeline. After exhausting testing individual changes, our best guess is a regression in how buffers are passed to and from the GPU or some change to fragment culling, but these are just semi-educated guesses and we have no way to test this.
This does not affect directional lights.
Image showing the occluded light case: https://i.imgur.com/M0YM5k2.jpeg
Hello @tylerrblount and welcome to the NVIDIA developer forums!
I loved playing Freespace 2! Such a great game!
Now for the problem at hand, can you pinpoint the exact driver version where this started to change? Then I could look up changelogs etc. and see what might influence this kind of behaviour. But no promises, since what you are describing is not some rare special case I doubt it really is a direct effect of a driver change. Otherwise we would be covered in complaints already.
Is this in the original engine or part of the Mod? And which DirectX version are you using?
Let’s start with that and see where we get.
Thanks!
Yes, the first driver version we could pinpoint was 531.18, released on Feb 28, 2023. The previous driver version, a 525.xx driver released on Feb 8, 2023 is the last downloadable version we could find that functions as expected.
This is the core FreeSpace 2 Open engine being affected. We do not support DirectX and currently target OpenGL 3.2+ Core.
If you would like, we have a GitHub where all the source code can be viewed: GitHub - scp-fs2open/fs2open.github.com: Origin Repository for SCP FreeSpace 2 Open
Hi, I’m The E, one of the developers working on FSO and one of the people investigating this issue.
This is an image showing the bug in action. Note the blue area that looks like an overlay of several blue circles in the center of the screen.
These are areas where our point light shader is trying to render lights that should be occluded by the ship geometry; drivers prior to and including 528.49 evaluate this correctly.
This is a link to a RenderDoc capture of this frame. Do note that, with its default settings, RenderDoc does not show this behaviour - this may be a hint for your driver engineers. However, when we inspect the frame and go through the draw calls and set the texture viewer to use the “Clear Before Pass” overlay, we can see the bug happening quite clearly:
(for reference: The relevant draw calls for this bug happen between event 630 and 1217, in the “Deferred Apply Single Light” steps)
Hi @fwoltermann, welcome to the NVIDIA developer forums to you too.
Thank you for all the detailed information and he RenderDoc link!
I’ll pass it on to the team and check if we need to open an internal bug report.
I always forget, would it be possible to create a minimal repro app for this in case the Renderdoc is not enough?
Because downloading and building the whole project might be difficult to do for us for various reasons.
Thanks!
The most minimal repro we can get would be an nsight capture project, would that be enough?
Here’s an nsight capture, taken from my system, running driver version 536.40 on Win 11 22H2 with an RTX 3080.
I wanted to ask for an API trace, but I think the NSight capture should be just fine :-) And thanks for the system details.
I opened an internal bug for this, hopefully we will be able to get back to you soon on this!
It’s been some time, has there been any development or update?
Has there been any movement on this issue?
I am sorry, but so far there is nothing new to report.
Hi, another developer for FreeSpace 2 Open here.
We think we have pinpointed where the issue occurs, which’ll hopefully help you to fix it:
In one of our shaders, we have an out vec3 lightPosition in the vertex stage, and a corresponding in vec3 lightPosition in the fragment stage.
By the time we read this vec3 in the fragment stage, it no longer contains the expected value (I assume it contains NAN or some other invalid / uninitialized value).
I assume that this is because the out vec3 lightPosition in the vertex stage is set to a dynamically uniform expression, and this dynamically uniform expression is then the target of some incorrect or overzealous optimization by the shader compiler since the 531.18 driver. Replacing every read of the lightPosition parameter in the shader’s fragment stage with the same dynamically uniform expression that populates lightPosition in the vertex stage resolves the incorrect lighting.
I hope this helps to track down the change in the driver that seems to have caused this difference in shader compilation (and possibly optimization).
1 Like
Hi @birk.magnussen and also welcome to you.
Thanks for the additional details. I added them to the bug report and updated the people involved.
