Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unnecessary heap allocations per frame for WebGL renderer. #374

Closed
itsjamie opened this issue Sep 10, 2024 · 5 comments · Fixed by #381
Closed

Unnecessary heap allocations per frame for WebGL renderer. #374

itsjamie opened this issue Sep 10, 2024 · 5 comments · Fixed by #381

Comments

@itsjamie
Copy link

rdkcentral/Lightning#494

Reopening this issue which impacted Lightning 2 and still impacts Lightning 3.

setUniform(name: string, ...value: any[]): void {
// eslint-disable-next-line @typescript-eslint/no-non-null-assertion, @typescript-eslint/no-unsafe-argument
this.glw.setUniform(
this.uniformTypes[name]!,
this.uniformLocations[name]!,
...(value as any),
);
}

setUniform(name: string, ...value: any[]): void {
// eslint-disable-next-line @typescript-eslint/no-non-null-assertion, @typescript-eslint/no-unsafe-argument
this.glw.setUniform(
this.uniformTypes[name]!,
this.uniformLocations[name]!,
...(value as any),
);
}

The direct usage of the generic version of this function leads to each of those spread and rest operators creating new arrays that have to be garbage collected after each frame that includes these shaders.

If ...args was replaced with arguments usage, it is possible you could keep the generic function without the explicit array being created from the rest operator usage.

For general applications this is fine, but the moment you have an animation that includes a re-render this can quickly grow into forcing many garbage collection cycles.

@itsjamie
Copy link
Author

As recommended in the Lightning 2 ticket, adding the explicit GL functions that take stack parameters would also resolve this, such as setUniform<1f,2f,3f,4f> etc. This would mean having to use the proper value. I think it's a fine trade to have to use the explicit function. Anyway, as before, wanted to open the issue for discussion.

@wouterlucas
Copy link
Contributor

Nice - thanks for resurfacing this @itsjamie !

Tagging @erikhaandrikman and @jfboeve - lets discuss this next sync.

@wouterlucas
Copy link
Contributor

Something like this @itsjamie: 79f6181 ?

@itsjamie
Copy link
Author

Exactly like that. 👍

@wouterlucas
Copy link
Contributor

ok - will noodle on that and get a PR up soonish.

wouterlucas added a commit that referenced this issue Sep 13, 2024
- Removed the setUniform method from the WebGLContextWrapper class.
- Updated the setUniform method to handle different types of uniforms, including single argument uniforms like uniform1f, uniform1fv, etc.
- Added support for setting uniform values using the appropriate WebGLRenderingContext methods based on the uniform type.

Related to #374
github-merge-queue bot pushed a commit that referenced this issue Sep 20, 2024
#381)

Fixes #374

Could not fall back to `arguments` as that isn't allowed in strict mode,
working around that only made it worse.
Moved everything up early in the chain to call the respective uniform
method directly, with minimal overhead which should avoid the additional
GC pressure as described in #374

Only thing I need to figure out what the impact is of losing the
`setUniform` argument caching that was originally there, worst case we
have to implement a cache check at each individual uniform method.

@jfboeve the Dynamic Shader was a bit of a thing - please 👀 if this
makes sense. I don't know if the additional argument uniforms can
actually happen in the Dynamic Shader case (I assumed so).
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 a pull request may close this issue.

2 participants