From: Gerd Hoffmann <kraxel@redhat.com>
To: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Dave Airlie <airlied@redhat.com>,
open list <linux-kernel@vger.kernel.org>,
ML dri-devel <dri-devel@lists.freedesktop.org>,
"open list:VIRTIO GPU DRIVER"
<virtualization@lists.linux-foundation.org>
Subject: Re: [PATCH 5/5] virtgpu: mark as a render gpu
Date: Thu, 10 Sep 2015 16:52:45 +0200 [thread overview]
Message-ID: <1441896765.11233.25.camel@redhat.com> (raw)
In-Reply-To: <CACvgo50SU46SYXBbVe+VGcAb6uFSj-iBY0E4=Vuuzf5RKbE+2Q@mail.gmail.com>
Hi,
> > Dave? Looking at the ioctls they are all fine for render nodes, there
> > isn't anything modesetting related in the device-specific ioctls.
> >
> > Correct?
> >
> Unless I've overdone the coffee this time - modesetting is done via
> the card# node, while render via either card# or renderD#.
Exactly, thats why anything modesetting-related must be disabled for
renderD#. Looking at the virtio-gpu device-specific ioctls I don't
think there is anything doing modesetting (which we would have to leave
out), so we can apply DRM_RENDER_ALLOW everythere I think. Or maybe
there is a global switch to flip DRM_RENDER_ALLOW for the whole list ...
cheers,
Gerd
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Gerd Hoffmann <kraxel@redhat.com>
To: Emil Velikov <emil.l.velikov@gmail.com>
Cc: ML dri-devel <dri-devel@lists.freedesktop.org>,
Dave Airlie <airlied@redhat.com>,
open list <linux-kernel@vger.kernel.org>,
"open list:VIRTIO GPU DRIVER"
<virtualization@lists.linux-foundation.org>
Subject: Re: [PATCH 5/5] virtgpu: mark as a render gpu
Date: Thu, 10 Sep 2015 16:52:45 +0200 [thread overview]
Message-ID: <1441896765.11233.25.camel@redhat.com> (raw)
In-Reply-To: <CACvgo50SU46SYXBbVe+VGcAb6uFSj-iBY0E4=Vuuzf5RKbE+2Q@mail.gmail.com>
Hi,
> > Dave? Looking at the ioctls they are all fine for render nodes, there
> > isn't anything modesetting related in the device-specific ioctls.
> >
> > Correct?
> >
> Unless I've overdone the coffee this time - modesetting is done via
> the card# node, while render via either card# or renderD#.
Exactly, thats why anything modesetting-related must be disabled for
renderD#. Looking at the virtio-gpu device-specific ioctls I don't
think there is anything doing modesetting (which we would have to leave
out), so we can apply DRM_RENDER_ALLOW everythere I think. Or maybe
there is a global switch to flip DRM_RENDER_ALLOW for the whole list ...
cheers,
Gerd
next prev parent reply other threads:[~2015-09-10 14:52 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-09 11:42 [PATCH 0/5] virtio-gpu: add virgl/3d rendering support Gerd Hoffmann
2015-09-09 11:42 ` [PATCH 1/5] virtio-gpu: add virtio_gpu_queue_ctrl_buffer_nolock Gerd Hoffmann
2015-09-09 11:42 ` Gerd Hoffmann
2015-09-10 8:39 ` Emil Velikov
2015-09-10 8:39 ` Emil Velikov
2015-09-10 14:04 ` Gerd Hoffmann
2015-09-10 14:04 ` Gerd Hoffmann
2015-09-10 8:39 ` Emil Velikov
2015-09-09 11:42 ` Gerd Hoffmann
2015-09-09 11:42 ` [PATCH 2/5] virtio-gpu: add & use virtio_gpu_queue_fenced_ctrl_buffer Gerd Hoffmann
2015-09-09 11:42 ` Gerd Hoffmann
2015-09-09 11:42 ` Gerd Hoffmann
2015-09-09 11:42 ` [PATCH 3/5] update virtio gpu driver: add 3d/virgl support Gerd Hoffmann
2015-09-09 11:42 ` Gerd Hoffmann
2015-09-09 11:42 ` Gerd Hoffmann
2015-09-10 8:56 ` Emil Velikov
[not found] ` <1441798946-26233-4-git-send-email-kraxel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-09-10 8:56 ` Emil Velikov
2015-09-10 8:56 ` Emil Velikov
2015-09-10 10:32 ` Dave Airlie
2015-09-10 10:32 ` Dave Airlie
2015-09-10 12:15 ` Emil Velikov
2015-09-10 12:15 ` Emil Velikov
2015-09-10 12:15 ` Emil Velikov
2015-09-10 14:45 ` Gerd Hoffmann
2015-09-10 14:45 ` Gerd Hoffmann
2015-09-09 11:42 ` [PATCH 4/5] virtio_gpu: add basic prime support Gerd Hoffmann
2015-09-09 11:42 ` Gerd Hoffmann
2015-09-09 11:42 ` Gerd Hoffmann
2015-09-09 11:42 ` [PATCH 5/5] virtgpu: mark as a render gpu Gerd Hoffmann
2015-09-09 11:42 ` Gerd Hoffmann
2015-09-10 8:59 ` Emil Velikov
2015-09-10 8:59 ` Emil Velikov
2015-09-10 14:23 ` Gerd Hoffmann
2015-09-10 14:23 ` Gerd Hoffmann
2015-09-10 14:33 ` Emil Velikov
2015-09-10 14:33 ` Emil Velikov
2015-09-10 14:52 ` Gerd Hoffmann [this message]
2015-09-10 14:52 ` Gerd Hoffmann
2015-09-10 15:04 ` Emil Velikov
2015-09-10 15:04 ` Emil Velikov
2015-09-11 6:32 ` Dave Airlie
2015-09-11 6:32 ` Dave Airlie
2015-09-11 6:32 ` Dave Airlie
2015-09-11 9:16 ` Gerd Hoffmann
2015-09-11 9:16 ` Gerd Hoffmann
2015-09-11 9:16 ` Gerd Hoffmann
2015-09-10 15:04 ` Emil Velikov
2015-09-10 14:52 ` Gerd Hoffmann
2015-09-10 8:59 ` Emil Velikov
2015-09-09 11:42 ` 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=1441896765.11233.25.camel@redhat.com \
--to=kraxel@redhat.com \
--cc=airlied@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=emil.l.velikov@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--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 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.