[Mesa-dev] [PATCH v4 0/3] Software rendering in EGL-DRM

[Emil Velikov]

On 22/07/14 18:41, Giovanni Campagna wrote:
> On Mon, Jul 21, 2014 at 9:54 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 21/07/14 17:02, Giovanni Campagna wrote:
>>> On Mon, Jul 21, 2014 at 12:47 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>> Giovanni can you test the series that I've not butchered anything else during
>>>> the rebase ?
>>>
>>> Oh hey, sorry I missed the bit that I was expected to test the patches.
>>> Unfortunately, something indeed got lost: the logic to choose the
>>> kms_swrast driver in preference to the swrast one.
>>>
>>> In my patches, I had:
>>>
>>> static int
>>> dri_screen_create_sw(struct gbm_dri_device *dri)
>>> {
>>>    int ret;
>>>
>>>    ret = dri_screen_create_dri2(dri, "kms_swrast");
>>>    if (ret == 0)
>>>       return ret;
>>>
>>>    return dri_screen_create_swrast(dri);
>>> }
>>>
>>> That would take the place of dri_screen_create_swrast in the
>>> dri_device_create() call site.
>>> With your patches, the kms_swrast driver is effectively never loaded.
>>>
>> Am I day-dreaming, or is this the same as your initial concern as stated here
>> [0] ? If so I believe that this should be fully addressed with the follow-up
>> revision of patches 1 [1] & 2 [2].
>>
>> Perhaps the updated patches never made it to your inbox :'(
> 
> My bad, I was testing the old patch.
> Nevertheless, the new patch is not working either: after the
> megadrivers work, the new kms_swrast_dri is trying to load ilo when
> run on an intel card with GBM_ALWAYS_SOFTWARE, because
> loader_get_pci_from_fd() returns i965. This fails because ilo is not
> compiled in (and even if ilo was compiled, it would fail because ilo
> does not support my GM45).
> Then weston crashes using the swrast driver, because at that point the
> kms_swrast driver was already partially loaded and extensions bound
> (so it takes a mixture of swrast and dri2 paths).
> 
> On intel, this problem can be worked around by removing the
> LOADER_GALLIUM from the i965 entry in the pci_id_driver_map table, but
> on nouveau/r600g/radeonsi it would result on a working GBM, HW
> accelerated despite the environment variable. I believe the
> _getDriverExtension_kms_swrast() function should return a different
> extension table for kms_swrast (one that references a InitScreen that
> always initializes a kms_swrast screen).
Good catch! The series targets qxl and similar devices so I haven't considered
the case when someone forces kms_swrast on a HWaccel capable setup.

> Additionally, it's probably a bad idea to fallback to kms_swrast
> unconditionally, because kms_swrast will fail spectacularly on x11 or
> wayland.
> 
Adding a separate InitScreen hook which explicitly calls
pipe_kms_swrast_create_screen() sounds like the most sensible thing IMHO.

Huge thanks for the help.

-Emil

P.S. I dare you to test the branch on your intel setup for a normal gbm/egl
workload. Hint, dri_screen_create() will succeed, yet dri_screen_create_sw()
will be executed as well :)

> OTOH, once loaded the driver works fine.
> 
> Giovanni
>