On Tue, 2 Oct 2018 15:06:14 +0200 Dirk Eibach <dirk.eib...@googlemail.com> wrote:
> Hi Pekka, > > I finally got everything working. I am using gbm_bo_create() and > gbm_bo_get_fd() to get a buffer that is filled by my grabber. Then I > use eglCreateImageKHR() and glEGLImageTargetTexture2DOES() to display > it. Hi Dirk, nice to hear! I suppose that means you still do a copy from the gbm_bo/dmabuf into a window surface? If you used zwp_linux_dmabuf manually from your Wayland client, you could avoid even that copy. It has the same caveat as below though. > My only problem left is that glEGLImageTargetTexture2DOES() does only > accept ARGB8888 and not RGB888, which means I have to waste a lot of > PCIe bandwidth. Any ideas how to get around this? Or what would be a > more appropriate place to post this question? Yeah, I suppose support for true 24-bit-storage formats is rare nowadays. The format list advertised via zwp_linux_dmabuf, visible via e.g. weston-info, can tell you what you could use directly. After all, a Wayland compositor does the same EGLImage import as you do in the simple case. You could probably use the GPU to convert from 24-bit to 32-bit format though, by importing the image as R8 format instead of RGB888 and pretend the width is 3x. Then you could use a fragment shader to sample the real R, G and B separately and write out a 32-bit format image for display. Thanks, pq
pgpzrLJsrcjcr.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
