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
#1330 introduced a new texture system that deletes the CPU memory once the data is copied to the GPU. However, this introduces problems for feature ID texture + property texture property picking, which depended on image.pixelData to remain on the CPU.
#1367 was a band-aid fix for such scenarios, by copying any textures that happen to be used by the material. But we should have a more robust solution, because this can potentially create too many copies. For instance, two property texture properties can sample the same texture, just at different channels.
One idea I had is to just move the deletion of the textures after every single texture in the model has been processed. During creation, we can just mark if a CPU texture should be deleted, then do a final pass over all the textures in a model. This feels most safe, though I don't know if that undoes or interferes with any of the work that #1330 did.
the "best" solution here is to have even metadata textures be on the CPU or the GPU, but not both (i.e., have only one copy of each texture in memory ever), even if that requires a GPU read-back in some cases.
So a future solution could be to keep the memory on the GPU, but add code that can read-back from the GPU and sample the texture.
The text was updated successfully, but these errors were encountered:
#1330 introduced a new texture system that deletes the CPU memory once the data is copied to the GPU. However, this introduces problems for feature ID texture + property texture property picking, which depended on
image.pixelData
to remain on the CPU.#1367 was a band-aid fix for such scenarios, by copying any textures that happen to be used by the material. But we should have a more robust solution, because this can potentially create too many copies. For instance, two property texture properties can sample the same texture, just at different channels.
One idea I had is to just move the deletion of the textures after every single texture in the model has been processed. During creation, we can just mark if a CPU texture should be deleted, then do a final pass over all the textures in a model. This feels most safe, though I don't know if that undoes or interferes with any of the work that #1330 did.
@kring also suggested:
So a future solution could be to keep the memory on the GPU, but add code that can read-back from the GPU and sample the texture.
The text was updated successfully, but these errors were encountered: