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

Giovanni Campagna gcampagna at src.gnome.org
Tue Jul 22 10:41:02 PDT 2014


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).
Additionally, it's probably a bad idea to fallback to kms_swrast
unconditionally, because kms_swrast will fail spectacularly on x11 or
wayland.

OTOH, once loaded the driver works fine.

Giovanni


More information about the mesa-dev mailing list