-
Notifications
You must be signed in to change notification settings - Fork 63
Implement staging buffer and use it for the material system #1675
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
base: master
Are you sure you want to change the base?
Conversation
96d8c0d
to
88c7d08
Compare
The CI error is caused by some unrelated bullshit. |
That sounds related |
Oh right, it's because of the moronic behaviour with static const in class declarations. |
Well no, it's gotta be caused by something else too, because even with |
Adds `GLStagingBuffer` and `GLBufferCopy()`. `GLStagingBuffer` allows setting buffer storage and map flags to 0 on the destination buffers, which pretty much guarantees that they will go into VRAM. The data is uploaded through mapping `stagingBuffer` and doing a copy of the data on the GPU.
Yeah I don't think |
Yeah, it's defaulting to C++14 apparently. |
It'll just have to do with the old redundant way. |
Adds
GLStagingBuffer
andGLBufferCopy()
.GLStagingBuffer
allows setting buffer storage and map flags to 0 on the destination buffers, which pretty much guarantees that they will go into VRAM. The data is uploaded through mappingstagingBuffer
and doing a copy of the data on the GPU.The
stagingBuffer
itself should (still depends on the driver) go into the BAR memory (on Nvidia this shows up asDMA_CACHED
when usingr_glDebugProfile on; r_glDebugMode 7
).Slightly improves material system performance. Currently this is used for all material system buffers except the portal one (since it requires reading from the GPU), and for the 2 geometry cache buffers that are currently used.
Also fixed
GLBuffer.mapped
state being retained on map change/load.