Re: [Mesa-dev] [PATCH v4 0/3] Software rendering in EGL-DRM
On Mon, Jul 21, 2014 at 9:54 PM, Emil Velikov wrote:
> On 21/07/14 17:02, Giovanni Campagna wrote:
>> On Mon, Jul 21, 2014 at 12:47 PM, Emil Velikov
>> 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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 0/3] Software rendering in EGL-DRM
On 22/07/14 18:41, Giovanni Campagna wrote:
> On Mon, Jul 21, 2014 at 9:54 PM, Emil Velikov
> wrote:
>> On 21/07/14 17:02, Giovanni Campagna wrote:
>>> On Mon, Jul 21, 2014 at 12:47 PM, Emil Velikov
>>> 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
Re: [Mesa-dev] [PATCH v4 0/3] Software rendering in EGL-DRM
On Mon, Jul 21, 2014 at 12:47 PM, Emil Velikov 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.
Giovanni
> Thanks
> Emil
>
> On 11/07/14 18:19, Emil Velikov wrote:
>> Hello all,
>>
>> Here is hopefully the last iteration of Giovanni's patches, rebased
>> on top of the buildsystem "mayhem" that I've caused recently.
>>
>> I've a few small changes in patch 1, most significant of which is
>> s/LIBGL_ALWAYS_SOFTWARE/GBM_ALWAYS_SOFTWARE, as I think that having an
>> LIBGL envvar to control gbm is ambiguous and may cause some unexpected
>> issues.
>>
>> Giovanni can you please test that I haven't broken the series with
>> megadrivers and/or during rebase.
>>
>> Thanks,
>> Emil
>>
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 0/3] Software rendering in EGL-DRM
On 21/07/14 17:02, Giovanni Campagna wrote:
> On Mon, Jul 21, 2014 at 12:47 PM, Emil Velikov
> 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 :'(
-Emil
[0] http://lists.freedesktop.org/archives/mesa-dev/2014-July/063260.html
[1] http://lists.freedesktop.org/archives/mesa-dev/2014-July/063236.html
[2] http://lists.freedesktop.org/archives/mesa-dev/2014-July/063237.html
> Giovanni
>
>> Thanks
>> Emil
>>
>> On 11/07/14 18:19, Emil Velikov wrote:
>>> Hello all,
>>>
>>> Here is hopefully the last iteration of Giovanni's patches, rebased
>>> on top of the buildsystem "mayhem" that I've caused recently.
>>>
>>> I've a few small changes in patch 1, most significant of which is
>>> s/LIBGL_ALWAYS_SOFTWARE/GBM_ALWAYS_SOFTWARE, as I think that having an
>>> LIBGL envvar to control gbm is ambiguous and may cause some unexpected
>>> issues.
>>>
>>> Giovanni can you please test that I haven't broken the series with
>>> megadrivers and/or during rebase.
>>>
>>> Thanks,
>>> Emil
>>>
>>>
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 0/3] Software rendering in EGL-DRM
Giovanni can you test the series that I've not butchered anything else during the rebase ? Thanks Emil On 11/07/14 18:19, Emil Velikov wrote: > Hello all, > > Here is hopefully the last iteration of Giovanni's patches, rebased > on top of the buildsystem "mayhem" that I've caused recently. > > I've a few small changes in patch 1, most significant of which is > s/LIBGL_ALWAYS_SOFTWARE/GBM_ALWAYS_SOFTWARE, as I think that having an > LIBGL envvar to control gbm is ambiguous and may cause some unexpected > issues. > > Giovanni can you please test that I haven't broken the series with > megadrivers and/or during rebase. > > Thanks, > Emil > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v4 0/3] Software rendering in EGL-DRM
Hello all, Here is hopefully the last iteration of Giovanni's patches, rebased on top of the buildsystem "mayhem" that I've caused recently. I've a few small changes in patch 1, most significant of which is s/LIBGL_ALWAYS_SOFTWARE/GBM_ALWAYS_SOFTWARE, as I think that having an LIBGL envvar to control gbm is ambiguous and may cause some unexpected issues. Giovanni can you please test that I haven't broken the series with megadrivers and/or during rebase. Thanks, Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
