All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keiichi Watanabe <keiichiw@chromium.org>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Tomasz Figa" <tfiga@chromium.org>,
	"Dmitry Sepp" <dmitry.sepp@opensynergy.com>,
	spice-devel@lists.freedesktop.org,
	virtio-dev@lists.oasis-open.org,
	"Linux Media Mailing List" <linux-media@vger.kernel.org>,
	"Alexandre Courbot" <acourbot@chromium.org>,
	"Alex Lau" <alexlau@chromium.org>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Dylan Reid" <dgreid@chromium.org>,
	"Enrico Granata" <egranata@google.com>,
	"Frediano Ziglio" <fziglio@redhat.com>,
	"Hans Verkuil" <hverkuil@xs4all.nl>,
	"Stéphane Marchesin" <marcheu@chromium.org>,
	"Pawel Osciak" <posciak@chromium.org>,
	"David Stevens" <stevensd@chromium.org>,
	uril@redhat.com
Subject: Re: [virtio-dev] Re: [PATCH v2 0/1] VirtIO video device specification
Date: Mon, 20 Jan 2020 16:20:03 +0900	[thread overview]
Message-ID: <CAD90VcaAaomTnwVESp9RaBwhjx+cKjXAJv4T7wSkFiCEhOUo5Q@mail.gmail.com> (raw)
In-Reply-To: <20200115112640.52kemwg4lncuvvir@sirius.home.kraxel.org>

Hi,

On Wed, Jan 15, 2020 at 8:26 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
>
>   Hi,
>
> > > If you have (1) hardware you simply can't import buffers with arbitrary
> > > plane offsets, so I'd expect software would prefer the single buffer
> > > layout (i) over (ii), even when using another driver + dmabuf
> > > export/import, to be able to support as much hardware as possible.
> > > So (ii) might end up being unused in practice.
> > >
> > > But maybe not, was just an idea, feel free to scratch it.
> >
> > That's true, simple user space would often do that. However, if more
> > devices are in the game, often some extra alignment or padding between
> > planes is needed and that is not allowed by (1), even though all the
> > planes are in the same buffer.
> >
> > My suggestion, based on the latest V4L2 discussion on unifying the
> > UAPI of i) and ii), is that we may want to instead always specify
> > buffers on a per-plane basis. Any additional requirements would be
> > then validated by the host, which could check if the planes end up in
> > the same buffer (or different buffers for (3)) and/or at the right
> > offsets.
>
> Hmm, using (ii) the API, then check whenever your three plane buffers
> happen to have the correct layout for (1) hardware looks somewhat
> backwards to me.

Can't this problem be solved by adding "offset" field in virtio_video_mem_entry?

struct virtio_video_mem_entry {
  le64 addr;
  le32 length;
  le32 offset;
  u8 padding[4];
};

Here, "addr" must be the same in every mem_entry for (1) hardware.

>
> I'd suggest to use (i) API and allow the device specify alignment
> requirements.  So (1) hardware would say "need_align=0", whereas (3)
> hardware would probably say "need_align=PAGE_SIZE" so it can easily
> split the single buffer into three per-plane buffers.

Just to confirm, is "need_align" a field added in virtio_video_format_desc?
It sounds workable, too.

Best regards,
Keiichi


>
> cheers,
>   Gerd
>

WARNING: multiple messages have this Message-ID (diff)
From: Keiichi Watanabe <keiichiw@chromium.org>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Tomasz Figa" <tfiga@chromium.org>,
	"Dmitry Sepp" <dmitry.sepp@opensynergy.com>,
	spice-devel@lists.freedesktop.org,
	virtio-dev@lists.oasis-open.org,
	"Linux Media Mailing List" <linux-media@vger.kernel.org>,
	"Alexandre Courbot" <acourbot@chromium.org>,
	"Alex Lau" <alexlau@chromium.org>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Dylan Reid" <dgreid@chromium.org>,
	"Enrico Granata" <egranata@google.com>,
	"Frediano Ziglio" <fziglio@redhat.com>,
	"Hans Verkuil" <hverkuil@xs4all.nl>,
	"Stéphane Marchesin" <marcheu@chromium.org>,
	"Pawel Osciak" <posciak@chromium.org>,
	"David Stevens" <stevensd@chromium.org>,
	uril@redhat.com
