[Mesa-dev] create src/wsi
jason at jlekstrand.net
Mon Oct 23 15:37:21 UTC 2017
On Mon, Oct 23, 2017 at 8:16 AM, Emil Velikov <emil.l.velikov at gmail.com>
> On 23 October 2017 at 16:03, Jason Ekstrand <jason at jlekstrand.net> wrote:
> > On Mon, Oct 23, 2017 at 6:27 AM, Nicolai Hähnle <nhaehnle at gmail.com>
> >> On 21.10.2017 03:00, Dylan Baker wrote:
> >>> This very short series creates a new src/wsi folder, and moves
> >>> wayland-drm into
> >>> it. Basically wsi stuff is scattered about, and is needed by multiple
> >>> components
> >>> within mesa, wayland-drm, for example, is used by EGL, GBM, and vulkan
> >>> wayland-wsi.
> >>> I think there's more that could be moved into wsi, we could move EGL,
> >>> GBM, and
> >>> GLX, and vulkan/wsi, for example.
> >> The general thrust sounds good to me.
> >> Is there a clean model for what should go into src/wsi and what
> >> Where's the boundary?
> >> For an example of the type of headaches, does DRI driver code (stuff
> >> ends up in xxx_dri.so, for example) count as part of src/wsi? If so,
> >> what about gallium/state_trackers/dri? What about
> > Maybe? I guess it depends on what it does and how much sense it makes to
> > share it higher than the gallium level.
> >> I don't have a full picture of all this code so it's hard for me to say,
> >> but I really hope your changes will lead to a clearer picture overall :)
> > Dylan and I talked about it quite a bit off-line so I have a few
> > :) In particular, here's what I envison:
> > src/wsi/gbm
> > src/wsi/egl
> > src/wsi/wayland-drm
> > src/wsi/dri3 (currently src/loader)
> > src/wsi/glx
> > src/wsi/vulkan (currently src/vulkan/wsi)
> > src/wsi/hgl
> Idea is mostly ok, but there's a bit of a snafu:
> Things are not as clean cut/split as per above. Here are some of the
> current inter-dependencies.
> src/loader - loader.c WSI agnostic DRI loader code.
> src/loader - loader_dri3.c X11 DRI3 code.
Ok, so maybe src/wsi/dri3 isn't quite the right name. Maybe we need a
> gbm - depends on loader.c, wayland-drm (I've sent patches to remove this),
> egl - depends on loader.c loader_dri3.c wayland-drm, gbm (pokes one
> of the AMD devs to attempt this)
> vulkan - has completely different wayland-drm/X11 dri3 code.
It does share some code with EGL which is implemented terribly at the
moment. In particular, we need to share all of the Wayland XML and
generated headers and protocol source files. If we ever did a server-side
Wayland Vulkan extension (which I think is probably unlikely), we could
possibly re-use the rest of wayland-drm. This was part of the motivation
for doing this rework.
> One could be able to flatten and use uniform interface across the
I'm not sure what you mean by that. I don't think it's worth it to try and
make a common core codebase to share between GLX, EGL, and Vulkan WSI.
Vulkan is enough different, that I think the current plan of re-rolling the
WSI bits almost entirely is the best plan.
> I would be weary as above code gets limited testing with
Agreed! However, what Dylan is trying to do doesn't involve changing
anything more than some include directories so it should be reasonably safe.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mesa-dev