On Thu, Jul 26, 2018 at 7:30 AM Emil Velikov <emil.l.veli...@gmail.com>
wrote:
> Hi David,
>
> Hi Emil,
Thanks for the comments.
> On 18 July 2018 at 01:12, David Riley <davidri...@chromium.org> wrote:
> > Allow platform_surfaceless to use swrast even if DRM is not available.
> > To be used to allow a fuzzer for virgl to be run on a jailed VM without
> > hardware GL or DRM support.
> >
> > Signed-off-by: David Riley <davidri...@chromium.org>
> > ---
> > src/egl/drivers/dri2/platform_surfaceless.c | 19 +++++++++++++++++++
> > 1 file changed, 19 insertions(+)
> >
> > diff --git a/src/egl/drivers/dri2/platform_surfaceless.c
> b/src/egl/drivers/dri2/platform_surfaceless.c
> > index f5fe7119c6..f4618bfa11 100644
> > --- a/src/egl/drivers/dri2/platform_surfaceless.c
> > +++ b/src/egl/drivers/dri2/platform_surfaceless.c
> > @@ -293,6 +293,7 @@ surfaceless_probe_device(_EGLDisplay *dpy, bool
> swrast)
> > int fd;
> > int i;
> >
> > + /* Attempt to find DRM device. */
> > for (i = 0; i < limit; ++i) {
> > char *card_path;
> > if (asprintf(&card_path, DRM_RENDER_DEV_NAME, DRM_DIR_NAME, base
> + i) < 0)
> > @@ -327,6 +328,24 @@ surfaceless_probe_device(_EGLDisplay *dpy, bool
> swrast)
> > dri2_dpy->loader_extensions = NULL;
> > }
> >
> > + /* No DRM device, so attempt to fall back to software path w/o DRM.
> */
> > + if (swrast) {
> > + _eglLog(_EGL_DEBUG, "Falling back to surfaceless swrast without
> DRM.");
> > + dri2_dpy->fd = -1;
> > + dri2_dpy->driver_name = strdup("swrast");
> > + if (!dri2_dpy->driver_name) {
> > + return false;
> > + }
> > +
> > + if (dri2_load_driver_swrast(dpy)) {
> > + dri2_dpy->loader_extensions = swrast_loader_extensions;
> > + return true;
> > + }
> > +
> > + free(dri2_dpy->driver_name);
> > + dri2_dpy->driver_name = NULL;
> > + }
>
> Using swrast gives you a fairly different feature-set than kms_swrast.
> Since you're doing virglrenderer fuzzing, you haven't really noticed it.
>
> Yes, the main goal is to be able to get coverage of the virgl APIs and
thus the required GL APIs.
> Regardless, this patch seems like a hack, alike the ones Tomeu did [1].
> There are some ideas, in the comments, how to address this in a better
> fashion.
>
> If you can give it a try, that'll be appreciated. I don't quite have
> the time to pursue it atm.
>
I understand and agree with your comments about kms_swrast requiring KMS
and not wanting to change those semantics.
I'm not quite sure I follow all the rest of your suggestions (new to this
entire code base). You're suggesting that surfaceless move away from
kms_swrast entirely? Or just for the fallback path like I've got in these
changes?
With regards to your other suggestion I also don't follow. Are you're
suggesting that createNewScreen3 for swrast should dispatch between
dri2_init_screen/drisw_init_screen/dri_kms_init_screen based on some enum
instead of a driver that has been loaded and it's vtable?
I'm hoping to make some more targeted changes than major refactoring of
code that I'm quite unfamiliar with.
Thanks,
David
>
> HTH
> Emil
>
> [1]
>
> https://gitlab.collabora.com/tomeu/mesa/commit/4f804ceecd658492234cbf0fa5fb1b156a8fb79c
>
> https://gitlab.collabora.com/tomeu/mesa/commit/54adda6a4d7b5c783d54dfd37d38d1a5a0f3187f
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