Subject: Re: [virtio-dev] Re: [PATCH v2 0/1] VirtIO video device specification
Date: Mon, 20 Jan 2020 16:20:03 +0900	[thread overview]
Message-ID: <CAD90VcaAaomTnwVESp9RaBwhjx+cKjXAJv4T7wSkFiCEhOUo5Q@mail.gmail.com> (raw)
In-Reply-To: <20200115112640.52kemwg4lncuvvir@sirius.home.kraxel.org>

Hi,

On Wed, Jan 15, 2020 at 8:26 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
>
>   Hi,
>
> > > If you have (1) hardware you simply can't import buffers with arbitrary
> > > plane offsets, so I'd expect software would prefer the single buffer
> > > layout (i) over (ii), even when using another driver + dmabuf
> > > export/import, to be able to support as much hardware as possible.
> > > So (ii) might end up being unused in practice.
> > >
> > > But maybe not, was just an idea, feel free to scratch it.
> >
> > That's true, simple user space would often do that. However, if more
> > devices are in the game, often some extra alignment or padding between
> > planes is needed and that is not allowed by (1), even though all the
> > planes are in the same buffer.
> >
> > My suggestion, based on the latest V4L2 discussion on unifying the
> > UAPI of i) and ii), is that we may want to instead always specify
> > buffers on a per-plane basis. Any additional requirements would be
> > then validated by the host, which could check if the planes end up in
> > the same buffer (or different buffers for (3)) and/or at the right
> > offsets.
>
> Hmm, using (ii) the API, then check whenever your three plane buffers
> happen to have the correct layout for (1) hardware looks somewhat
> backwards to me.

Can't this problem be solved by adding "offset" field in virtio_video_mem_entry?

struct virtio_video_mem_entry {
  le64 addr;
  le32 length;
  le32 offset;
  u8 padding[4];
};

Here, "addr" must be the same in every mem_entry for (1) hardware.

>
> I'd suggest to use (i) API and allow the device specify alignment
> requirements.  So (1) hardware would say "need_align=0", whereas (3)
> hardware would probably say "need_align=PAGE_SIZE" so it can easily
> split the single buffer into three per-plane buffers.

Just to confirm, is "need_align" a field added in virtio_video_format_desc?
It sounds workable, too.

Best regards,
Keiichi


>
> cheers,
>   Gerd
>

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  reply	other threads:[~2020-01-20  7:20 UTC|newest]

