Really glad to see initial dmabuf support in r4p0, to replace ump, i.e. using this variant string:
VARIANT=mali400-r1p1-gles11-gles20-linux-monolithic-no_profiling-x11-dma_buf
Thanks for implementing that!
I would love to move away from the UMP version but we currently rely on a special feature in the UMP version: umplock.
This solves a synchronization problem on textures that are created from X pixmaps. Otherwise, such textures can then be concurrently accessed to by X and libMali at the same time, leading to misrenderings and visual glitches. umplock allows access to be nicely synchronized. The key part is that the libMali binary itself implements this, it tells the umplock driver when it is using specific buffers and then when it has finished with them.
What is the umplock equivalent in the dmabuf variant of mali?
I know this question could be a bit complicated because dma-buf itself doesn't give a clear answer of how access should be controlled and synchronized between multiple users of a buffer. Or at least, not until recently. Looks like there has been some progress on that topic in recent kernel releases.
Hi dsd,
Sorry for the delay in getting back to you.
I've contacted the relevant people at this end and I have some news.
We have an update to armsoc which implements umplock for both ump and dma buf backends which will give you the buffer locking functionality you want. This update has not yet been released though and is currently sitting with legal for approval.
As a result, I can safely tell you that the update is en route and will do what you require, but I can't give you any kind of time frame for release unfortunately.
Hope this helps,
Rich