Skip to content

perf(llf): significantly improve scaling with many lights#1185

Merged
doodlum merged 2 commits into
devfrom
llf-perf
Jun 23, 2025
Merged

perf(llf): significantly improve scaling with many lights#1185
doodlum merged 2 commits into
devfrom
llf-perf

Conversation

@doodlum
Copy link
Copy Markdown
Collaborator

@doodlum doodlum commented Jun 23, 2025

Re-adds old hooks that skips sorting the majority of lights per-object which leads to CPU improvements. Skips casting because that was slow.

Summary by CodeRabbit

  • New Features
    • Improved light validation by adding new checks for certain lighting conditions, enhancing compatibility and visual accuracy in scenarios with specific light properties.

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Jun 23, 2025

Walkthrough

Three new hook structs—ValidLight1, ValidLight2, and ValidLight3—were introduced in the LightLimitFix::Hooks namespace. Each struct provides a thunk function that wraps an original function pointer and adds extra validation logic. The Install() method was updated to install these hooks at specific relocated addresses.

Changes

File(s) Change Summary
src/Features/LightLimitFix.h Added three hook structs (ValidLight1, ValidLight2, ValidLight3) with thunk functions and original function pointers; updated Install() to write new thunk calls at specific relocation addresses.

Sequence Diagram(s)

sequenceDiagram
    participant ClientCode
    participant ValidLightX (thunk)
    participant OriginalFunc
    participant Light

    ClientCode->>ValidLightX (thunk): Call(RE::BSShaderProperty*, RE::BSLight*)
    ValidLightX (thunk)->>OriginalFunc: Call original function with parameters
    OriginalFunc-->>ValidLightX (thunk): Return bool
    ValidLightX (thunk)->>Light: Check portalStrict/portalGraph
    ValidLightX (thunk)-->>ClientCode: Return true if both checks pass
Loading

Poem

Three new hooks in the code do dwell,
ValidLight1, 2, and 3—oh swell!
They check the lights with portal flair,
Ensuring only the right ones are there.
With every thunk and careful call,
The rabbit hops and thanks you all! 🐇✨


📜 Recent review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0ee08d4 and f323c30.

