linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: David Airlie <airlied@linux.ie>, Dave Airlie <airlied@redhat.com>,
	open list <linux-kernel@vger.kernel.org>,
	"open list:VIRTIO GPU DRIVER" <dri-devel@lists.freedesktop.org>,
	"open list:VIRTIO GPU DRIVER" 
	<virtualization@lists.linux-foundation.org>,
	"open list:ABI/API" <linux-api@vger.kernel.org>
Subject: Re: [PATCH v2 4/6] virtio-gpu: add 3d/virgl support
Date: Tue, 22 Sep 2015 17:18:18 +0200	[thread overview]
Message-ID: <1442935098.13084.31.camel@redhat.com> (raw)
In-Reply-To: <20150921130110-mutt-send-email-mst@redhat.com>

  Hi,

> >  static unsigned int features[] = {
> > +#ifdef __LITTLE_ENDIAN
> > +	VIRTIO_GPU_FEATURE_VIRGL,
> > +#endif
> >  };
> 
> Why is virgl LE specific? Just curious.

gallium command stream is native endian, and we only support little
endian guests on little endian hosts for that reason.

Supporting bigendian guests on bigendian hosts should be possible too
(with a VIRGl_BE feature flag), but with even the powerpc world moving
to little endian I see little reason to actually bother.

To be clear: this affects 3d acceleration only, 2d mode works fine on
every host/guest endian combination.

> > +#ifdef __LITTLE_ENDIAN
> > +	if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_FEATURE_VIRGL))
> > +		vgdev->has_virgl_3d = true;
> > +#endif
> 
> You might be able to get by without this ifdef as
> VIRTIO_GPU_FEATURE_VIRGL won't be set without it.

Yes, right, this #ifdef can go away.

> > +int virtio_gpu_cmd_get_capset_info(struct virtio_gpu_device *vgdev, int idx)
> > +{
> > +	struct virtio_gpu_get_capset_info *cmd_p;
> > +	struct virtio_gpu_vbuffer *vbuf;
> > +	void *resp_buf;
> > +
> > +	resp_buf = kzalloc(sizeof(struct virtio_gpu_resp_capset_info),
> > +			   GFP_KERNEL);
> > +	if (!resp_buf)
> > +		return -ENOMEM;
> > +
> > +	cmd_p = virtio_gpu_alloc_cmd_resp
> > +		(vgdev, &virtio_gpu_cmd_get_capset_info_cb, &vbuf,
> > +		 sizeof(*cmd_p), sizeof(struct virtio_gpu_resp_capset_info),
> > +		 resp_buf);
> > +	memset(cmd_p, 0, sizeof(*cmd_p));
> > +
> > +	cmd_p->hdr.type = cpu_to_le32(VIRTIO_GPU_CMD_GET_CAPSET_INFO);
> > +	cmd_p->capset_index = cpu_to_le32(idx);
> > +	virtio_gpu_queue_ctrl_buffer(vgdev, vbuf);
> > +	return 0;
> > +}
> > +
> 
> I note that all callers ignore the recurn code from
> virtio_gpu_queue_ctrl_buffer.
> 
> Is there a reason it can't fail?

It can only fail when vgdev->vqs_ready is false.  Which can only happen
when we are about to unload the driver.  In that case we probably don't
worry much about the failure ...

> Shouldn't it be made void then?

I guess we should ...

> > +	cmd_p->hdr.type = cpu_to_le32(VIRTIO_GPU_CMD_CTX_CREATE);
> > +	cmd_p->hdr.ctx_id = cpu_to_le32(id);
> > +	cmd_p->nlen = cpu_to_le32(nlen);
> > +	strncpy(cmd_p->debug_name, name, 63);
> > +	cmd_p->debug_name[63] = 0;
> 
> sizeof (cmd_p->debug_name) - 1 will be a but prettier.

Agree.

> > diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h
> > index 478be52..7f4f9ce 100644
> > --- a/include/uapi/linux/virtio_gpu.h
> > +++ b/include/uapi/linux/virtio_gpu.h
> > @@ -40,6 +40,8 @@
> >  
> >  #include <linux/types.h>
> >  
> > +#define VIRTIO_GPU_FEATURE_VIRGL 0
> > +
> 
> I'd prefer it named VIRTIO_GPU_F_VIRGL for consistency with other
> devices.

Makes sense, I'll change it.

thanks,
  Gerd



  reply	other threads:[~2015-09-22 15:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1442828417-6165-1-git-send-email-kraxel@redhat.com>
2015-09-21  9:40 ` [PATCH v2 1/6] virtio-gpu: add virtio_gpu_queue_ctrl_buffer_locked Gerd Hoffmann
2015-09-21  9:40 ` [PATCH v2 2/6] virtio-gpu: add & use virtio_gpu_queue_fenced_ctrl_buffer Gerd Hoffmann
2015-09-21  9:40 ` [PATCH v2 3/6] virtio-gpu: wait for cursor updates finish Gerd Hoffmann
2015-09-21  9:40 ` [PATCH v2 4/6] virtio-gpu: add 3d/virgl support Gerd Hoffmann
2015-09-21 10:15   ` Michael S. Tsirkin
2015-09-22 15:18     ` Gerd Hoffmann [this message]
2015-09-21  9:40 ` [PATCH v2 5/6] virtio-gpu: add basic prime support Gerd Hoffmann
2015-09-22  9:40   ` Daniel Vetter
2015-09-22 15:24     ` Gerd Hoffmann
2015-09-22 16:15       ` Daniel Vetter
2015-09-21  9:40 ` [PATCH v2 6/6] virtio-gpu: mark as a render gpu Gerd Hoffmann

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=1442935098.13084.31.camel@redhat.com \
    --to=kraxel@redhat.com \
    --cc=airlied@linux.ie \
    --cc=airlied@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=virtualization@lists.linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).