Re: [Mesa-dev] Drooping multiple driver support in EGL?
- Original Message - On 01/13/2012 04:29 PM, Jose Fonseca wrote: - Original Message - On 01/12/2012 09:06 AM, Chia-I Wu wrote: On Tue, Jan 10, 2012 at 12:55 AM, Jose Fonsecajfons...@vmware.com wrote: - Original Message - On Fri, Dec 23, 2011 at 7:51 PM, Chia-I Wuolva...@gmail.com wrote: On Sat, Dec 24, 2011 at 12:37 AM, Ian Romanick i...@freedesktop.org wrote: On 12/23/2011 07:20 AM, Jose Fonseca wrote: - Original Message - Hi list, Multiple driver support in EGL is hard to get right, if not impossible. On Linux desktop, we almost always want to use egl_dri2. It allows EGL to loads DRI2 drivers, thus allowing it to share DRI2 drivers with libGL. In one case where the app wants to use OpenVG, libEGL needs to load egl_gallium instead. The problem comes from that we cannot know that an OpenVG context is to be created until it is created. But before a context can be created, EGL needs to be initialized and an EGLConfig needs to be chosen. So when EGL is to be initialized, we need to load and initilaize all EGL drivers. When an EGLConfig is to be picked, we need to pick it from all drivers. Couldn't we restructure this such that OpenVG (and all other state trackers on Linux) still use a dri2 driver, but one which exposes an additional (gallium specific) interface? I was going to suggest something similar. I think we want fewer EGL backends to test and maintain, not more. Right? I totally agree with that. I even had an unfinished branch for that. Note that this thread is about dropping multiple EGL driver support. The motivation for having OpenVG in DRI2 drivers is that we do not want multiple EGL drivers. The former should push the latter to happen more quickly, instead of preventing it from happening. The problem with exposing the Gallium Interface via the DRI interface is that the DRI interface is public and stable while the Gallium one is not. I think one doesn't invalidate the other. That is, it is technically feasible to have an unstable interface on top of an stable interface. In detail, we could add a stable extension DRI , which exposes Gallium (eg. DRI2GetGalliumScreen). Obviously, for things to work, it would be imperative that the libEGL.so and foo_dri.so were built together, which is already the case today. We don't get to require that lib*GL and *_dri.so be upgraded in lock-step. Ever. I'm afraid I don't understand what you're trying to say.. (Who requires what and why?) Anyway, the fact is that gallium state tracker and pipe driver have to be upgraded in lock-step *today*, and my point is that it must be somehow possible to preserve that constraint, without having to do something completely different from the non-gallium drivers. This is another case where the term DRI is overloaded in an awkward and confusing way. We cannot require that things loader side (libEGL, libGL, or the xserver's GLX module) be updated in lock-step with the drivers or vice versa. Why? Is it because the X server will continue to run in the background w/ the old libEGL/libGL and may load the new xxx_dri.so drivers? We can version the interfaces and only have certain functionality when everyone agrees on the interfaces (e.g., the recent GLX_ARB_create_context work). This sounds different than what was being discussed above, but I may be mistaken. I'm not sure myself either how exactly gallium's OpenVG implementation is split across shared objects. But intuitively I still think that it must be somehow possible to perserve lib(E)GL.so - xxx_dri.so loose versioning, w/ the gallium state tracker - pipe driver strict versioning, without doing something radically different between gallium and classic dri drivers. For example, leave lib(E)GL.so gallium agnostic, and put the OpenVG state tracker in a shared object on which the gallium based xxx_dri.so drivers can depend. Or something along those lines. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Drooping multiple driver support in EGL?
On 01/13/2012 04:29 PM, Jose Fonseca wrote: - Original Message - On 01/12/2012 09:06 AM, Chia-I Wu wrote: On Tue, Jan 10, 2012 at 12:55 AM, Jose Fonsecajfons...@vmware.com wrote: - Original Message - On Fri, Dec 23, 2011 at 7:51 PM, Chia-I Wuolva...@gmail.com wrote: On Sat, Dec 24, 2011 at 12:37 AM, Ian Romanick i...@freedesktop.org wrote: On 12/23/2011 07:20 AM, Jose Fonseca wrote: - Original Message - Hi list, Multiple driver support in EGL is hard to get right, if not impossible. On Linux desktop, we almost always want to use egl_dri2. It allows EGL to loads DRI2 drivers, thus allowing it to share DRI2 drivers with libGL. In one case where the app wants to use OpenVG, libEGL needs to load egl_gallium instead. The problem comes from that we cannot know that an OpenVG context is to be created until it is created. But before a context can be created, EGL needs to be initialized and an EGLConfig needs to be chosen. So when EGL is to be initialized, we need to load and initilaize all EGL drivers. When an EGLConfig is to be picked, we need to pick it from all drivers. Couldn't we restructure this such that OpenVG (and all other state trackers on Linux) still use a dri2 driver, but one which exposes an additional (gallium specific) interface? I was going to suggest something similar. I think we want fewer EGL backends to test and maintain, not more. Right? I totally agree with that. I even had an unfinished branch for that. Note that this thread is about dropping multiple EGL driver support. The motivation for having OpenVG in DRI2 drivers is that we do not want multiple EGL drivers. The former should push the latter to happen more quickly, instead of preventing it from happening. The problem with exposing the Gallium Interface via the DRI interface is that the DRI interface is public and stable while the Gallium one is not. I think one doesn't invalidate the other. That is, it is technically feasible to have an unstable interface on top of an stable interface. In detail, we could add a stable extension DRI , which exposes Gallium (eg. DRI2GetGalliumScreen). Obviously, for things to work, it would be imperative that the libEGL.so and foo_dri.so were built together, which is already the case today. We don't get to require that lib*GL and *_dri.so be upgraded in lock-step. Ever. I'm afraid I don't understand what you're trying to say.. (Who requires what and why?) Anyway, the fact is that gallium state tracker and pipe driver have to be upgraded in lock-step *today*, and my point is that it must be somehow possible to preserve that constraint, without having to do something completely different from the non-gallium drivers. This is another case where the term DRI is overloaded in an awkward and confusing way. We cannot require that things loader side (libEGL, libGL, or the xserver's GLX module) be updated in lock-step with the drivers or vice versa. We can version the interfaces and only have certain functionality when everyone agrees on the interfaces (e.g., the recent GLX_ARB_create_context work). This sounds different than what was being discussed above, but I may be mistaken. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Drooping multiple driver support in EGL?
On Thu, Jan 12, 2012 at 12:06 PM, Chia-I Wu olva...@gmail.com wrote: On Tue, Jan 10, 2012 at 12:55 AM, Jose Fonseca jfons...@vmware.com wrote: - Original Message - On Fri, Dec 23, 2011 at 7:51 PM, Chia-I Wu olva...@gmail.com wrote: On Sat, Dec 24, 2011 at 12:37 AM, Ian Romanick i...@freedesktop.org wrote: On 12/23/2011 07:20 AM, Jose Fonseca wrote: - Original Message - Hi list, Multiple driver support in EGL is hard to get right, if not impossible. On Linux desktop, we almost always want to use egl_dri2. It allows EGL to loads DRI2 drivers, thus allowing it to share DRI2 drivers with libGL. In one case where the app wants to use OpenVG, libEGL needs to load egl_gallium instead. The problem comes from that we cannot know that an OpenVG context is to be created until it is created. But before a context can be created, EGL needs to be initialized and an EGLConfig needs to be chosen. So when EGL is to be initialized, we need to load and initilaize all EGL drivers. When an EGLConfig is to be picked, we need to pick it from all drivers. Couldn't we restructure this such that OpenVG (and all other state trackers on Linux) still use a dri2 driver, but one which exposes an additional (gallium specific) interface? I was going to suggest something similar. I think we want fewer EGL backends to test and maintain, not more. Right? I totally agree with that. I even had an unfinished branch for that. Note that this thread is about dropping multiple EGL driver support. The motivation for having OpenVG in DRI2 drivers is that we do not want multiple EGL drivers. The former should push the latter to happen more quickly, instead of preventing it from happening. The problem with exposing the Gallium Interface via the DRI interface is that the DRI interface is public and stable while the Gallium one is not. I think one doesn't invalidate the other. That is, it is technically feasible to have an unstable interface on top of an stable interface. In detail, we could add a stable extension DRI , which exposes Gallium (eg. DRI2GetGalliumScreen). Obviously, for things to work, it would be imperative that the libEGL.so and foo_dri.so were built together, which is already the case today. It could be as simple as adding #define __DRI_API_OPENVG 4 with regard to interface change. Then only st/dri needs to be updated to create an OpenVG context when createNewContextForAPI is called. Very much in favor of this. Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Drooping multiple driver support in EGL?
On 01/12/2012 09:06 AM, Chia-I Wu wrote: On Tue, Jan 10, 2012 at 12:55 AM, Jose Fonsecajfons...@vmware.com wrote: - Original Message - On Fri, Dec 23, 2011 at 7:51 PM, Chia-I Wuolva...@gmail.com wrote: On Sat, Dec 24, 2011 at 12:37 AM, Ian Romanick i...@freedesktop.org wrote: On 12/23/2011 07:20 AM, Jose Fonseca wrote: - Original Message - Hi list, Multiple driver support in EGL is hard to get right, if not impossible. On Linux desktop, we almost always want to use egl_dri2. It allows EGL to loads DRI2 drivers, thus allowing it to share DRI2 drivers with libGL. In one case where the app wants to use OpenVG, libEGL needs to load egl_gallium instead. The problem comes from that we cannot know that an OpenVG context is to be created until it is created. But before a context can be created, EGL needs to be initialized and an EGLConfig needs to be chosen. So when EGL is to be initialized, we need to load and initilaize all EGL drivers. When an EGLConfig is to be picked, we need to pick it from all drivers. Couldn't we restructure this such that OpenVG (and all other state trackers on Linux) still use a dri2 driver, but one which exposes an additional (gallium specific) interface? I was going to suggest something similar. I think we want fewer EGL backends to test and maintain, not more. Right? I totally agree with that. I even had an unfinished branch for that. Note that this thread is about dropping multiple EGL driver support. The motivation for having OpenVG in DRI2 drivers is that we do not want multiple EGL drivers. The former should push the latter to happen more quickly, instead of preventing it from happening. The problem with exposing the Gallium Interface via the DRI interface is that the DRI interface is public and stable while the Gallium one is not. I think one doesn't invalidate the other. That is, it is technically feasible to have an unstable interface on top of an stable interface. In detail, we could add a stable extension DRI , which exposes Gallium (eg. DRI2GetGalliumScreen). Obviously, for things to work, it would be imperative that the libEGL.so and foo_dri.so were built together, which is already the case today. We don't get to require that lib*GL and *_dri.so be upgraded in lock-step. Ever. It could be as simple as adding #define __DRI_API_OPENVG 4 with regard to interface change. Then only st/dri needs to be updated to create an OpenVG context when createNewContextForAPI is called. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Drooping multiple driver support in EGL?
- Original Message - On 01/12/2012 09:06 AM, Chia-I Wu wrote: On Tue, Jan 10, 2012 at 12:55 AM, Jose Fonsecajfons...@vmware.com wrote: - Original Message - On Fri, Dec 23, 2011 at 7:51 PM, Chia-I Wuolva...@gmail.com wrote: On Sat, Dec 24, 2011 at 12:37 AM, Ian Romanick i...@freedesktop.org wrote: On 12/23/2011 07:20 AM, Jose Fonseca wrote: - Original Message - Hi list, Multiple driver support in EGL is hard to get right, if not impossible. On Linux desktop, we almost always want to use egl_dri2. It allows EGL to loads DRI2 drivers, thus allowing it to share DRI2 drivers with libGL. In one case where the app wants to use OpenVG, libEGL needs to load egl_gallium instead. The problem comes from that we cannot know that an OpenVG context is to be created until it is created. But before a context can be created, EGL needs to be initialized and an EGLConfig needs to be chosen. So when EGL is to be initialized, we need to load and initilaize all EGL drivers. When an EGLConfig is to be picked, we need to pick it from all drivers. Couldn't we restructure this such that OpenVG (and all other state trackers on Linux) still use a dri2 driver, but one which exposes an additional (gallium specific) interface? I was going to suggest something similar. I think we want fewer EGL backends to test and maintain, not more. Right? I totally agree with that. I even had an unfinished branch for that. Note that this thread is about dropping multiple EGL driver support. The motivation for having OpenVG in DRI2 drivers is that we do not want multiple EGL drivers. The former should push the latter to happen more quickly, instead of preventing it from happening. The problem with exposing the Gallium Interface via the DRI interface is that the DRI interface is public and stable while the Gallium one is not. I think one doesn't invalidate the other. That is, it is technically feasible to have an unstable interface on top of an stable interface. In detail, we could add a stable extension DRI , which exposes Gallium (eg. DRI2GetGalliumScreen). Obviously, for things to work, it would be imperative that the libEGL.so and foo_dri.so were built together, which is already the case today. We don't get to require that lib*GL and *_dri.so be upgraded in lock-step. Ever. I'm afraid I don't understand what you're trying to say.. (Who requires what and why?) Anyway, the fact is that gallium state tracker and pipe driver have to be upgraded in lock-step *today*, and my point is that it must be somehow possible to preserve that constraint, without having to do something completely different from the non-gallium drivers. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Drooping multiple driver support in EGL?
- Original Message - On Fri, Dec 23, 2011 at 7:51 PM, Chia-I Wu olva...@gmail.com wrote: On Sat, Dec 24, 2011 at 12:37 AM, Ian Romanick i...@freedesktop.org wrote: On 12/23/2011 07:20 AM, Jose Fonseca wrote: - Original Message - Hi list, Multiple driver support in EGL is hard to get right, if not impossible. On Linux desktop, we almost always want to use egl_dri2. It allows EGL to loads DRI2 drivers, thus allowing it to share DRI2 drivers with libGL. In one case where the app wants to use OpenVG, libEGL needs to load egl_gallium instead. The problem comes from that we cannot know that an OpenVG context is to be created until it is created. But before a context can be created, EGL needs to be initialized and an EGLConfig needs to be chosen. So when EGL is to be initialized, we need to load and initilaize all EGL drivers. When an EGLConfig is to be picked, we need to pick it from all drivers. Couldn't we restructure this such that OpenVG (and all other state trackers on Linux) still use a dri2 driver, but one which exposes an additional (gallium specific) interface? I was going to suggest something similar. I think we want fewer EGL backends to test and maintain, not more. Right? I totally agree with that. I even had an unfinished branch for that. Note that this thread is about dropping multiple EGL driver support. The motivation for having OpenVG in DRI2 drivers is that we do not want multiple EGL drivers. The former should push the latter to happen more quickly, instead of preventing it from happening. The problem with exposing the Gallium Interface via the DRI interface is that the DRI interface is public and stable while the Gallium one is not. I think one doesn't invalidate the other. That is, it is technically feasible to have an unstable interface on top of an stable interface. In detail, we could add a stable extension DRI , which exposes Gallium (eg. DRI2GetGalliumScreen). Obviously, for things to work, it would be imperative that the libEGL.so and foo_dri.so were built together, which is already the case today. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Drooping multiple driver support in EGL?
- Original Message - Hi list, Multiple driver support in EGL is hard to get right, if not impossible. On Linux desktop, we almost always want to use egl_dri2. It allows EGL to loads DRI2 drivers, thus allowing it to share DRI2 drivers with libGL. In one case where the app wants to use OpenVG, libEGL needs to load egl_gallium instead. The problem comes from that we cannot know that an OpenVG context is to be created until it is created. But before a context can be created, EGL needs to be initialized and an EGLConfig needs to be chosen. So when EGL is to be initialized, we need to load and initilaize all EGL drivers. When an EGLConfig is to be picked, we need to pick it from all drivers. Couldn't we restructure this such that OpenVG (and all other state trackers on Linux) still use a dri2 driver, but one which exposes an additional (gallium specific) interface? Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Drooping multiple driver support in EGL?
On 12/23/2011 07:20 AM, Jose Fonseca wrote: - Original Message - Hi list, Multiple driver support in EGL is hard to get right, if not impossible. On Linux desktop, we almost always want to use egl_dri2. It allows EGL to loads DRI2 drivers, thus allowing it to share DRI2 drivers with libGL. In one case where the app wants to use OpenVG, libEGL needs to load egl_gallium instead. The problem comes from that we cannot know that an OpenVG context is to be created until it is created. But before a context can be created, EGL needs to be initialized and an EGLConfig needs to be chosen. So when EGL is to be initialized, we need to load and initilaize all EGL drivers. When an EGLConfig is to be picked, we need to pick it from all drivers. Couldn't we restructure this such that OpenVG (and all other state trackers on Linux) still use a dri2 driver, but one which exposes an additional (gallium specific) interface? I was going to suggest something similar. I think we want fewer EGL backends to test and maintain, not more. Right? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Drooping multiple driver support in EGL?
On Sat, Dec 24, 2011 at 12:37 AM, Ian Romanick i...@freedesktop.org wrote: On 12/23/2011 07:20 AM, Jose Fonseca wrote: - Original Message - Hi list, Multiple driver support in EGL is hard to get right, if not impossible. On Linux desktop, we almost always want to use egl_dri2. It allows EGL to loads DRI2 drivers, thus allowing it to share DRI2 drivers with libGL. In one case where the app wants to use OpenVG, libEGL needs to load egl_gallium instead. The problem comes from that we cannot know that an OpenVG context is to be created until it is created. But before a context can be created, EGL needs to be initialized and an EGLConfig needs to be chosen. So when EGL is to be initialized, we need to load and initilaize all EGL drivers. When an EGLConfig is to be picked, we need to pick it from all drivers. Couldn't we restructure this such that OpenVG (and all other state trackers on Linux) still use a dri2 driver, but one which exposes an additional (gallium specific) interface? I was going to suggest something similar. I think we want fewer EGL backends to test and maintain, not more. Right? I totally agree with that. I even had an unfinished branch for that. Note that this thread is about dropping multiple EGL driver support. The motivation for having OpenVG in DRI2 drivers is that we do not want multiple EGL drivers. The former should push the latter to happen more quickly, instead of preventing it from happening. -- o...@lunarg.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Drooping multiple driver support in EGL?
On 12/23/2011 10:51 AM, Chia-I Wu wrote: On Sat, Dec 24, 2011 at 12:37 AM, Ian Romanick i...@freedesktop.org wrote: On 12/23/2011 07:20 AM, Jose Fonseca wrote: Couldn't we restructure this such that OpenVG (and all other state trackers on Linux) still use a dri2 driver, but one which exposes an additional (gallium specific) interface? I was going to suggest something similar. I think we want fewer EGL backends to test and maintain, not more. Right? I totally agree with that. I even had an unfinished branch for that. Note that this thread is about dropping multiple EGL driver support. The motivation for having OpenVG in DRI2 drivers is that we do not want multiple EGL drivers. The former should push the latter to happen more quickly, instead of preventing it from happening. I'm totally in favor of having a single EGL driver. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Drooping multiple driver support in EGL?
On Fri, Dec 23, 2011 at 7:51 PM, Chia-I Wu olva...@gmail.com wrote: On Sat, Dec 24, 2011 at 12:37 AM, Ian Romanick i...@freedesktop.org wrote: On 12/23/2011 07:20 AM, Jose Fonseca wrote: - Original Message - Hi list, Multiple driver support in EGL is hard to get right, if not impossible. On Linux desktop, we almost always want to use egl_dri2. It allows EGL to loads DRI2 drivers, thus allowing it to share DRI2 drivers with libGL. In one case where the app wants to use OpenVG, libEGL needs to load egl_gallium instead. The problem comes from that we cannot know that an OpenVG context is to be created until it is created. But before a context can be created, EGL needs to be initialized and an EGLConfig needs to be chosen. So when EGL is to be initialized, we need to load and initilaize all EGL drivers. When an EGLConfig is to be picked, we need to pick it from all drivers. Couldn't we restructure this such that OpenVG (and all other state trackers on Linux) still use a dri2 driver, but one which exposes an additional (gallium specific) interface? I was going to suggest something similar. I think we want fewer EGL backends to test and maintain, not more. Right? I totally agree with that. I even had an unfinished branch for that. Note that this thread is about dropping multiple EGL driver support. The motivation for having OpenVG in DRI2 drivers is that we do not want multiple EGL drivers. The former should push the latter to happen more quickly, instead of preventing it from happening. The problem with exposing the Gallium Interface via the DRI interface is that the DRI interface is public and stable while the Gallium one is not. Cheers, Jakob. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Drooping multiple driver support in EGL?
On 12/22/2011 09:01 AM, Chia-I Wu wrote: Hi list, Multiple driver support in EGL is hard to get right, if not impossible. On Linux desktop, we almost always want to use egl_dri2. It allows EGL to loads DRI2 drivers, thus allowing it to share DRI2 drivers with libGL. In one case where the app wants to use OpenVG, libEGL needs to load egl_gallium instead. The problem comes from that we cannot know that an OpenVG context is to be created until it is created. But before a context can be created, EGL needs to be initialized and an EGLConfig needs to be chosen. So when EGL is to be initialized, we need to load and initilaize all EGL drivers. When an EGLConfig is to be picked, we need to pick it from all drivers. But this also introduces new problems. For example, when the vendor string or the extension string is queried, whose string of all EGL drivers should be returned? My proposal is to simply drop multiple driver support from EGL. Instead, we will provide four libEGL implementations: - libEGL_dri2: derived from egl_dri2 - libEGL_gallium: derived from egl_gallium - libEGL_glx: derived from egl_glx - libEGL_loader: see below Somewhat tangentially...what is the advantage of egl_glx? Does anybody use it? Why? Is it being tested? I'm mostly curious, as I've always used egl_dri2. All of them are conformant EGL implementations. That is, any one of them can be installed as /usr/lib/libEGL.so. libEGL_loader is new. It is basically a wrapper that loads another implementation to do the real work. As such, the problems we face with multiple driver support will remain in libEGL_loader. Distros may choose to install libEGL_loader as libEGL and let it pick the real implementation. Or they may choose to have the first three installed as libEGL, and package them separately. Thoughts? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
