-
-
Notifications
You must be signed in to change notification settings - Fork 21.3k
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
[3.x] Unbind texture slots when changing framebuffer #80481
Conversation
8e51051
to
096d6cd
Compare
Prevent bugs whereby texture still in use.
096d6cd
to
5e197fd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! I think the overhead of accidentally unbinding a texture slot that wasn't bound would be pretty low. But this doesn't add much more complexity to have the peace of mind that we aren't unbinding too much.
It would be nice to have this forward ported to 4.x as well.
Sure, it's pretty simple. |
Thanks! |
I found 8 errors before running a project like this:
I think is because |
You are correct |
Ah yes, silly me, I must have only tested Until then just ignore these messages, they are benign. |
Prevent bugs whereby texture still in use.
Roughly based on @clayjohn's draft clayjohn@baf691a
Fixes #61632
Maintains a list of texture slots that have been bound in the current frame, so they can be unbound when setting a new render target.
Notes
frame
.Clayjohn's original draft did this:
This seems likely to duplicate unbinding for a bunch of slots.
I experimented with keeping a maximum slot from the beginning and minimum from the end of the texture unit range, but decided in the end it was probably the best trade off to keep a list of slots in use. In combination with a lookup table (bitfield used here) it should be very efficient with negligible cost.