[Mesa-dev] [PATCH 4/4] egl/dri2: add image extension to swrast_core_extensions

[Gurchetan Singh]

Ping...

On Wed, Jun 21, 2017 at 4:40 PM, Gurchetan Singh <
gurchetansingh at chromium.org> wrote:

> Emil,
>
> If I understand you correctly, you're proposing to add the ability to use
> the kms_swrast driver in platform_x11.c (the host is a standard Ubuntu box
> for the emulator use case, not CrOS) alongside swrast.
>
> In that case, we would need to:
>
> 1) Have a dri2_initialize_x11_kms_swrast function that's called when some
> environment variable is set instead of dri2_initialize_x11_swrast.
> 2) dri2_initialize_x11_kms_swrast would need access to the host card fd
> (dri_kms_init_screen requires this) and call dri2_load_driver instead of
> dri2_load_driver_swrast .
> 3) Use dri2_loader_extensions instead of swrast_loader_extensions,
> dri2_x11_display_vtbl instead dri2_x11_swrast_display_vtbl etc.
>
> I'm having trouble getting this to work, and I was wondering if what I'm
> trying to do is what you want.  Attached is the patch I'm trying (it
> compiles, but will crash your display).
>
> Regarding the issues with the emulator, I filed a bug based your comments
> and the emulator team has started looking at it (see
> https://android-review.googlesource.com/#/c/418541/).
>
>
> On Tue, Jun 20, 2017 at 1:19 AM, Emil Velikov <emil.l.velikov at gmail.com>
> wrote:
>
>> On 19 June 2017 at 20:46, Chad Versace <chadversary at 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170626/74c3a1fd/attachment-0001.html>