Ping... On Wed, Jun 21, 2017 at 4:40 PM, Gurchetan Singh < gurchetansi...@chromium.org> wrote:
> Emil, > > If I understand you correctly, you're proposing to add the ability to use > the kms_swrast driver in platform_x11.c (the host is a standard Ubuntu box > for the emulator use case, not CrOS) alongside swrast. > > In that case, we would need to: > > 1) Have a dri2_initialize_x11_kms_swrast function that's called when some > environment variable is set instead of dri2_initialize_x11_swrast. > 2) dri2_initialize_x11_kms_swrast would need access to the host card fd > (dri_kms_init_screen requires this) and call dri2_load_driver instead of > dri2_load_driver_swrast . > 3) Use dri2_loader_extensions instead of swrast_loader_extensions, > dri2_x11_display_vtbl instead dri2_x11_swrast_display_vtbl etc. > > I'm having trouble getting this to work, and I was wondering if what I'm > trying to do is what you want. Attached is the patch I'm trying (it > compiles, but will crash your display). > > Regarding the issues with the emulator, I filed a bug based your comments > and the emulator team has started looking at it (see > https://android-review.googlesource.com/#/c/418541/). > > > On Tue, Jun 20, 2017 at 1:19 AM, Emil Velikov <emil.l.veli...@gmail.com> > wrote: > >> On 19 June 2017 at 20:46, Chad Versace <chadvers...@chromium.org> wrote: >> > On Thu 15 Jun 2017, Gurchetan Singh wrote: >> >> Emil, would you be fine with leaving the image extension in dri2.c but >> still >> >> adding it as a drisw extension? That solution would look like: >> >> >> >> [1]https://patchwork.freedesktop.org/patch/154807/ >> > >> > Observations: >> > - src/gallium/state_trackers/dri/dri2.c:dri2ImageExtension >> advertises v15 of __DRI_IMAGE. >> > - egl_dri2.c requires only v1 of __DRI_IMAGE. Maybe a higher version >> > is required in practive, but the egl_dri2.c code checks only for >> v1. >> > >> > Questions: >> > 1. All functions implemented in dri2.c:dri2ImageExtensions, do they >> > under swrast? Honest question, because I'm no expert on >> > gallium. >> > >> > If question #1 is true, then I see no problem with your latest plan. But >> > maybe Emil does. >> > >> > If question #1 is false, it should be straightforward to implement in >> > drisw.c the small subset of __DRI_IMAGE functions required for v1. >> >> While I haven't checked how much [or well] DRI_IMAGE works with >> swrast, there's no need to actually add it there. >> An alternative is to add kms_swrast support for EGL like we already do >> for GBM, as mentioned earlier [1]. >> >> Gents, keep in mind that: >> - one cannot pull DRM specifics (dri2.c) code within drisw.c, and >> - DRI_IMAGE pulls DRM specifics, hence adding it into drisw.c is >> again a no-go :-\ >> >> FWIW the above architectural split applies for classic drivers as >> well. swrast_dri.so simply cannot depend on anything DRM related. >> >> -Emil >> >> [1] https://lists.freedesktop.org/archives/mesa-dev/2017-June/159519.html >> > >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