Thread overview: 147+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-18 13:02 [PATCH v2 0/1] VirtIO video device specification Keiichi Watanabe
2019-12-18 13:02 ` [virtio-dev] " Keiichi Watanabe
2019-12-18 13:02 ` [PATCH v2 1/1] virtio-video: Add virtio " Keiichi Watanabe
2019-12-18 13:02   ` [virtio-dev] " Keiichi Watanabe
2019-12-18 13:40   ` Gerd Hoffmann
2019-12-18 13:40     ` [virtio-dev] " Gerd Hoffmann
2019-12-18 14:08     ` Tomasz Figa
2019-12-18 14:08       ` Tomasz Figa
2019-12-19  7:46       ` Gerd Hoffmann
2019-12-19  7:46         ` Gerd Hoffmann
2019-12-19  9:48         ` Dmitry Sepp
2019-12-19  9:48           ` Dmitry Sepp
2019-12-19  9:59           ` Tomasz Figa
2019-12-19  9:59             ` Tomasz Figa
2019-12-19 10:54             ` Dmitry Sepp
2019-12-19 10:54               ` Dmitry Sepp
2019-12-19 12:05               ` Tomasz Figa
2019-12-19 12:05                 ` Tomasz Figa
2019-12-19 13:12               ` Gerd Hoffmann
2019-12-19 13:12                 ` Gerd Hoffmann
2020-01-08 13:52                 ` Keiichi Watanabe
2020-01-08 13:52                   ` Keiichi Watanabe
2020-01-09 13:40                   ` Gerd Hoffmann
2020-01-09 13:40                     ` Gerd Hoffmann
2020-01-09 14:20                   ` Tomasz Figa
2020-01-09 14:20                     ` Tomasz Figa
2020-01-14  7:18                     ` Keiichi Watanabe
2020-01-14  7:18                       ` Keiichi Watanabe
2020-01-14 10:35                       ` Dmitry Sepp
2020-01-14 10:35                         ` Dmitry Sepp
2020-01-15  7:49                         ` Keiichi Watanabe
2020-01-15  7:49                           ` Keiichi Watanabe
2020-01-15 11:12                         ` Tomasz Figa
2020-01-15 11:12                           ` Tomasz Figa
2019-12-19 13:01           ` Gerd Hoffmann
2019-12-19 13:01             ` Gerd Hoffmann
2020-01-08 13:50             ` Keiichi Watanabe
2020-01-08 13:50               ` Keiichi Watanabe
2019-12-19  9:26     ` Dmitry Sepp
2019-12-19  9:26       ` [virtio-dev] " Dmitry Sepp
2019-12-19  9:59       ` Tomasz Figa
2019-12-19  9:59         ` [virtio-dev] " Tomasz Figa
2019-12-19 12:54       ` Gerd Hoffmann
2019-12-19 12:54         ` [virtio-dev] " Gerd Hoffmann
2019-12-18 17:29   ` Frediano Ziglio
2019-12-20 14:05     ` Keiichi Watanabe
2019-12-20 14:05       ` [virtio-dev] " Keiichi Watanabe
2019-12-20 15:33       ` Dmitry Sepp
2019-12-20 15:33         ` [virtio-dev] " Dmitry Sepp
2019-12-19 13:28   ` Dmitry Sepp
2019-12-19 13:28     ` [virtio-dev] " Dmitry Sepp
2019-12-20 15:26     ` Keiichi Watanabe
2019-12-20 15:26       ` [virtio-dev] " Keiichi Watanabe
2019-12-20 15:46       ` Dmitry Sepp
2019-12-21  6:46         ` Tomasz Figa
2019-12-21  6:46           ` [virtio-dev] " Tomasz Figa
2019-12-30 12:16     ` Dmitry Sepp
2019-12-30 12:16       ` Dmitry Sepp
2020-01-06  6:31       ` Tomasz Figa
2020-01-06  6:31         ` Tomasz Figa
2020-01-06  8:33         ` Gerd Hoffmann
2020-01-06  8:33           ` Gerd Hoffmann
2020-01-06  9:29           ` Dmitry Sepp
2020-01-06  9:29             ` Dmitry Sepp
2020-01-03 15:47   ` Dmitry Sepp
2020-01-03 15:47     ` [virtio-dev] " Dmitry Sepp
2020-01-06  8:47     ` Gerd Hoffmann
2020-01-06  8:47       ` [virtio-dev] " Gerd Hoffmann
2020-01-06 10:21     ` Keiichi Watanabe
2020-01-06 10:21       ` [virtio-dev] " Keiichi Watanabe
2020-01-06 14:59   ` Dmitry Sepp
2020-01-06 14:59     ` [virtio-dev] " Dmitry Sepp
2020-01-07 13:24     ` Keiichi Watanabe
2020-01-07 13:24       ` [virtio-dev] " Keiichi Watanabe
2020-01-07 16:50       ` Dmitry Sepp
2020-01-07 16:50         ` [virtio-dev] " Dmitry Sepp
2020-01-08  6:59         ` Keiichi Watanabe
2020-01-08  6:59           ` [virtio-dev] " Keiichi Watanabe
2020-01-08 10:00           ` Dmitry Sepp
2020-01-08 10:00             ` [virtio-dev] " Dmitry Sepp
2020-01-08 12:14             ` Keiichi Watanabe
2020-01-08 12:14               ` [virtio-dev] " Keiichi Watanabe
2020-01-08 12:46               ` Tomasz Figa
2020-01-08 12:46                 ` [virtio-dev] " Tomasz Figa
2020-01-08 13:05                 ` Keiichi Watanabe
2020-01-08 13:05                   ` [virtio-dev] " Keiichi Watanabe
2020-01-08 13:11                 ` Dmitry Sepp
2020-01-08 13:11                   ` [virtio-dev] " Dmitry Sepp
2020-01-08 13:23                   ` Keiichi Watanabe
2020-01-08 13:23                     ` Keiichi Watanabe
2020-01-08 12:23   ` Keiichi Watanabe
2020-01-08 12:23     ` [virtio-dev] " Keiichi Watanabe
2019-12-20 15:58 ` [PATCH v2 0/1] VirtIO " Dmitry Sepp
2019-12-20 15:58   ` [virtio-dev] " Dmitry Sepp
2019-12-21  4:36   ` Keiichi Watanabe
2019-12-21  4:36     ` [virtio-dev] " Keiichi Watanabe
2019-12-21  6:18     ` Tomasz Figa
2019-12-21  6:18       ` [virtio-dev] " Tomasz Figa
2019-12-21  6:19       ` Tomasz Figa
2019-12-21  6:19         ` [virtio-dev] " Tomasz Figa
2020-01-03 13:05         ` Dmitry Sepp
2020-01-03 13:05           ` [virtio-dev] " Dmitry Sepp
2020-01-06 10:30           ` Keiichi Watanabe
2020-01-06 10:30             ` [virtio-dev] " Keiichi Watanabe
2020-01-06 11:28             ` Dmitry Sepp
2020-01-06 11:28               ` [virtio-dev] " Dmitry Sepp
2020-01-07 10:25               ` Keiichi Watanabe
2020-01-07 10:25                 ` [virtio-dev] " Keiichi Watanabe
2020-01-09 14:56                 ` Dmitry Sepp
2020-01-09 14:56                   ` [virtio-dev] " Dmitry Sepp
2020-01-10 10:16                   ` Dmitry Sepp
2020-01-10 10:16                     ` Dmitry Sepp
2020-01-10 13:53                     ` Keiichi Watanabe
2020-01-10 13:53                       ` Keiichi Watanabe
2020-01-10 15:11                       ` Dmitry Sepp
2020-01-10 15:11                         ` Dmitry Sepp
2020-01-11 16:06                         ` Tomasz Figa
2020-01-11 16:06                           ` Tomasz Figa
2020-01-13  9:50                           ` Dmitry Sepp
2020-01-13  9:50                             ` Dmitry Sepp
2020-01-15 11:23                             ` Keiichi Watanabe
2020-01-15 11:23                               ` Keiichi Watanabe
2020-01-13  9:56                         ` Gerd Hoffmann
2020-01-13  9:56                           ` Gerd Hoffmann
2020-01-13 10:41                           ` Dmitry Sepp
2020-01-13 11:05                             ` Gerd Hoffmann
2020-01-13 11:05                               ` Gerd Hoffmann
2020-01-13 11:59                               ` Tomasz Figa
2020-01-13 11:59                                 ` Tomasz Figa
2020-01-13 13:26                                 ` Gerd Hoffmann
2020-01-13 13:26                                   ` Gerd Hoffmann
2020-01-15 11:00                                   ` Tomasz Figa
2020-01-15 11:00                                     ` Tomasz Figa
2020-01-15 11:23                                     ` Keiichi Watanabe
2020-01-15 11:23                                       ` Keiichi Watanabe
2020-01-15 11:26                                     ` Gerd Hoffmann
2020-01-15 11:26                                       ` Gerd Hoffmann
2020-01-20  7:20                                       ` Keiichi Watanabe [this message]
2020-01-20  7:20                                         ` Keiichi Watanabe
2020-01-20 10:47                                         ` Gerd Hoffmann
2020-01-20 10:47                                           ` Gerd Hoffmann
2020-01-21  2:47                                           ` Keiichi Watanabe
2020-01-21  2:47                                             ` Keiichi Watanabe
2020-01-21  6:44                                             ` Gerd Hoffmann
2020-01-21  6:44                                               ` Gerd Hoffmann
2020-01-21  8:56                                               ` Keiichi Watanabe
2020-01-21  8:56                                                 ` Keiichi Watanabe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAD90VcaAaomTnwVESp9RaBwhjx+cKjXAJv4T7wSkFiCEhOUo5Q@mail.gmail.com \
    --to=keiichiw@chromium.org \
    --cc=acourbot@chromium.org \
    --cc=alexlau@chromium.org \
    --cc=daniel@ffwll.ch \
    --cc=dgreid@chromium.org \
    --cc=dmitry.sepp@opensynergy.com \
    --cc=egranata@google.com \
    --cc=fziglio@redhat.com \
    --cc=hverkuil@xs4all.nl \
    --cc=kraxel@redhat.com \
    --cc=linux-media@vger.kernel.org \
    --cc=marcheu@chromium.org \
    --cc=posciak@chromium.org \
    --cc=spice-devel@lists.freedesktop.org \
    --cc=stevensd@chromium.org \
    --cc=tfiga@chromium.org \
    --cc=uril@redhat.com \
    --cc=virtio-dev@lists.oasis-open.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.