New pool allocator, pixmaps compression and some more

[digetx]

Pool allocator

I've replaced TLSF with a custom pool allocator which is simpler, faster and has features like defragmentation. The main reason of replacing TLSF is that it embeds allocation descriptors into the allocation itself, that is bad because a faulty out-of-bounds write will smash the descriptor and Xorg will crash and hence one of the GART/IOMMU purposes is defeated.

Pixmaps compression

Pixmaps data is getting compressed after few seconds of idling. If data is poorly compressible, then the data is just moved out from CMA. The supported compression types are: LZ4, PNG and JPEG. JPEG is a lossy compression that gives the best result, x3-x5 in memory savings without visual difference. Compression could be configured and disabled via xorg.conf.

Putting all together, now the memory management is a way much better than it was before. There are also couple minor-cleanup patches unrelated to MM that I included into this patchset.

[digetx]

@kusma, hope the amount of changes doesn't scare you much, any comments on this PR?

[kusma]

@digetx: hum, the size of this makes it kind of hard to digest, indeed...

[kusma]

I would also note that I'm veeery skeptical to lossy compression here. "without visual difference" sounds like an unlikely claim; some content can be more sensitive to JPEG artifacts than other, and I doubt the X driver is the right place to try and make such high-level, content-dependent decisions.

I guess the goal here is to reduce memory usage in common use-cases, right?

[digetx]

Yes, the goal is to optimize memory usage. I can disable the lossy compression by default, but it so good and I couldn't spot any differences after weeks of using it. Maybe later we could introduce other compressions like ETC or S3, that 3D could handle.

[digetx]

Disabled JPEG by default.

[kusma]

Sorry, I'm a bit swamped these days. I'll try to do a review tonight!

[digetx]

Take your time. I'm now considering some more invasive and radical change for opentegra, will see how it goes :)

[digetx]

Recently I was looking at what could be done about performance, unfortunately seems not much could be done at least until we'll have a new kernel driver in upstream. So the invasive changes are postponed and this PR shouldn't get any more changes.

[digetx]

@kusma are you okay with merging this?

[kusma]

@digetx: Yeah. I haven't reviewed it properly, but I'm also not really using this code, so I have no problem with it being merged if you think it's OK as-is.

[digetx]

@kusma I've been using it quite a lot and everything works perfect, will merge it later today.