Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

restorable: Split pixel data into multiple slices #897

Closed
hajimehoshi opened this issue Jul 9, 2019 · 2 comments
Closed

restorable: Split pixel data into multiple slices #897

hajimehoshi opened this issue Jul 9, 2019 · 2 comments
Milestone

Comments

@hajimehoshi
Copy link
Owner

For sparse images, this should be effective in terms of memory usage. Big shareable images tend to be sparse in our experience.

@hajimehoshi hajimehoshi added this to the v1.10.0 milestone Jul 9, 2019
hajimehoshi added a commit that referenced this issue Jul 9, 2019
This hides the implementation details of allocating byte slice.

This change also adds comments about #897.
hajimehoshi added a commit that referenced this issue Jul 16, 2019
This simplifies Pixels struct. This is a preparation to change
how to record pixels.

Updates #897
@hajimehoshi
Copy link
Owner Author

hajimehoshi commented Jul 17, 2019

I think we can reduce redundant memory usages by these actions:

  • Split the byte slice for a texture into a multiple slices (this issue). For example, a 4096x4096 image needed to hold 64MB memory, but if we can keep only needed data, this can be reduced to about 10MB or so.
  • Remove CopyPixels command and use ReplacePixels instead. CopyPixels allocates all the pixel data of the texture, the same data might be in the restorable package though. For example, when extending a 2048x2048 image to a 4096x4096 image, CopyPixels read 16MB data from GPU to copy the pixels.

Then, I estimate we can reduce 40-50MB peak memory usage in theory in usual cases.

hajimehoshi added a commit that referenced this issue Jul 17, 2019
This is an optimization. This change enables to avoid reading
pixels from GPU when extending an image.

Updates #897
@hajimehoshi
Copy link
Owner Author

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

1 participant