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've been thinking a bit about what would be the best way to make things faster on platforms such as the i.MX6. The biggest constraint is probably memory bandwidth, and to that end these are the things that we could try optimising:
The ZRLE encoder currently copies its results into a buffer and then sends the whole buffer. By dividing the zlib stream into chunks that are sent as soon as they are available, there should be less memory traffic. Hopefully individual chunks can fit in the cache.
A similar approach can be used for "tight" encoding.
We could look into tiling nvnc_fb and perhaps even compressing it. I suspect that the i.MX6 has plenty of processing power that just goes to waste because the bus just can't cope. Perhaps compression can improve performance. Lossy compression of the buffer might even be a good compromise when the user allows it.
I've been thinking a bit about what would be the best way to make things faster on platforms such as the i.MX6. The biggest constraint is probably memory bandwidth, and to that end these are the things that we could try optimising:
nvnc_fb
and perhaps even compressing it. I suspect that the i.MX6 has plenty of processing power that just goes to waste because the bus just can't cope. Perhaps compression can improve performance. Lossy compression of the buffer might even be a good compromise when the user allows it.cc @agners
The text was updated successfully, but these errors were encountered: