You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm mostly writing this because it helps me to think but looking for ideas.
If you're unaware, uniform block objects allow uniforms to be stored in buffers. The issue is that basically anything can write to a buffer, using transform feedback you could have a shader write to a buffer. You can also use PBOs to transfer texture data to/from a buffer. As it is now I think you save all buffer updates whereas uniforms are only saved for a specific frame. But, once you put uniforms in buffers those buffers will be updated every single frame, saving all data for all frames seems bad. We'd run out of memory pretty quick.
There's now getBufferSubData to get data out of a buffer so maybe we could use that on the capture frame only? I'm not sure. You can also get texture data out of a buffer using PBOs. I guess I could make it so that on capture I get the data for uniforms using getBufferSubData and on playback I can use getBufferSubData to save the data currently in the buffer, then put the captured data into the buffer, then put the data that was there back.
I'm not sure that would really work. The buffer may have changed size. I could just use a hidden shadow buffer for uniforms and or everything else but it would require lots of remapping.
Or maybe the inspector just can't work with uniform buffer objects. As it is it saves bufferData and bufferSubData data but it's kind of assuming those are not called that often (right?) There's no way to tell beforehand if the data being put in is for vertices or for uniforms or something else. Also back to the transform feedback issue the inspector would have to save buffers after every transform feedback call to produce the right playback.
Ugh, now that I think about it making it work is going to be pretty hard.
Maybe capturing all buffer uploads should be an option. It's nice to be able to see all the calls to bufferData or bufferSubData for a particular buffer but given all that stuff above it should like capturing the uploads might need be the exception and otherwise just use getBufferSubData during capture.
Another big change is buffer bind target no longer = buffer type. All the code assumes there's 2 buffer types, ARRAY_BUFFER and ELEMENT_ARRAY_BUFFER but now there are 8 targets but only 2 buffer types, ELEMENT_ARRAY_BUFFER, and "other". You can bind the same buffer to all other 7 targets. They're just bind points for what the buffer will be used for, not it's type.
Anyway I'm not sure how the inspector should handle any of this. Like noticing how it currently needs to save the state of everything for playback means debugging things with video textures or dynamic textures is also problematic. Maybe it should be saving a snapshot of the data and track if things have been updated so it knows on the next capture if it needs new copies or can use the old ones.
Anyway, just thinking out loud but would love to hear thoughts.
The text was updated successfully, but these errors were encountered:
I'm mostly writing this because it helps me to think but looking for ideas.
If you're unaware, uniform block objects allow uniforms to be stored in buffers. The issue is that basically anything can write to a buffer, using transform feedback you could have a shader write to a buffer. You can also use PBOs to transfer texture data to/from a buffer. As it is now I think you save all buffer updates whereas uniforms are only saved for a specific frame. But, once you put uniforms in buffers those buffers will be updated every single frame, saving all data for all frames seems bad. We'd run out of memory pretty quick.
There's now
getBufferSubData
to get data out of a buffer so maybe we could use that on the capture frame only? I'm not sure. You can also get texture data out of a buffer using PBOs. I guess I could make it so that on capture I get the data for uniforms usinggetBufferSubData
and on playback I can usegetBufferSubData
to save the data currently in the buffer, then put the captured data into the buffer, then put the data that was there back.I'm not sure that would really work. The buffer may have changed size. I could just use a hidden shadow buffer for uniforms and or everything else but it would require lots of remapping.
Or maybe the inspector just can't work with uniform buffer objects. As it is it saves
bufferData
andbufferSubData
data but it's kind of assuming those are not called that often (right?) There's no way to tell beforehand if the data being put in is for vertices or for uniforms or something else. Also back to the transform feedback issue the inspector would have to save buffers after every transform feedback call to produce the right playback.Ugh, now that I think about it making it work is going to be pretty hard.
Maybe capturing all buffer uploads should be an option. It's nice to be able to see all the calls to bufferData or bufferSubData for a particular buffer but given all that stuff above it should like capturing the uploads might need be the exception and otherwise just use
getBufferSubData
during capture.Another big change is buffer bind target no longer = buffer type. All the code assumes there's 2 buffer types, ARRAY_BUFFER and ELEMENT_ARRAY_BUFFER but now there are 8 targets but only 2 buffer types, ELEMENT_ARRAY_BUFFER, and "other". You can bind the same buffer to all other 7 targets. They're just bind points for what the buffer will be used for, not it's type.
Anyway I'm not sure how the inspector should handle any of this. Like noticing how it currently needs to save the state of everything for playback means debugging things with video textures or dynamic textures is also problematic. Maybe it should be saving a snapshot of the data and track if things have been updated so it knows on the next capture if it needs new copies or can use the old ones.
Anyway, just thinking out loud but would love to hear thoughts.
The text was updated successfully, but these errors were encountered: