On Mon, Sep 25, 2017 at 7:21 PM, Eric Engestrom <eric.engest...@imgtec.com> wrote: > On Saturday, 2017-09-23 13:37:29 +0900, Tomasz Figa wrote: >> On Wed, Sep 20, 2017 at 7:47 PM, Eric Engestrom >> <eric.engest...@imgtec.com> wrote: >> > On Tuesday, 2017-09-19 17:19:59 +0000, Emil Velikov wrote: >> >> From: Emil Velikov <emil.veli...@collabora.com> >> >> >> >> In order to build EGL, one has to use shared glapi - libglapi.so. >> >> >> >> Thus the dlopen/dlsym dance is no longer needed and we can link to the >> >> library directly. >> >> >> >> This allows us to remove a handful of platform specific names of the >> >> library. >> >> >> >> Cc: Jonathan Gray <j...@jsg.id.au> >> >> Cc: Jon Turney <jon.tur...@dronecode.org.uk> >> >> Cc: Julien Isorce <julien.iso...@gmail.com> >> >> Cc: Rob Herring <r...@kernel.org> >> >> Cc: Tomasz Figa <tf...@chromium.org> >> >> Signed-off-by: Emil Velikov <emil.veli...@collabora.com> >> > >> > Nice cleanup! >> > Assuming the build systems stuff works (with Rob's suggested change?): >> > Reviewed-by: Eric Engestrom <eric.engest...@imgtec.com> >> > >> > struct dri2_egl_driver now only contains the glFlush() pointer and >> > _EGLDriver. Could we move the _glapi_get_proc_address() call to >> > the two places that use glFlush() (ie. dri2_make_current() and >> > dri2_client_wait_sync()), and get rid of this struct, as well as >> > the whole dri2_load() function? >> > >> > I'm happy to do this, just want to check that it would be ok :) >> >> Wouldn't that mean going through the series of strcmp()s over all the >> symbols every time EGL wants to call glFlush? > > Well, I was thinking of making that call static, maybe even global > (shared between the functions), so it would happen at most once for each > of the two functions, but yeah you're right, it would do it more often > than right now. Do you think this is an issue? > I guess I'm dropping this idea if that's the case :]
I guess a global function (let's say dri2_gl_flush()) that looks up the symbol only at the first call and then calls it, wouldn't be so bad. Best regards, Tomasz > >> >> Best regards, >> Tomasz >> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
