On 19 June 2017 at 20:46, Chad Versace <chadvers...@chromium.org> wrote: > On Thu 15 Jun 2017, Gurchetan Singh wrote: >> Emil, would you be fine with leaving the image extension in dri2.c but still >> adding it as a drisw extension? That solution would look like: >> >> [1]https://patchwork.freedesktop.org/patch/154807/ > > Observations: > - src/gallium/state_trackers/dri/dri2.c:dri2ImageExtension advertises v15 > of __DRI_IMAGE. > - egl_dri2.c requires only v1 of __DRI_IMAGE. Maybe a higher version > is required in practive, but the egl_dri2.c code checks only for v1. > > Questions: > 1. All functions implemented in dri2.c:dri2ImageExtensions, do they > under swrast? Honest question, because I'm no expert on > gallium. > > If question #1 is true, then I see no problem with your latest plan. But > maybe Emil does. > > If question #1 is false, it should be straightforward to implement in > drisw.c the small subset of __DRI_IMAGE functions required for v1.
While I haven't checked how much [or well] DRI_IMAGE works with swrast, there's no need to actually add it there. An alternative is to add kms_swrast support for EGL like we already do for GBM, as mentioned earlier [1]. Gents, keep in mind that: - one cannot pull DRM specifics (dri2.c) code within drisw.c, and - DRI_IMAGE pulls DRM specifics, hence adding it into drisw.c is again a no-go :-\ FWIW the above architectural split applies for classic drivers as well. swrast_dri.so simply cannot depend on anything DRM related. -Emil [1] https://lists.freedesktop.org/archives/mesa-dev/2017-June/159519.html _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
