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:
https://patchwork.freedesktop.org/patch/154807/ On Fri, Jun 9, 2017 at 8:40 AM, Gurchetan Singh <gurchetansi...@chromium.org > wrote: > Actually, these are the only patches that are required. We're trying to > run the Android Studio emulator using the host's GLES implementation. The > emulator uses the image extension in that case: > > https://android.googlesource.com/platform/sdk/+/emu-2.4-rele > ase/emulator/opengl/host/libs/libOpenglRender/FrameBuffer.cpp > https://android.googlesource.com/platform/sdk/+/emu-2.4-rele > ase/emulator/opengl/host/libs/libOpenglRender/ColorBuffer.cpp > > It does only use a subset of the extension, but nothing hardware specific. > > > On Fri, Jun 9, 2017 at 4:17 AM, Emil Velikov <emil.l.veli...@gmail.com> > wrote: > >> Hi Gurchetan, >> >> On 9 June 2017 at 01:28, gurchetansi...@chromium.org >> <gurchetansi...@chromium.org> wrote: >> > From: Gurchetan Singh <gurchetansi...@google.com> >> > >> > Otherwise, this extension is not visible to the EGL user >> > --- >> > src/egl/drivers/dri2/egl_dri2.c | 1 + >> > 1 file changed, 1 insertion(+) >> > >> > diff --git a/src/egl/drivers/dri2/egl_dri2.c >> b/src/egl/drivers/dri2/egl_dri2.c >> > index 7175e827c9..9e845e99e3 100644 >> > --- a/src/egl/drivers/dri2/egl_dri2.c >> > +++ b/src/egl/drivers/dri2/egl_dri2.c >> > @@ -429,6 +429,7 @@ static const struct dri2_extension_match >> swrast_driver_extensions[] = { >> > >> > static const struct dri2_extension_match swrast_core_extensions[] = { >> > { __DRI_TEX_BUFFER, 2, offsetof(struct dri2_egl_display, >> tex_buffer) }, >> > + { __DRI_IMAGE, 1, offsetof(struct dri2_egl_display, image) }, >> IIRC the current codebase will not use it even, we expose it. Correct? >> Wild guess here is that you guys have some extra patches around, like >> say using vgem? Is there a public repo with the lot? >> >> On the st/dri side (earlier patches) - one should be able to build >> st/dri without any hardware specific knowledge and/or files. >> Currently that's done by isolating all the DRM specifics in dri2.c. >> Not sure if breaking that, architectural split imho, is a good idea. >> >> -Emil >> > >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
