I'm working on Android in a virtualized environment under Xen hypervisor.
I suppose that drm_hwcomposer will be the convenient choice as a generic 
solution in that case.

I've implemented some platfomrXXX for our case, in which implemented Importer:
I.e. ImportBuffer and ReleaseBuffer for native buffers(i.e. ION allocated 
memory) in/from DRM.
I use the same ImportImage as in platformgeneric.cpp implementation(but I 
suppose it not used in our use-cases for now).
Please note, we use custom paravirtual DRM driver on our platform.
It has only one main plane so far.
Taking that into account, I suppose that all composition is done in 
SurfaceFlinger in that case.
I.e.: hwc report that it won't take any layers and SurfaceFlinger will do 
composition and propagate one buffer as framebuffer target(via SetClientTarget)
to hwc. That buffer will be placed on the main plane.

Using drm_hwcomposer I see buffer 
registration/deregistration(DrmHwcBuffer::ImportBuffer / DrmHwcBuffer::Clear) 
for each composition.
That cause some performance issues, which may be specific to our platform/DRM 
realization/our use-case:
In our virtualized environment Framebuffer 
registration/deregistration(drmModeAddFB2/drmModeRmFB) is  performance costly. 
And de facto useless to do it for every frame, because SurfaceFlinger will not 
reallocate that framebuffer-target's(at least until display resolution won't 

For example: If I allocate several buffers for final composition and register 
them once in DRM. Further, I will copy composition from framebuffer surface 
(provided by SurfaceFlinger) to one of that preallocated buffers and put it on 
a plane, it will be more optimal than do drmModeAddFB2/drmModeRmFB for every 
buffer per composition.

Could you please suggest me how to overcome that situation with buffers 

Kind regards,

dri-devel mailing list

Reply via email to