Thanks for the review, Emil. If we want to use swrast we'll probably need
to implement a new swrast version of the image extension. We can't reuse
the functions from dri2.c, even for version 1 of the extension
(createImageFromName, createImageFromRenderbuffer etc), since they require
definitions from dri_driver.h (like struct winsys_handle).
However, we would like to get around the the constant re-implementation and
code movement, and use kms_swrast if possible. Can you outline some the
challenges and possible solutions to using kms_swrast with platform_x11?
We could invest the time in making it work if it is achievable ...
On Wed, Jun 28, 2017 at 8:24 AM, Emil Velikov <emil.l.veli...@gmail.com>
wrote:
> 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) },
> Considering the entry points used, check the exact _DRI_IMAGE version
> needed (see dri_interface.h) and update accordingly.
>
> Also move the line to optional_core_extensions, since by using
> swrast_core_extensions you will fail to load older swrast_dri.so which
> are otherwise perfectly capable of working (albeit w/o said EGL
> extensions).
>
> Before you ask - yes, extension is present in dri2_core_extensions, so
> doing a second check is sub-optimal/strange.
> Do add a comment clearing any ambiguities.
>
> With that said - I'm back to addressing all the issues I've saw in libEGL
> ;-)
>
> Thanks
> Emil
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
