On 22/07/14 18:41, Giovanni Campagna wrote: > On Mon, Jul 21, 2014 at 9:54 PM, Emil Velikov <emil.l.veli...@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.veli...@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 > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev