dmabuf modifiers for HW overlays

Martin Stransky stransky at redhat.com
Fri Aug 2 13:41:15 UTC 2019


On 8/2/19 1:48 PM, Scott Anderson wrote:
> On 2/08/19 10:19 pm, Martin Stransky wrote:
>> On 8/2/19 12:04 PM, Martin Stransky wrote:
>>>>> Also I wonder if it's feasible to use any modifiers as I need
>>>>> plain/linear buffer to draw into by skia. I suspect when I create the
>>>>> buffer with modifiers and then I map it to CPU memory for SW drawing,
>>>>> intermediate buffer is created and then the pixels are de-composed 
>>>>> back
>>>>> to GPU memory.
>>>>
>>>> No, I don't believe there is any kind of intermediate buffer behind the
>>>> scenes in GBM or dmabuf ioctls/mmap. OpenGL drivers may use
>>>> intermediate buffers. Some EGLImage operations are allowed to create
>>>> more buffers behind the scenes but I think implementations try to avoid
>>>> it. Copies are bad for performance, and implicit copies are unexpected
>>>> performance bottle-necks. So yes, I believe you very much need to
>>>> ensure the buffer gets allocated as linear from the start.
>>>>
>>>> Some hardware may have hardware tiling units, that may be able to
>>>> represent a linear CPU view into a tiled buffer, but I know very little
>>>> of that. I think they might need driver-specific ioctls to use or
>>>> something, and are a scarce resource.
>>
>> The HW overlays is another use-case I'm working on. I want to draw 2D 
>> data to dmabuf buffer by CPU and send it directly to GPU to render 
>> from (bind as wl_buffer and attach it to wl_subsurface). I guess it 
>> also depends on compositor how to handles that and how does that 
>> handle mutter?. Does mutter such dmabuf buffer pass directly to GPU?
>  >
>> Also is it feasible to use *any* modifiers here and which flags should 
>> I pass to gbm_bo_create()? I want to use plain DRM_FORMAT_ARGB8888 for 
>> the dmabuf buffer as it's easy to draw into but I wonder if that 
>> buffer can be used by GPU directly for compositing and how effective 
>> is tha >
>> Thanks,
>> ma
> As the client, you don't need to try do the compositor's/driver's job 
> for it. If you want CPU accessable buffers, just use wl_shm. Trying to 
> push CPU data into a dmabuf directly can potentially hurt more than it 
> helps. You should benchmark if that actually leads to increased 
> performance, especially across different hardware/drivers.

Yes, I suppose that will be optional.

> Regarding overlays, a pending change to wp_linux_dmabuf [1] would give 
> the client more information about how to allocate its GPU buffers so 
> that's it's more likely to work with hardware overlays or be more 
> efficient in general, but it's a complicated thing to get correct, and 
> it'll never be perfect.

Great, thanks!

> I'm also puzzled as to why you would need to use GBM directly. Some 
> clients have a justified use for it, but most don't, and is mainly 
> useful for display servers instead. Are the EGL/OpenGL APIs not sufficient?

Recently video playback at Firefox drains your laptop battery reliably 
under Linux and improvement would be great. Also fullscreen video 
playback can benefit from it.

ma.

  > Scott
> 
> [1]: 
> https://lists.freedesktop.org/archives/wayland-devel/2018-November/039660.html 
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel


-- 
Martin Stransky
Software Engineer / Red Hat, Inc


More information about the wayland-devel mailing list