Skip to content

fix(gfx): generate cloud mipmaps after unbinding the render FBO#4344

Open
semeaj wants to merge 1 commit into
open-goal:masterfrom
semeaj:fix/clouds-mipmap-scope
Open

fix(gfx): generate cloud mipmaps after unbinding the render FBO#4344
semeaj wants to merge 1 commit into
open-goal:masterfrom
semeaj:fix/clouds-mipmap-scope

Conversation

@semeaj

@semeaj semeaj commented Jul 17, 2026

Copy link
Copy Markdown

Found while investigating the jak2/jak3 one-frame sky flicker (see the fog CLUT inline payload PR: #4343).

Problem

TextureAnimator::run_clouds calls glGenerateMipmap on the final cloud texture while that texture is still attached to the currently bound draw framebuffer (the FramebufferTexturePairContext is still in scope). Reading a texture that is attached to the bound framebuffer is a driver hazard even outside a draw call.

Every other site in this file already avoids this: run_slime and opengl_upload_resize_texture both close the FBO context scope before generating mipmaps. run_clouds is the one outlier, presumably an oversight.

Fix

Scope the FramebufferTexturePairContext in braces and generate the mipmaps after it restores the previous framebuffer binding, matching the established pattern in the rest of the file.

Test plan

  • jak2/jak3 clouds render identically (hires and normal cloud modes)

(AI-assisted)

run_clouds called glGenerateMipmap on the cloud texture while it was
still attached to the currently bound draw framebuffer. Every other
site in this file (run_slime, opengl_upload_resize_texture) closes the
FramebufferTexturePairContext scope before generating mipmaps; make
run_clouds match. Reading a texture that is attached to the bound
framebuffer is a driver hazard even outside a draw.

(AI-assisted)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

1 participant