<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 23, 2017 at 8:16 AM, Emil Velikov <span dir="ltr"><<a href="mailto:emil.l.velikov@gmail.com" target="_blank">emil.l.velikov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 23 October 2017 at 16:03, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>
> On Mon, Oct 23, 2017 at 6:27 AM, Nicolai Hähnle <<a href="mailto:nhaehnle@gmail.com">nhaehnle@gmail.com</a>> wrote:<br>
>><br>
>> On 21.10.2017 03:00, Dylan Baker wrote:<br>
>>><br>
>>> This very short series creates a new src/wsi folder, and moves<br>
>>> wayland-drm into<br>
>>> it. Basically wsi stuff is scattered about, and is needed by multiple<br>
>>> components<br>
>>> within mesa, wayland-drm, for example, is used by EGL, GBM, and vulkan<br>
>>> wayland-wsi.<br>
>>><br>
>>> I think there's more that could be moved into wsi, we could move EGL,<br>
>>> GBM, and<br>
>>> GLX, and vulkan/wsi, for example.<br>
>><br>
>><br>
>> The general thrust sounds good to me.<br>
>><br>
>> Is there a clean model for what should go into src/wsi and what shouldn't?<br>
>> Where's the boundary?<br>
>><br>
>> For an example of the type of headaches, does DRI driver code (stuff that<br>
>> ends up in xxx_dri.so, for example) count as part of src/wsi? If so, then<br>
>> what about gallium/state_trackers/dri? What about mesa/drivers/dri/common?<br>
><br>
><br>
> Maybe?  I guess it depends on what it does and how much sense it makes to<br>
> share it higher than the gallium level.<br>
><br>
>><br>
>> I don't have a full picture of all this code so it's hard for me to say,<br>
>> but I really hope your changes will lead to a clearer picture overall :)<br>
><br>
><br>
> Dylan and I talked about it quite a bit off-line so I have a few opinions.<br>
> :)  In particular, here's what I envison:<br>
><br>
> src/wsi/gbm<br>
> src/wsi/egl<br>
> src/wsi/wayland-drm<br>
> src/wsi/dri3 (currently src/loader)<br>
> src/wsi/glx<br>
> src/wsi/vulkan (currently src/vulkan/wsi)<br>
> src/wsi/hgl<br>
><br>
</div></div>Idea is mostly ok, but there's a bit of a snafu:<br>
<br>
Things are not as clean cut/split as per above. Here are some of the<br>
current inter-dependencies.<br>
<br>
src/loader - loader.c WSI agnostic DRI loader code.<br>
src/loader - loader_dri3.c X11 DRI3 code.<br></blockquote><div><br></div><div>Ok, so maybe src/wsi/dri3 isn't quite the right name.  Maybe we need a src/wsi/dri-loader.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
gbm - depends on loader.c, wayland-drm (I've sent patches to remove this), egl<br>
egl  - depends on loader.c loader_dri3.c wayland-drm, gbm (pokes one<br>
of the AMD devs to attempt this)<br>
vulkan - has completely different wayland-drm/X11 dri3 code.<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One could be able to flatten and use uniform interface across the<br>
board.</blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would be weary as above code gets limited testing with<br>
piglit/CTS/dEQP.<br></blockquote><div><br></div><div>Agreed!  However, what Dylan is trying to do doesn't involve changing anything more than some include directories so it should be reasonably safe.<br></div><div><br></div><div>--Jason<br></div></div></div></div>