| Message ID | 20230425073012.11036-1-marius.vlad@collabora.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm/vkms: Add support for multiple pipes | expand |
We're doing/planning on doing similar or related work here at chromium. https://patchwork.kernel.org/project/dri-devel/list/?series=662676&submitter=&state=&q=&delegate=&archive=both Here's the stuff we have now (we're currently rebasing and touching it up, myself and @Yi Xie <yixie@google.com> will be taking over this work. Our plans are to add configFS changes and DRI VKMS changes to be able to add and remove virtual displays at runtime (among other things needed for our own testing purposes for our Exo wayland implementation). We're still learning how this all works and comes together, but it is worth letting you know "us too" We can chat more and see where we overlap and can learn from each other :) On Tue, Apr 25, 2023 at 4:30 PM Marius Vlad <marius.vlad@collabora.com> wrote: > With multiple pipe available we can perform management of outputs at > a more granular level, such that we're able to turn off or on several > outputs at a time, or combinations that arise from doing that. > > The Weston project use VKMS when running its test suite in CI, and we > have now uses cases which would need to ability to set-up the outputs > DPMS/state individually, rather than globally -- which would affect all > outputs. This an attempt on fixing that by giving the possibility to > create more than one pipe, and thus allowing to run tests that could > exercise code paths in the compositor related to management of outputs. > > v3: > - Apply the series against drm-misc-next (Maíra Canal) > - Add a lower range check to avoid passing negative values to > max_pipes (Maíra Canal) > > v2: > - Replace 'outputs' with 'pipes' as to use the proper terminology > (Thomas Zimmermann, Maíra Canal) > - Fixed passing wrong possible_crtc bitmask when initializing the > write back connector which address kms_writeback failure (Maíra Canal) > - Add a feat. note about moving overlay planes between CRTCs (Melissa > Wen) > > Marius Vlad (3): > vkms: Pass the correct bitmask for possible crtcs > vkms: Add support for multiple pipes > Documentation/gpu/vkms.rst: Added a note about plane migration > > Documentation/gpu/vkms.rst | 5 +++-- > drivers/gpu/drm/vkms/vkms_crtc.c | 3 +-- > drivers/gpu/drm/vkms/vkms_drv.c | 31 +++++++++++++++++++++------ > drivers/gpu/drm/vkms/vkms_drv.h | 12 ++++++++--- > drivers/gpu/drm/vkms/vkms_output.c | 7 +++--- > drivers/gpu/drm/vkms/vkms_writeback.c | 24 ++++++++++----------- > 6 files changed, 53 insertions(+), 29 deletions(-) > > -- > 2.39.2 > >
Hi Brandon, Xie, Thanks for reaching out, and for the heads-up. I need to take a closer look, but by glancing over it, using configFS would be really awesome. Think we could really benefit from having that in our CI and being able to customize the entire pipeline. I'm totally for that. It looks like it requires some infra work so I guess landing that might require quite a bit of time. Not sure if there are recent updates for it. My changes are quite trivial and much more focused on just having multiple virtual displays, so IDK, I've submitted a version that seems to work, so I guess others should or would decide if we should drop mine and focus on the configFS series, or we should go with configFS as a follow-up. Would have liked to get something in the tree so we can at least have something to work with. Thoughts on the matter on how should we go about it? On 4/26/23 05:06, Brandon Ross Pollack wrote: > We're doing/planning on doing similar or related work here at chromium. > > https://patchwork.kernel.org/project/dri-devel/list/?series=662676&submitter=&state=&q=&delegate=&archive=both <https://patchwork.kernel.org/project/dri-devel/list/?series=662676&submitter=&state=&q=&delegate=&archive=both> > > Here's the stuff we have now (we're currently rebasing and touching it > up, myself and @Yi Xie <mailto:yixie@google.com> will be taking over > this work. > > Our plans are to add configFS changes and DRI VKMS changes to be able to > add and remove virtual displays at runtime (among other things needed > for our own testing purposes for our Exo wayland implementation). > > We're still learning how this all works and comes together, but it is > worth letting you know "us too" > > We can chat more and see where we overlap and can learn from each other :) > > On Tue, Apr 25, 2023 at 4:30 PM Marius Vlad <marius.vlad@collabora.com > <mailto:marius.vlad@collabora.com>> wrote: > > With multiple pipe available we can perform management of outputs at > a more granular level, such that we're able to turn off or on several > outputs at a time, or combinations that arise from doing that. > > The Weston project use VKMS when running its test suite in CI, and we > have now uses cases which would need to ability to set-up the outputs > DPMS/state individually, rather than globally -- which would affect all > outputs. This an attempt on fixing that by giving the possibility to > create more than one pipe, and thus allowing to run tests that could > exercise code paths in the compositor related to management of outputs. > > v3: > - Apply the series against drm-misc-next (Maíra Canal) > - Add a lower range check to avoid passing negative values to > max_pipes (Maíra Canal) > > v2: > - Replace 'outputs' with 'pipes' as to use the proper terminology > (Thomas Zimmermann, Maíra Canal) > - Fixed passing wrong possible_crtc bitmask when initializing the > write back connector which address kms_writeback failure (Maíra > Canal) > - Add a feat. note about moving overlay planes between CRTCs > (Melissa Wen) > > Marius Vlad (3): > vkms: Pass the correct bitmask for possible crtcs > vkms: Add support for multiple pipes > Documentation/gpu/vkms.rst: Added a note about plane migration > > Documentation/gpu/vkms.rst | 5 +++-- > drivers/gpu/drm/vkms/vkms_crtc.c | 3 +-- > drivers/gpu/drm/vkms/vkms_drv.c | 31 +++++++++++++++++++++------ > drivers/gpu/drm/vkms/vkms_drv.h | 12 ++++++++--- > drivers/gpu/drm/vkms/vkms_output.c | 7 +++--- > drivers/gpu/drm/vkms/vkms_writeback.c | 24 ++++++++++----------- > 6 files changed, 53 insertions(+), 29 deletions(-) > > -- > 2.39.2 >
I'm adding the original offer of those changes. We talked recently and they have the intent to push forward and merge them. I'm still getting up to speed a bit, but I will probably have a stronger opinion by early next week. On Wed, Apr 26, 2023 at 9:54 PM Marius Vlad <marius.vlad@collabora.com> wrote: > > Hi Brandon, Xie, > > Thanks for reaching out, and for the heads-up. I need to take a closer > look, but by glancing over it, using configFS would be really awesome. > Think we could really benefit from having that in our CI and being able > to customize the entire pipeline. I'm totally for that. > > It looks like it requires some infra work so I guess landing that might > require quite a bit of time. Not sure if there are recent updates for it. > > My changes are quite trivial and much more focused on just having > multiple virtual displays, so IDK, I've submitted a version that seems > to work, so I guess others should or would decide if we should drop mine > and focus on the configFS series, or we should go with configFS as a > follow-up. Would have liked to get something in the tree so we can at > least have something to work with. > > Thoughts on the matter on how should we go about it? > > On 4/26/23 05:06, Brandon Ross Pollack wrote: > > We're doing/planning on doing similar or related work here at chromium. > > > > https://patchwork.kernel.org/project/dri-devel/list/?series=662676&submitter=&state=&q=&delegate=&archive=both <https://patchwork.kernel.org/project/dri-devel/list/?series=662676&submitter=&state=&q=&delegate=&archive=both> > > > > Here's the stuff we have now (we're currently rebasing and touching it > > up, myself and @Yi Xie <mailto:yixie@google.com> will be taking over > > this work. > > > > Our plans are to add configFS changes and DRI VKMS changes to be able to > > add and remove virtual displays at runtime (among other things needed > > for our own testing purposes for our Exo wayland implementation). > > > > We're still learning how this all works and comes together, but it is > > worth letting you know "us too" > > > > We can chat more and see where we overlap and can learn from each other :) > > > > On Tue, Apr 25, 2023 at 4:30 PM Marius Vlad <marius.vlad@collabora.com > > <mailto:marius.vlad@collabora.com>> wrote: > > > > With multiple pipe available we can perform management of outputs at > > a more granular level, such that we're able to turn off or on several > > outputs at a time, or combinations that arise from doing that. > > > > The Weston project use VKMS when running its test suite in CI, and we > > have now uses cases which would need to ability to set-up the outputs > > DPMS/state individually, rather than globally -- which would affect all > > outputs. This an attempt on fixing that by giving the possibility to > > create more than one pipe, and thus allowing to run tests that could > > exercise code paths in the compositor related to management of outputs. > > > > v3: > > - Apply the series against drm-misc-next (Maíra Canal) > > - Add a lower range check to avoid passing negative values to > > max_pipes (Maíra Canal) > > > > v2: > > - Replace 'outputs' with 'pipes' as to use the proper terminology > > (Thomas Zimmermann, Maíra Canal) > > - Fixed passing wrong possible_crtc bitmask when initializing the > > write back connector which address kms_writeback failure (Maíra > > Canal) > > - Add a feat. note about moving overlay planes between CRTCs > > (Melissa Wen) > > > > Marius Vlad (3): > > vkms: Pass the correct bitmask for possible crtcs > > vkms: Add support for multiple pipes > > Documentation/gpu/vkms.rst: Added a note about plane migration > > > > Documentation/gpu/vkms.rst | 5 +++-- > > drivers/gpu/drm/vkms/vkms_crtc.c | 3 +-- > > drivers/gpu/drm/vkms/vkms_drv.c | 31 +++++++++++++++++++++------ > > drivers/gpu/drm/vkms/vkms_drv.h | 12 ++++++++--- > > drivers/gpu/drm/vkms/vkms_output.c | 7 +++--- > > drivers/gpu/drm/vkms/vkms_writeback.c | 24 ++++++++++----------- > > 6 files changed, 53 insertions(+), 29 deletions(-) > > > > -- > > 2.39.2 > >
Hey, all! I am so excited to see other folks excited about extending VKMS. I think it's a great project and has outstanding potential! Life stuff made me AFK for the last few months, but I'm back now and I've been wrapping up the work on the patchset Brandon linked. The current WIP patches are here: https://gitlab.freedesktop.org/jshargo/compositor-kernel-explorations/-/merge_requests/4 They even come with matching IGT tests! https://gitlab.freedesktop.org/jshargo/igt-gpu-tools/-/commit/8375cf128f0811d54ecb4a0b5cf044942ffc67b9 I'm hoping to send them out again soon, hopefully next week. As a suggestion for how to move forward: the first three patches are little refactors that are separable from the core ConfigFS ones (which might have more back-and-forth design iterations). With those three, the param you're adding should be easy to put on top. I can try to get those out sooner for review. What do you think? On Thu, Apr 27, 2023 at 10:51 PM Brandon Ross Pollack <brpol@chromium.org> wrote: > > I'm adding the original offer of those changes. We talked recently > and they have the intent to push forward and merge them. I'm still > getting up to speed a bit, but I will probably have a stronger opinion > by early next week. > > > On Wed, Apr 26, 2023 at 9:54 PM Marius Vlad <marius.vlad@collabora.com> wrote: > > > > Hi Brandon, Xie, > > > > Thanks for reaching out, and for the heads-up. I need to take a closer > > look, but by glancing over it, using configFS would be really awesome. > > Think we could really benefit from having that in our CI and being able > > to customize the entire pipeline. I'm totally for that. > > > > It looks like it requires some infra work so I guess landing that might > > require quite a bit of time. Not sure if there are recent updates for it. > > > > My changes are quite trivial and much more focused on just having > > multiple virtual displays, so IDK, I've submitted a version that seems > > to work, so I guess others should or would decide if we should drop mine > > and focus on the configFS series, or we should go with configFS as a > > follow-up. Would have liked to get something in the tree so we can at > > least have something to work with. > > > > Thoughts on the matter on how should we go about it? > > > > On 4/26/23 05:06, Brandon Ross Pollack wrote: > > > We're doing/planning on doing similar or related work here at chromium. > > > > > > https://patchwork.kernel.org/project/dri-devel/list/?series=662676&submitter=&state=&q=&delegate=&archive=both <https://patchwork.kernel.org/project/dri-devel/list/?series=662676&submitter=&state=&q=&delegate=&archive=both> > > > > > > Here's the stuff we have now (we're currently rebasing and touching it > > > up, myself and @Yi Xie <mailto:yixie@google.com> will be taking over > > > this work. > > > > > > Our plans are to add configFS changes and DRI VKMS changes to be able to > > > add and remove virtual displays at runtime (among other things needed > > > for our own testing purposes for our Exo wayland implementation). > > > > > > We're still learning how this all works and comes together, but it is > > > worth letting you know "us too" > > > > > > We can chat more and see where we overlap and can learn from each other :) > > > > > > On Tue, Apr 25, 2023 at 4:30 PM Marius Vlad <marius.vlad@collabora.com > > > <mailto:marius.vlad@collabora.com>> wrote: > > > > > > With multiple pipe available we can perform management of outputs at > > > a more granular level, such that we're able to turn off or on several > > > outputs at a time, or combinations that arise from doing that. > > > > > > The Weston project use VKMS when running its test suite in CI, and we > > > have now uses cases which would need to ability to set-up the outputs > > > DPMS/state individually, rather than globally -- which would affect all > > > outputs. This an attempt on fixing that by giving the possibility to > > > create more than one pipe, and thus allowing to run tests that could > > > exercise code paths in the compositor related to management of outputs. > > > > > > v3: > > > - Apply the series against drm-misc-next (Maíra Canal) > > > - Add a lower range check to avoid passing negative values to > > > max_pipes (Maíra Canal) > > > > > > v2: > > > - Replace 'outputs' with 'pipes' as to use the proper terminology > > > (Thomas Zimmermann, Maíra Canal) > > > - Fixed passing wrong possible_crtc bitmask when initializing the > > > write back connector which address kms_writeback failure (Maíra > > > Canal) > > > - Add a feat. note about moving overlay planes between CRTCs > > > (Melissa Wen) > > > > > > Marius Vlad (3): > > > vkms: Pass the correct bitmask for possible crtcs > > > vkms: Add support for multiple pipes > > > Documentation/gpu/vkms.rst: Added a note about plane migration > > > > > > Documentation/gpu/vkms.rst | 5 +++-- > > > drivers/gpu/drm/vkms/vkms_crtc.c | 3 +-- > > > drivers/gpu/drm/vkms/vkms_drv.c | 31 +++++++++++++++++++++------ > > > drivers/gpu/drm/vkms/vkms_drv.h | 12 ++++++++--- > > > drivers/gpu/drm/vkms/vkms_output.c | 7 +++--- > > > drivers/gpu/drm/vkms/vkms_writeback.c | 24 ++++++++++----------- > > > 6 files changed, 53 insertions(+), 29 deletions(-) > > > > > > -- > > > 2.39.2 > > >
Sorry for the late reply on my end (last week was a holiday week in Japan). I'm just getting to looking through these closer now, I spent much of my vacation reading about kernel/drivers and things make much more sense now to me so I'll have some notes (hopefully) as well shortly. On Sat, Apr 29, 2023 at 12:10 PM Jim Shargo <jshargo@chromium.org> wrote: > Hey, all! > > I am so excited to see other folks excited about extending VKMS. I > think it's a great project and has outstanding potential! > > Life stuff made me AFK for the last few months, but I'm back now and > I've been wrapping up the work on the patchset Brandon linked. > > The current WIP patches are here: > > https://gitlab.freedesktop.org/jshargo/compositor-kernel-explorations/-/merge_requests/4 > > They even come with matching IGT tests! > > https://gitlab.freedesktop.org/jshargo/igt-gpu-tools/-/commit/8375cf128f0811d54ecb4a0b5cf044942ffc67b9 > > I'm hoping to send them out again soon, hopefully next week. > > As a suggestion for how to move forward: the first three patches are > little refactors that are separable from the core ConfigFS ones (which > might have more back-and-forth design iterations). With those three, > the param you're adding should be easy to put on top. I can try to get > those out sooner for review. > > What do you think? > > > On Thu, Apr 27, 2023 at 10:51 PM Brandon Ross Pollack > <brpol@chromium.org> wrote: > > > > I'm adding the original offer of those changes. We talked recently > > and they have the intent to push forward and merge them. I'm still > > getting up to speed a bit, but I will probably have a stronger opinion > > by early next week. > > > > > > On Wed, Apr 26, 2023 at 9:54 PM Marius Vlad <marius.vlad@collabora.com> > wrote: > > > > > > Hi Brandon, Xie, > > > > > > Thanks for reaching out, and for the heads-up. I need to take a closer > > > look, but by glancing over it, using configFS would be really awesome. > > > Think we could really benefit from having that in our CI and being able > > > to customize the entire pipeline. I'm totally for that. > > > > > > It looks like it requires some infra work so I guess landing that might > > > require quite a bit of time. Not sure if there are recent updates for > it. > > > > > > My changes are quite trivial and much more focused on just having > > > multiple virtual displays, so IDK, I've submitted a version that seems > > > to work, so I guess others should or would decide if we should drop > mine > > > and focus on the configFS series, or we should go with configFS as a > > > follow-up. Would have liked to get something in the tree so we can at > > > least have something to work with. > > > > > > Thoughts on the matter on how should we go about it? > > > > > > On 4/26/23 05:06, Brandon Ross Pollack wrote: > > > > We're doing/planning on doing similar or related work here at > chromium. > > > > > > > > > https://patchwork.kernel.org/project/dri-devel/list/?series=662676&submitter=&state=&q=&delegate=&archive=both > < > https://patchwork.kernel.org/project/dri-devel/list/?series=662676&submitter=&state=&q=&delegate=&archive=both > > > > > > > > > > Here's the stuff we have now (we're currently rebasing and touching > it > > > > up, myself and @Yi Xie <mailto:yixie@google.com> will be taking over > > > > this work. > > > > > > > > Our plans are to add configFS changes and DRI VKMS changes to be > able to > > > > add and remove virtual displays at runtime (among other things needed > > > > for our own testing purposes for our Exo wayland implementation). > > > > > > > > We're still learning how this all works and comes together, but it is > > > > worth letting you know "us too" > > > > > > > > We can chat more and see where we overlap and can learn from each > other :) > > > > > > > > On Tue, Apr 25, 2023 at 4:30 PM Marius Vlad < > marius.vlad@collabora.com > > > > <mailto:marius.vlad@collabora.com>> wrote: > > > > > > > > With multiple pipe available we can perform management of > outputs at > > > > a more granular level, such that we're able to turn off or on > several > > > > outputs at a time, or combinations that arise from doing that. > > > > > > > > The Weston project use VKMS when running its test suite in CI, > and we > > > > have now uses cases which would need to ability to set-up the > outputs > > > > DPMS/state individually, rather than globally -- which would > affect all > > > > outputs. This an attempt on fixing that by giving the > possibility to > > > > create more than one pipe, and thus allowing to run tests that > could > > > > exercise code paths in the compositor related to management of > outputs. > > > > > > > > v3: > > > > - Apply the series against drm-misc-next (Maíra Canal) > > > > - Add a lower range check to avoid passing negative values to > > > > max_pipes (Maíra Canal) > > > > > > > > v2: > > > > - Replace 'outputs' with 'pipes' as to use the proper > terminology > > > > (Thomas Zimmermann, Maíra Canal) > > > > - Fixed passing wrong possible_crtc bitmask when initializing > the > > > > write back connector which address kms_writeback failure > (Maíra > > > > Canal) > > > > - Add a feat. note about moving overlay planes between CRTCs > > > > (Melissa Wen) > > > > > > > > Marius Vlad (3): > > > > vkms: Pass the correct bitmask for possible crtcs > > > > vkms: Add support for multiple pipes > > > > Documentation/gpu/vkms.rst: Added a note about plane migration > > > > > > > > Documentation/gpu/vkms.rst | 5 +++-- > > > > drivers/gpu/drm/vkms/vkms_crtc.c | 3 +-- > > > > drivers/gpu/drm/vkms/vkms_drv.c | 31 > +++++++++++++++++++++------ > > > > drivers/gpu/drm/vkms/vkms_drv.h | 12 ++++++++--- > > > > drivers/gpu/drm/vkms/vkms_output.c | 7 +++--- > > > > drivers/gpu/drm/vkms/vkms_writeback.c | 24 > ++++++++++----------- > > > > 6 files changed, 53 insertions(+), 29 deletions(-) > > > > > > > > -- > > > > 2.39.2 > > > > >
With multiple pipe available we can perform management of outputs at a more granular level, such that we're able to turn off or on several outputs at a time, or combinations that arise from doing that. The Weston project use VKMS when running its test suite in CI, and we have now uses cases which would need to ability to set-up the outputs DPMS/state individually, rather than globally -- which would affect all outputs. This an attempt on fixing that by giving the possibility to create more than one pipe, and thus allowing to run tests that could exercise code paths in the compositor related to management of outputs. v3: - Apply the series against drm-misc-next (Maíra Canal) - Add a lower range check to avoid passing negative values to max_pipes (Maíra Canal) v2: - Replace 'outputs' with 'pipes' as to use the proper terminology (Thomas Zimmermann, Maíra Canal) - Fixed passing wrong possible_crtc bitmask when initializing the write back connector which address kms_writeback failure (Maíra Canal) - Add a feat. note about moving overlay planes between CRTCs (Melissa Wen) Marius Vlad (3): vkms: Pass the correct bitmask for possible crtcs vkms: Add support for multiple pipes Documentation/gpu/vkms.rst: Added a note about plane migration Documentation/gpu/vkms.rst | 5 +++-- drivers/gpu/drm/vkms/vkms_crtc.c | 3 +-- drivers/gpu/drm/vkms/vkms_drv.c | 31 +++++++++++++++++++++------ drivers/gpu/drm/vkms/vkms_drv.h | 12 ++++++++--- drivers/gpu/drm/vkms/vkms_output.c | 7 +++--- drivers/gpu/drm/vkms/vkms_writeback.c | 24 ++++++++++----------- 6 files changed, 53 insertions(+), 29 deletions(-)