📒 Files selected for processing (1)
  • src/Features/LightLimitFix.h (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • src/Features/LightLimitFix.h
⏰ Context from checks skipped due to timeout of 90000ms (1)
  • GitHub Check: Build plugin and addons
✨ Finishing Touches
  • 📝 Generate Docstrings

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Automated formatting by clang-format, prettier, and other hooks.
See https://pre-commit.ci for details.
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🧹 Nitpick comments (1)
src/Features/LightLimitFix.h (1)

320-322: Consider adding error handling for hook installation.

The hook installations don't have error handling, which could make debugging difficult if installation fails. Consider adding validation or logging for failed installations.

-			stl::write_thunk_call<ValidLight1>(REL::RelocationID(100994, 107781).address() + 0x92);
-			stl::write_thunk_call<ValidLight2>(REL::RelocationID(100997, 107784).address() + REL::Relocate(0x139, 0x12A));
-			stl::write_thunk_call<ValidLight3>(REL::RelocationID(101296, 108283).address() + REL::Relocate(0xB7, 0x7E));
+			try {
+				stl::write_thunk_call<ValidLight1>(REL::RelocationID(100994, 107781).address() + 0x92);
+				stl::write_thunk_call<ValidLight2>(REL::RelocationID(100997, 107784).address() + REL::Relocate(0x139, 0x12A));
+				stl::write_thunk_call<ValidLight3>(REL::RelocationID(101296, 108283).address() + REL::Relocate(0xB7, 0x7E));
+			} catch (const std::exception& e) {
+				logger::error("[LLF] Failed to install ValidLight hooks: {}", e.what());
+				throw;
+			}
📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 02dc8e5 and 0ee08d4.

📒 Files selected for processing (1)
  • src/Features/LightLimitFix.h (2 hunks)
🔇 Additional comments (1)
src/Features/LightLimitFix.h (1)

281-306: Verify the light filtering logic aligns with performance goals.

The validation logic (a_light->portalStrict || !a_light->portalGraph) filters lights based on portal properties. Please confirm this logic correctly identifies lights that can skip per-object sorting to achieve the stated performance improvements.

#!/bin/bash
# Description: Search for usage of portalStrict and portalGraph to understand their purpose
# Expected: Find context about how these properties are used in light processing

echo "Searching for portalStrict usage..."
rg -A 3 -B 3 "portalStrict"

echo "Searching for portalGraph usage..."
rg -A 3 -B 3 "portalGraph"

echo "Searching for light validation patterns..."
rg -A 5 -B 5 "BSLight.*portal"

Comment on lines +283 to +285
static bool thunk(RE::BSShaderProperty* a_property, RE::BSLight* a_light)
{
return func(a_property, a_light) && (a_light->portalStrict || !a_light->portalGraph);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Add null pointer validation for runtime safety.

The thunk functions access a_light->portalStrict and a_light->portalGraph without null checks, which could cause crashes if a null pointer is passed.

 			static bool thunk(RE::BSShaderProperty* a_property, RE::BSLight* a_light)
 			{
-				return func(a_property, a_light) && (a_light->portalStrict || !a_light->portalGraph);
+				return a_light && func(a_property, a_light) && (a_light->portalStrict || !a_light->portalGraph);
 			}

Also applies to: 292-294, 301-303

🤖 Prompt for AI Agents
In src/Features/LightLimitFix.h at lines 283-285, 292-294, and 301-303, the
thunk functions access a_light->portalStrict and a_light->portalGraph without
checking if a_light is null, risking crashes. Add null pointer checks for
a_light before accessing its members by returning false or handling the null
case appropriately to ensure runtime safety.

Comment on lines +281 to +306
struct ValidLight1
{
static bool thunk(RE::BSShaderProperty* a_property, RE::BSLight* a_light)
{
return func(a_property, a_light) && (a_light->portalStrict || !a_light->portalGraph);
}
static inline REL::Relocation<decltype(thunk)> func;
};

struct ValidLight2
{
static bool thunk(RE::BSShaderProperty* a_property, RE::BSLight* a_light)
{
return func(a_property, a_light) && (a_light->portalStrict || !a_light->portalGraph);
}
static inline REL::Relocation<decltype(thunk)> func;
};

struct ValidLight3
{
static bool thunk(RE::BSShaderProperty* a_property, RE::BSLight* a_light)
{
return func(a_property, a_light) && (a_light->portalStrict || !a_light->portalGraph);
}
static inline REL::Relocation<decltype(thunk)> func;
};
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Eliminate code duplication by creating a template or shared implementation.

All three ValidLight structs contain identical logic, which violates the DRY principle and increases maintenance overhead. Consider refactoring to use a template or shared base implementation.

-		struct ValidLight1
-		{
-			static bool thunk(RE::BSShaderProperty* a_property, RE::BSLight* a_light)
-			{
-				return func(a_property, a_light) && (a_light->portalStrict || !a_light->portalGraph);
-			}
-			static inline REL::Relocation<decltype(thunk)> func;
-		};
-
-		struct ValidLight2
-		{
-			static bool thunk(RE::BSShaderProperty* a_property, RE::BSLight* a_light)
-			{
-				return func(a_property, a_light) && (a_light->portalStrict || !a_light->portalGraph);
-			}
-			static inline REL::Relocation<decltype(thunk)> func;
-		};
-
-		struct ValidLight3
-		{
-			static bool thunk(RE::BSShaderProperty* a_property, RE::BSLight* a_light)
-			{
-				return func(a_property, a_light) && (a_light->portalStrict || !a_light->portalGraph);
-			}
-			static inline REL::Relocation<decltype(thunk)> func;
-		};
+		template<int N>
+		struct ValidLight
+		{
+			static bool thunk(RE::BSShaderProperty* a_property, RE::BSLight* a_light)
+			{
+				return func(a_property, a_light) && (a_light->portalStrict || !a_light->portalGraph);
+			}
+			static inline REL::Relocation<decltype(thunk)> func;
+		};
+		
+		using ValidLight1 = ValidLight<1>;
+		using ValidLight2 = ValidLight<2>;
+		using ValidLight3 = ValidLight<3>;
🤖 Prompt for AI Agents
In src/Features/LightLimitFix.h between lines 281 and 306, the three ValidLight
structs have identical thunk functions causing code duplication. Refactor by
creating a single templated struct or a shared base struct that implements the
thunk function once, then instantiate or inherit it for ValidLight1,
ValidLight2, and ValidLight3 to eliminate redundancy and improve
maintainability.

@github-actions
Copy link
Copy Markdown

✅ A pre-release build is available for this PR:
Download

@doodlum doodlum merged commit a509ec0 into dev Jun 23, 2025
16 checks passed
alandtse pushed a commit to alandtse/open-shaders that referenced this pull request Jul 20, 2025
…shaders#1185)

* perf(llf): significantly improve scaling with many lights

* style: 🎨 apply pre-commit.ci formatting

Automated formatting by clang-format, prettier, and other hooks.
See https://pre-commit.ci for details.

---------

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
@coderabbitai coderabbitai Bot mentioned this pull request Mar 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants