On 23 October 2017 at 16:03, Jason Ekstrand <ja...@jlekstrand.net> wrote: > On Mon, Oct 23, 2017 at 6:27 AM, Nicolai Hähnle <nhaeh...@gmail.com> wrote: >> >> 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 shouldn't? >> Where's the boundary? >> >> For an example of the type of headaches, does DRI driver code (stuff that >> ends up in xxx_dri.so, for example) count as part of src/wsi? If so, then >> what about gallium/state_trackers/dri? What about mesa/drivers/dri/common? > > > 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 opinions. > :) 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. gbm - depends on loader.c, wayland-drm (I've sent patches to remove this), egl 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. One could be able to flatten and use uniform interface across the board. I would be weary as above code gets limited testing with piglit/CTS/dEQP. -Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
