Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
Hello Giovanni, On Thu, 3 Jul 2014 11:14:48 +0200 Giovanni Campagna scampa.giova...@gmail.com wrote: 2014-07-03 10:48 GMT+02:00 Boris BREZILLON boris.brezil...@free-electrons.com: Hello Giovanni, I have recently been working on a DRM/KMS driver which does not support OpenGL rendering (it only provides plane composition functionalities): [1]. If I understand correctly you patch series might solve some of the issues I am facing. It might get your working EGL, but it's not a complete solution, because buffer management is limited to linear CPU-addressable dumb buffers, which is probably not the most efficient choice (altough how much slower it gets depends on the driver and on the HWl). I'm trying to get wayland working with HW cursor and several planes, the problem is that it depends on GBM to provides drm plane and drm cursor support. I tried to get EGL working with my DRM device and it always ask for an atmel-hlcdc_dri.so module (I have applied this patch [2] to get to this point). First of all, am I mistaken in thinking this series could solve my issue ? Indeed, using my patch stack (patches 2 and 3) you will have a working GBM device that will allocate GPU memory using the dumb interface. If your driver is then able to upload this buffers to the plane HW (or directly capable of allocating in GPU memory), that may be good enough for you. OTOH, this will not provide the wayland clients with the ability to render directly to the plane buffers, because the dumb interface does not provide global names that can be shared between processes, therefore clients will have to render into a shared memory location, that then the wayland compositor (weston, I assume) will have to memcpy into a GBM allocated buffer. If you want to avoid that, you will need to design an ioctl interface for your driver to allocate buffers, then write a winsys for the userspace side that uses those ioctls (directly or through libdrm) - first it allocates the buffer with your driver specific ioctl and then calls GEM_FLINK to get the global name, which can be passed to weston and in there to gbm_bo_import(). If your HW is uncapable of GL rendering (and thus you want to use SW rendering always) is quite likely that your driver will not be that different from dri_kms_swrast, except that will be able to share buffers (patch 3) using GEM names. I'm just curious: what are you using this dri_kms_swrast implementation for ? Okay, my real question here is: Is there other people trying to do what I'm doing or do you need it for another use case :-) ? Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
On 3 July 2014 10:48, Boris BREZILLON boris.brezil...@free-electrons.com wrote: [snip] Perfect! Emil, could you add me in Cc of this future submission ? Of course :) -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
Hello Giovanni, I have recently been working on a DRM/KMS driver which does not support OpenGL rendering (it only provides plane composition functionalities): [1]. If I understand correctly you patch series might solve some of the issues I am facing. I'm trying to get wayland working with HW cursor and several planes, the problem is that it depends on GBM to provides drm plane and drm cursor support. I tried to get EGL working with my DRM device and it always ask for an atmel-hlcdc_dri.so module (I have applied this patch [2] to get to this point). First of all, am I mistaken in thinking this series could solve my issue ? If not, could you tell me on which branch (or which tag) you based your work ? I'm asking this because I tried to apply your patches on top of the master branch (a few days ago), and after fixing some conflict I got a segfault (sorry, I don't have the backtrace anymore :-(, but this was related to negative stride value which was implying faulty memory access). Yesterday I tried to rebase your patches on top of last master branch modifications, and it seems they've completely rework the gallium dri module architecture ([3]) and know I get an 'undefined symbol: dd_create_screen' error when mesa tries to load kms_swrast_dri.so. Sorry if my questions seem stupid to you, but I'm new in graphic related developments :-). Best Regards, Boris [1] https://lkml.org/lkml/2014/6/9/487 [2] http://thread.gmane.org/gmane.comp.video.mesa3d.devel/66385 [3] http://thread.gmane.org/gmane.comp.video.mesa3d.devel/78175 -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
On Thu, 3 Jul 2014 10:48:26 +0200 Boris BREZILLON boris.brezil...@free-electrons.com wrote: Hello Giovanni, I have recently been working on a DRM/KMS driver which does not support OpenGL rendering (it only provides plane composition functionalities): [1]. If I understand correctly you patch series might solve some of the issues I am facing. I'm trying to get wayland working with HW cursor and several planes, the problem is that it depends on GBM to provides drm plane and drm cursor support. Which compositor? All the dependencies are in the compositors, not Wayland per se. If it is Weston, have you tried --use-pixman to avoid EGL altogether? I see Weston still tries to use GBM for cursor fbs, while primary fbs are dumb buffers, but then again, I'm not sure if cursors are supposed to support dumb buffers. Weston's overlay planes code however totally depends on EGL to provide hw-capable buffers from clients. A software renderer support in EGL-DRM won't help in that. Thanks, pq I tried to get EGL working with my DRM device and it always ask for an atmel-hlcdc_dri.so module (I have applied this patch [2] to get to this point). First of all, am I mistaken in thinking this series could solve my issue ? If not, could you tell me on which branch (or which tag) you based your work ? I'm asking this because I tried to apply your patches on top of the master branch (a few days ago), and after fixing some conflict I got a segfault (sorry, I don't have the backtrace anymore :-(, but this was related to negative stride value which was implying faulty memory access). Yesterday I tried to rebase your patches on top of last master branch modifications, and it seems they've completely rework the gallium dri module architecture ([3]) and know I get an 'undefined symbol: dd_create_screen' error when mesa tries to load kms_swrast_dri.so. Sorry if my questions seem stupid to you, but I'm new in graphic related developments :-). Best Regards, Boris [1] https://lkml.org/lkml/2014/6/9/487 [2] http://thread.gmane.org/gmane.comp.video.mesa3d.devel/66385 [3] http://thread.gmane.org/gmane.comp.video.mesa3d.devel/78175 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
On Thu, 3 Jul 2014 11:14:48 +0200 Giovanni Campagna scampa.giova...@gmail.com wrote: 2014-07-03 10:48 GMT+02:00 Boris BREZILLON boris.brezil...@free-electrons.com: Hello Giovanni, I have recently been working on a DRM/KMS driver which does not support OpenGL rendering (it only provides plane composition functionalities): [1]. If I understand correctly you patch series might solve some of the issues I am facing. It might get your working EGL, but it's not a complete solution, because buffer management is limited to linear CPU-addressable dumb buffers, which is probably not the most efficient choice (altough how much slower it gets depends on the driver and on the HWl). I'm only providing DUMB ioctls (through the CMA GEM implementation), so it should be enough for me, isn't it. I'm trying to get wayland working with HW cursor and several planes, the problem is that it depends on GBM to provides drm plane and drm cursor support. I tried to get EGL working with my DRM device and it always ask for an atmel-hlcdc_dri.so module (I have applied this patch [2] to get to this point). First of all, am I mistaken in thinking this series could solve my issue ? Indeed, using my patch stack (patches 2 and 3) you will have a working GBM device that will allocate GPU memory using the dumb interface. If your driver is then able to upload this buffers to the plane HW (or directly capable of allocating in GPU memory), that may be good enough for you. OTOH, this will not provide the wayland clients with the ability to render directly to the plane buffers, because the dumb interface does not provide global names that can be shared between processes, therefore clients will have to render into a shared memory location, that then the wayland compositor (weston, I assume) will have to memcpy into a GBM allocated buffer. Indeed, I'm using weston (just forgot to mention it). If you want to avoid that, you will need to design an ioctl interface for your driver to allocate buffers, then write a winsys for the userspace side that uses those ioctls (directly or through libdrm) - first it allocates the buffer with your driver specific ioctl and then calls GEM_FLINK to get the global name, which can be passed to weston and in there to gbm_bo_import(). If your HW is uncapable of GL rendering (and thus you want to use SW rendering always) is quite likely that your driver will not be that different from dri_kms_swrast, except that will be able to share buffers (patch 3) using GEM names. Okay, thanks for these enlightenment. I'll try to get the dri_kms_swrast first and then see if I need performance improvements ;-). If not, could you tell me on which branch (or which tag) you based your work ? I'm asking this because I tried to apply your patches on top of the master branch (a few days ago), and after fixing some conflict I got a segfault (sorry, I don't have the backtrace anymore :-(, but this was related to negative stride value which was implying faulty memory access). The patches were made against an old version of mesa, and the build system was updated meanwhile. Emil said he will rebase them, and that will happen in a couple days. You should just wait until they land. Perfect! Emil, could you add me in Cc of this future submission ? Thanks for taking the time to answer to my questions. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
On Thu, 3 Jul 2014 12:24:44 +0300 Pekka Paalanen ppaala...@gmail.com wrote: On Thu, 3 Jul 2014 10:48:26 +0200 Boris BREZILLON boris.brezil...@free-electrons.com wrote: Hello Giovanni, I have recently been working on a DRM/KMS driver which does not support OpenGL rendering (it only provides plane composition functionalities): [1]. If I understand correctly you patch series might solve some of the issues I am facing. I'm trying to get wayland working with HW cursor and several planes, the problem is that it depends on GBM to provides drm plane and drm cursor support. Which compositor? All the dependencies are in the compositors, not Wayland per se. Sorry, I meant weston not wayland. If it is Weston, have you tried --use-pixman to avoid EGL altogether? I see Weston still tries to use GBM for cursor fbs, while primary fbs are dumb buffers, but then again, I'm not sure if cursors are supposed to support dumb buffers. Yes weston works fine with --use-pixman, but then I can't use HW cursor and drm overlay planes (because it requires gbm). Weston's overlay planes code however totally depends on EGL to provide hw-capable buffers from clients. A software renderer support in EGL-DRM won't help in that. Okay, if I understand correctly, this means I'll have to implement an atmel-hlcdc_dri.so module (as suggested by Giovanni), right ? Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
On Thu, 3 Jul 2014 12:10:36 +0200 Boris BREZILLON boris.brezil...@free-electrons.com wrote: On Thu, 3 Jul 2014 12:24:44 +0300 Pekka Paalanen ppaala...@gmail.com wrote: On Thu, 3 Jul 2014 10:48:26 +0200 Boris BREZILLON boris.brezil...@free-electrons.com wrote: Hello Giovanni, I have recently been working on a DRM/KMS driver which does not support OpenGL rendering (it only provides plane composition functionalities): [1]. If I understand correctly you patch series might solve some of the issues I am facing. I'm trying to get wayland working with HW cursor and several planes, the problem is that it depends on GBM to provides drm plane and drm cursor support. Which compositor? All the dependencies are in the compositors, not Wayland per se. Sorry, I meant weston not wayland. If it is Weston, have you tried --use-pixman to avoid EGL altogether? I see Weston still tries to use GBM for cursor fbs, while primary fbs are dumb buffers, but then again, I'm not sure if cursors are supposed to support dumb buffers. Yes weston works fine with --use-pixman, but then I can't use HW cursor and drm overlay planes (because it requires gbm). Weston's overlay planes code however totally depends on EGL to provide hw-capable buffers from clients. A software renderer support in EGL-DRM won't help in that. Okay, if I understand correctly, this means I'll have to implement an atmel-hlcdc_dri.so module (as suggested by Giovanni), right ? Well, uhh, I suppose... That means you need to get clients actually rendering into hw-capable buffers, so that usually means having a GL(ES) rendering working on EGL Wayland platform, too. Or, clients could use something like libva(?) to fill the buffers and use Mesa's internal wl_drm protocol to pass those to the compositor. If the compositor is able to initialize EGL_WL_bind_wayland_display extension, then with Mesa, the clients will have wl_drm available. Still probably requires working GLESv2 rendering for the EGL DRM/GBM platform, because the pixman renderer cannot handle anything else than wl_shm buffers. Or, you migh hack Weston to copy pixels from wl_shm buffers into dumb buffers, and put those into overlays (err, did dumb buffers support going on overlays, or were they primary plane only?). But if you have like less than 10 overlays in hw, that might be a net lose in performance. Or, you might go wild and have a hack on my hacky zlinux_dmabuf support in weston: http://cgit.collabora.com/git/user/pq/weston.git/log/?h=dmabuf-WIP It is missing pixman-renderer integration, and the test client is intel-only, but if you hack around those, you can have clients filling dmabufs, sending those to Weston, and Weston using GBM to import them to put them on overlays via DRM - unless the scenegraph forces them to go through pixman-renderer in which case you are in a slight pickle. Warning: that weston branch may get rewritten or deleted without notice. I guess the take-away from this is that DRM overlay planes have not really been considered for use with server nor client software rendering in Weston. Thanks, pq ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
On Thu, 3 Jul 2014 13:49:06 +0300 Pekka Paalanen ppaala...@gmail.com wrote: On Thu, 3 Jul 2014 12:10:36 +0200 Boris BREZILLON boris.brezil...@free-electrons.com wrote: On Thu, 3 Jul 2014 12:24:44 +0300 Pekka Paalanen ppaala...@gmail.com wrote: On Thu, 3 Jul 2014 10:48:26 +0200 Boris BREZILLON boris.brezil...@free-electrons.com wrote: Hello Giovanni, I have recently been working on a DRM/KMS driver which does not support OpenGL rendering (it only provides plane composition functionalities): [1]. If I understand correctly you patch series might solve some of the issues I am facing. I'm trying to get wayland working with HW cursor and several planes, the problem is that it depends on GBM to provides drm plane and drm cursor support. Which compositor? All the dependencies are in the compositors, not Wayland per se. Sorry, I meant weston not wayland. If it is Weston, have you tried --use-pixman to avoid EGL altogether? I see Weston still tries to use GBM for cursor fbs, while primary fbs are dumb buffers, but then again, I'm not sure if cursors are supposed to support dumb buffers. Yes weston works fine with --use-pixman, but then I can't use HW cursor and drm overlay planes (because it requires gbm). Weston's overlay planes code however totally depends on EGL to provide hw-capable buffers from clients. A software renderer support in EGL-DRM won't help in that. Okay, if I understand correctly, this means I'll have to implement an atmel-hlcdc_dri.so module (as suggested by Giovanni), right ? Well, uhh, I suppose... That means you need to get clients actually rendering into hw-capable buffers, so that usually means having a GL(ES) rendering working on EGL Wayland platform, too. Or, clients could use something like libva(?) to fill the buffers and use Mesa's internal wl_drm protocol to pass those to the compositor. If the compositor is able to initialize EGL_WL_bind_wayland_display extension, then with Mesa, the clients will have wl_drm available. Still probably requires working GLESv2 rendering for the EGL DRM/GBM platform, because the pixman renderer cannot handle anything else than wl_shm buffers. Or, you migh hack Weston to copy pixels from wl_shm buffers into dumb buffers, and put those into overlays (err, did dumb buffers support going on overlays, or were they primary plane only?). But if you have like less than 10 overlays in hw, that might be a net lose in performance. I have, at most, 3 overlays (it depends on the HLCDC IP version), so this might be an acceptable solution. ITOH, I'd like to keep the implementation as clean as possible in order to be able to base future work on offical weston versions (and tell me if I'm wrong, but I'm not sure the proposed solution can ever make it to the official weston version). Or, you might go wild and have a hack on my hacky zlinux_dmabuf support in weston: http://cgit.collabora.com/git/user/pq/weston.git/log/?h=dmabuf-WIP It is missing pixman-renderer integration, and the test client is intel-only, but if you hack around those, you can have clients filling dmabufs, sending those to Weston, and Weston using GBM to import them to put them on overlays via DRM - unless the scenegraph forces them to go through pixman-renderer in which case you are in a slight pickle. That sounds interesting! I'll take a closer look at it. Warning: that weston branch may get rewritten or deleted without notice. I guess the take-away from this is that DRM overlay planes have not really been considered for use with server nor client software rendering in Weston. Yes, I kinda realize that know. My main goal here is to provide a video player demo application where the primary plane (or an overlay plane) is used to display video player controls (play, pause, ...) and another plane is used to display video content (using gstreamer or any other alternative). This needs to be done using overlays in order to get acceptable performances (avoid software rendering for plane composition), and thus should use drm overlay planes. I thought about developing or using an existing Qt application, but AFAIU, the problem remains the same with Qt DRM/KMS backend: it depends on EGL/GBM. Please let me know if you have any other ideas. Thanks. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
On Thu, 3 Jul 2014 14:15:34 +0200 Boris BREZILLON boris.brezil...@free-electrons.com wrote: On Thu, 3 Jul 2014 13:49:06 +0300 Pekka Paalanen ppaala...@gmail.com wrote: On Thu, 3 Jul 2014 12:10:36 +0200 Boris BREZILLON boris.brezil...@free-electrons.com wrote: On Thu, 3 Jul 2014 12:24:44 +0300 Pekka Paalanen ppaala...@gmail.com wrote: Weston's overlay planes code however totally depends on EGL to provide hw-capable buffers from clients. A software renderer support in EGL-DRM won't help in that. Okay, if I understand correctly, this means I'll have to implement an atmel-hlcdc_dri.so module (as suggested by Giovanni), right ? Well, uhh, I suppose... That means you need to get clients actually rendering into hw-capable buffers, so that usually means having a GL(ES) rendering working on EGL Wayland platform, too. Or, clients could use something like libva(?) to fill the buffers and use Mesa's internal wl_drm protocol to pass those to the compositor. If the compositor is able to initialize EGL_WL_bind_wayland_display extension, then with Mesa, the clients will have wl_drm available. Still probably requires working GLESv2 rendering for the EGL DRM/GBM platform, because the pixman renderer cannot handle anything else than wl_shm buffers. Or, you migh hack Weston to copy pixels from wl_shm buffers into dumb buffers, and put those into overlays (err, did dumb buffers support going on overlays, or were they primary plane only?). But if you have like less than 10 overlays in hw, that might be a net lose in performance. I have, at most, 3 overlays (it depends on the HLCDC IP version), so this might be an acceptable solution. ITOH, I'd like to keep the implementation as clean as possible in order to be able to base future work on offical weston versions (and tell me if I'm wrong, but I'm not sure the proposed solution can ever make it to the official weston version). Or, you might go wild and have a hack on my hacky zlinux_dmabuf support in weston: http://cgit.collabora.com/git/user/pq/weston.git/log/?h=dmabuf-WIP It is missing pixman-renderer integration, and the test client is intel-only, but if you hack around those, you can have clients filling dmabufs, sending those to Weston, and Weston using GBM to import them to put them on overlays via DRM - unless the scenegraph forces them to go through pixman-renderer in which case you are in a slight pickle. That sounds interesting! I'll take a closer look at it. Note, that the protocol there does not address the problem of compatibility at all, and the implementation does not even advertise any pixel formats. It is all based on luck and clairvoyance, that the client just happens to create exactly the right kind of dmabufs that the compositor can use. If you fail that, the client gets kicked or you get a mess on the screen. Obviously not upstreamable material. ;-) Warning: that weston branch may get rewritten or deleted without notice. I guess the take-away from this is that DRM overlay planes have not really been considered for use with server nor client software rendering in Weston. Yes, I kinda realize that know. My main goal here is to provide a video player demo application where the primary plane (or an overlay plane) is used to display video player controls (play, pause, ...) and another plane is used to display video content (using gstreamer or any other alternative). This needs to be done using overlays in order to get acceptable performances (avoid software rendering for plane composition), and thus should use drm overlay planes. Oh, a video player! How do you get the video frames? Do you have hardware decoding? Can you perhaps decode straight into dmabufs? If yes, then you could use zlinux_dmabuf to throw those video frames to Weston zero-copy. Then the tricky part is to make Weston cope with those video frame buffers, as if they even attempt to go through the pixman-renderer, Weston will... hm, not sure what it does, but it won't work. So you have to somehow guarantee, that the surface which those buffers are targeting will *always* be assigned to an overlay. That may be a fair amount of hacking. Good luck! :-) Thanks, pq ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
On Thu, 3 Jul 2014 15:46:14 +0300 Pekka Paalanen ppaala...@gmail.com wrote: On Thu, 3 Jul 2014 14:15:34 +0200 Boris BREZILLON boris.brezil...@free-electrons.com wrote: On Thu, 3 Jul 2014 13:49:06 +0300 Pekka Paalanen ppaala...@gmail.com wrote: On Thu, 3 Jul 2014 12:10:36 +0200 Boris BREZILLON boris.brezil...@free-electrons.com wrote: On Thu, 3 Jul 2014 12:24:44 +0300 Pekka Paalanen ppaala...@gmail.com wrote: Weston's overlay planes code however totally depends on EGL to provide hw-capable buffers from clients. A software renderer support in EGL-DRM won't help in that. Okay, if I understand correctly, this means I'll have to implement an atmel-hlcdc_dri.so module (as suggested by Giovanni), right ? Well, uhh, I suppose... That means you need to get clients actually rendering into hw-capable buffers, so that usually means having a GL(ES) rendering working on EGL Wayland platform, too. Or, clients could use something like libva(?) to fill the buffers and use Mesa's internal wl_drm protocol to pass those to the compositor. If the compositor is able to initialize EGL_WL_bind_wayland_display extension, then with Mesa, the clients will have wl_drm available. Still probably requires working GLESv2 rendering for the EGL DRM/GBM platform, because the pixman renderer cannot handle anything else than wl_shm buffers. Or, you migh hack Weston to copy pixels from wl_shm buffers into dumb buffers, and put those into overlays (err, did dumb buffers support going on overlays, or were they primary plane only?). But if you have like less than 10 overlays in hw, that might be a net lose in performance. I have, at most, 3 overlays (it depends on the HLCDC IP version), so this might be an acceptable solution. ITOH, I'd like to keep the implementation as clean as possible in order to be able to base future work on offical weston versions (and tell me if I'm wrong, but I'm not sure the proposed solution can ever make it to the official weston version). Or, you might go wild and have a hack on my hacky zlinux_dmabuf support in weston: http://cgit.collabora.com/git/user/pq/weston.git/log/?h=dmabuf-WIP It is missing pixman-renderer integration, and the test client is intel-only, but if you hack around those, you can have clients filling dmabufs, sending those to Weston, and Weston using GBM to import them to put them on overlays via DRM - unless the scenegraph forces them to go through pixman-renderer in which case you are in a slight pickle. That sounds interesting! I'll take a closer look at it. Note, that the protocol there does not address the problem of compatibility at all, and the implementation does not even advertise any pixel formats. It is all based on luck and clairvoyance, that the client just happens to create exactly the right kind of dmabufs that the compositor can use. If you fail that, the client gets kicked or you get a mess on the screen. Obviously not upstreamable material. ;-) Warning: that weston branch may get rewritten or deleted without notice. I guess the take-away from this is that DRM overlay planes have not really been considered for use with server nor client software rendering in Weston. Yes, I kinda realize that know. My main goal here is to provide a video player demo application where the primary plane (or an overlay plane) is used to display video player controls (play, pause, ...) and another plane is used to display video content (using gstreamer or any other alternative). This needs to be done using overlays in order to get acceptable performances (avoid software rendering for plane composition), and thus should use drm overlay planes. Oh, a video player! How do you get the video frames? Do you have hardware decoding? Can you perhaps decode straight into dmabufs? If yes, then you could use zlinux_dmabuf to throw those video frames to Weston zero-copy. Then the tricky part is to make Weston cope with those video frame buffers, as if they even attempt to go through the pixman-renderer, Weston will... hm, not sure what it does, but it won't work. So you have to somehow guarantee, that the surface which those buffers are targeting will *always* be assigned to an overlay. Some SoCs have an HW decoder and yes I had dmabuf in mind to provide zero copy from video decoder to DRM device ;-). But I'm not even sure this video decoder is supported in mainline and I'd like to get software decoding working first :-). That may be a fair amount of hacking. Good luck! :-) Yes that's what I'm realizing now. I thought the kernel driver would be the most complicated part, but now that I'm working on user space support I'd say developing the driver was quite easy :-). Thanks for your support. Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
2014-07-03 10:48 GMT+02:00 Boris BREZILLON boris.brezil...@free-electrons.com: Hello Giovanni, I have recently been working on a DRM/KMS driver which does not support OpenGL rendering (it only provides plane composition functionalities): [1]. If I understand correctly you patch series might solve some of the issues I am facing. It might get your working EGL, but it's not a complete solution, because buffer management is limited to linear CPU-addressable dumb buffers, which is probably not the most efficient choice (altough how much slower it gets depends on the driver and on the HWl). I'm trying to get wayland working with HW cursor and several planes, the problem is that it depends on GBM to provides drm plane and drm cursor support. I tried to get EGL working with my DRM device and it always ask for an atmel-hlcdc_dri.so module (I have applied this patch [2] to get to this point). First of all, am I mistaken in thinking this series could solve my issue ? Indeed, using my patch stack (patches 2 and 3) you will have a working GBM device that will allocate GPU memory using the dumb interface. If your driver is then able to upload this buffers to the plane HW (or directly capable of allocating in GPU memory), that may be good enough for you. OTOH, this will not provide the wayland clients with the ability to render directly to the plane buffers, because the dumb interface does not provide global names that can be shared between processes, therefore clients will have to render into a shared memory location, that then the wayland compositor (weston, I assume) will have to memcpy into a GBM allocated buffer. If you want to avoid that, you will need to design an ioctl interface for your driver to allocate buffers, then write a winsys for the userspace side that uses those ioctls (directly or through libdrm) - first it allocates the buffer with your driver specific ioctl and then calls GEM_FLINK to get the global name, which can be passed to weston and in there to gbm_bo_import(). If your HW is uncapable of GL rendering (and thus you want to use SW rendering always) is quite likely that your driver will not be that different from dri_kms_swrast, except that will be able to share buffers (patch 3) using GEM names. If not, could you tell me on which branch (or which tag) you based your work ? I'm asking this because I tried to apply your patches on top of the master branch (a few days ago), and after fixing some conflict I got a segfault (sorry, I don't have the backtrace anymore :-(, but this was related to negative stride value which was implying faulty memory access). The patches were made against an old version of mesa, and the build system was updated meanwhile. Emil said he will rebase them, and that will happen in a couple days. You should just wait until they land. Giovanni ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
On 15/06/14 12:49, Giovanni Campagna wrote: Hello all, This is the third attempt at swrast/llvmpipe support for DRM drivers that don't have userspace support (qxl, cirrus, simpledrm, etc.) I hope I addressed all of Emil's comments. Thanks for keeping up with my nit-picking Giovanni. Pretty much everything looks great imho, just one silly question that slippe through the cracks: Why do you insist on using LIBGL env var when you're dealing with EGL/GBM ? IMHO the name is quite explanatory (meant/used by libGL), it may cause us some headaches if we try to go with one variable that rules them all approach. With that said, I would prefer (unless someone objects) if we push these after my long series of reshuffling the gallium targets has done in. I would gladly rebase this 3 patches over the 20+ one that I have. Thanks again. Emil Giovanni ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
On Mon, 16 Jun 2014 17:15:47 +0200 Giovanni Campagna scampa.giova...@gmail.com wrote: 2014-06-16 7:47 GMT+02:00 Pekka Paalanen ppaala...@gmail.com: On Sun, 15 Jun 2014 13:49:48 +0200 Giovanni Campagna scampa.giova...@gmail.com wrote: Hello all, This is the third attempt at swrast/llvmpipe support for DRM drivers that don't have userspace support (qxl, cirrus, simpledrm, etc.) I hope I addressed all of Emil's comments. Hi, this sounds cool work to me, sorry I can't really review it. Does this work also help in getting llvmpipe working with the egl_dri2 loader? If you mean in wayland, unfortunately no. Each egl platform has to implement buffer uploading differently, so the code paths are different. This patchset only tackles the DRM platform, which means mutter, weston and other wayland compositors can run with llvmpipe, but their clients will not have working egl. Yes, that was clear to me. AFAIU, currently on EGL-Wayland the only way to use llvmpipe is to use egl_gallium.so as the loader, and I don't really know what it would take to make egl_dri2 work there, apart from the Wayland-specific bits, so I was kind of hoping your work would make that easier to implement. In the end, the simple way is to implement swrastGetImage and swrastPutImage for the wayland platform, using an shm backed buffer. It would look similar to the platform_drm side (because the way drm and wayland do double buffering is quite similar, and because both are incapable of front-buffer rendering, single-buffer rendering or rendering to foreign windows), but no real code sharing. OTOH, in wayland buffer sharing exists, so it would be hugely inefficient to implement swrast support this way (it incures one extra copy, from the malloc backbuffer to the shm fake frontbuffer). It should be possible to design an swrast2 interface in terms of shm FDs, similar to prime/dma-buf FDs, and with similar semantics, just nobody is working on it right now. Ookay... I maybe got half of that, but no worries. :-) I was just under the impression, that some larger infrastructural work was needed before egl_dri2 could work with software renderers, and I was hoping your work do at least part of that infrastructure. Doesn't matter, I was just curious. :-) Thanks, pq ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
2014-06-16 7:47 GMT+02:00 Pekka Paalanen ppaala...@gmail.com: On Sun, 15 Jun 2014 13:49:48 +0200 Giovanni Campagna scampa.giova...@gmail.com wrote: Hello all, This is the third attempt at swrast/llvmpipe support for DRM drivers that don't have userspace support (qxl, cirrus, simpledrm, etc.) I hope I addressed all of Emil's comments. Hi, this sounds cool work to me, sorry I can't really review it. Does this work also help in getting llvmpipe working with the egl_dri2 loader? If you mean in wayland, unfortunately no. Each egl platform has to implement buffer uploading differently, so the code paths are different. This patchset only tackles the DRM platform, which means mutter, weston and other wayland compositors can run with llvmpipe, but their clients will not have working egl. AFAIU, currently on EGL-Wayland the only way to use llvmpipe is to use egl_gallium.so as the loader, and I don't really know what it would take to make egl_dri2 work there, apart from the Wayland-specific bits, so I was kind of hoping your work would make that easier to implement. In the end, the simple way is to implement swrastGetImage and swrastPutImage for the wayland platform, using an shm backed buffer. It would look similar to the platform_drm side (because the way drm and wayland do double buffering is quite similar, and because both are incapable of front-buffer rendering, single-buffer rendering or rendering to foreign windows), but no real code sharing. OTOH, in wayland buffer sharing exists, so it would be hugely inefficient to implement swrast support this way (it incures one extra copy, from the malloc backbuffer to the shm fake frontbuffer). It should be possible to design an swrast2 interface in terms of shm FDs, similar to prime/dma-buf FDs, and with similar semantics, just nobody is working on it right now. Giovanni ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
Hello all, This is the third attempt at swrast/llvmpipe support for DRM drivers that don't have userspace support (qxl, cirrus, simpledrm, etc.) I hope I addressed all of Emil's comments. Giovanni ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
On Sun, 15 Jun 2014 13:49:48 +0200 Giovanni Campagna scampa.giova...@gmail.com wrote: Hello all, This is the third attempt at swrast/llvmpipe support for DRM drivers that don't have userspace support (qxl, cirrus, simpledrm, etc.) I hope I addressed all of Emil's comments. Hi, this sounds cool work to me, sorry I can't really review it. Does this work also help in getting llvmpipe working with the egl_dri2 loader? AFAIU, currently on EGL-Wayland the only way to use llvmpipe is to use egl_gallium.so as the loader, and I don't really know what it would take to make egl_dri2 work there, apart from the Wayland-specific bits, so I was kind of hoping your work would make that easier to implement. Thanks, pq ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
