| Message ID | 1406644398-2191-1-git-send-email-alexander.deucher@amd.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Jul 29, 2014 at 10:33:18AM -0400, Alex Deucher wrote: > Return 2 so we can be sure the kernel has the necessary > changes for acceleration to work. I highly dislike that ? Why about just using nop2 in userspace ? > > Signed-off-by: Alex Deucher <alexander.deucher@amd.com> > --- > drivers/gpu/drm/radeon/radeon_kms.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_kms.c b/drivers/gpu/drm/radeon/radeon_kms.c > index 35d9318..dcec4ff 100644 > --- a/drivers/gpu/drm/radeon/radeon_kms.c > +++ b/drivers/gpu/drm/radeon/radeon_kms.c > @@ -254,7 +254,14 @@ static int radeon_info_ioctl(struct drm_device *dev, void *data, struct drm_file > } > break; > case RADEON_INFO_ACCEL_WORKING2: > - *value = rdev->accel_working; > + if (rdev->family == CHIP_HAWAII) { > + if (rdev->accel_working && rdev->new_fw) > + *value = 2; > + else > + *value = 0; > + } else { > + *value = rdev->accel_working; > + } > break; > case RADEON_INFO_TILING_CONFIG: > if (rdev->family >= CHIP_BONAIRE) > -- > 1.8.3.1 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Jul 29, 2014 at 11:39 AM, Jerome Glisse <j.glisse@gmail.com> wrote: > On Tue, Jul 29, 2014 at 10:33:18AM -0400, Alex Deucher wrote: >> Return 2 so we can be sure the kernel has the necessary >> changes for acceleration to work. > > I highly dislike that ? Why about just using nop2 in userspace ? How to we tell whether the version of mesa has that change or not? Also, packet2 nops are deprecated so may not work in future firmwares if we end up updating them again. Alex > >> >> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> >> --- >> drivers/gpu/drm/radeon/radeon_kms.c | 9 ++++++++- >> 1 file changed, 8 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c b/drivers/gpu/drm/radeon/radeon_kms.c >> index 35d9318..dcec4ff 100644 >> --- a/drivers/gpu/drm/radeon/radeon_kms.c >> +++ b/drivers/gpu/drm/radeon/radeon_kms.c >> @@ -254,7 +254,14 @@ static int radeon_info_ioctl(struct drm_device *dev, void *data, struct drm_file >> } >> break; >> case RADEON_INFO_ACCEL_WORKING2: >> - *value = rdev->accel_working; >> + if (rdev->family == CHIP_HAWAII) { >> + if (rdev->accel_working && rdev->new_fw) >> + *value = 2; >> + else >> + *value = 0; >> + } else { >> + *value = rdev->accel_working; >> + } >> break; >> case RADEON_INFO_TILING_CONFIG: >> if (rdev->family >= CHIP_BONAIRE) >> -- >> 1.8.3.1 >> >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Jul 29, 2014 at 01:05:15PM -0400, Alex Deucher wrote: > On Tue, Jul 29, 2014 at 11:39 AM, Jerome Glisse <j.glisse@gmail.com> wrote: > > On Tue, Jul 29, 2014 at 10:33:18AM -0400, Alex Deucher wrote: > >> Return 2 so we can be sure the kernel has the necessary > >> changes for acceleration to work. > > > > I highly dislike that ? Why about just using nop2 in userspace ? > > How to we tell whether the version of mesa has that change or not? You do not need to know that in kernel, all that is needed is for userspace to test 3.16 kernel as it's all that is needed to get accel working. So i would say enable accel on ddx now because truly if someone update its ddx then it must have updated mesa too. > Also, packet2 nops are deprecated so may not work in future firmwares > if we end up updating them again. I do not want to go into discussion on closed source firmware, if they offer no API stability i would consider that utterly broken. > > Alex > > > > >> > >> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> > >> --- > >> drivers/gpu/drm/radeon/radeon_kms.c | 9 ++++++++- > >> 1 file changed, 8 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c b/drivers/gpu/drm/radeon/radeon_kms.c > >> index 35d9318..dcec4ff 100644 > >> --- a/drivers/gpu/drm/radeon/radeon_kms.c > >> +++ b/drivers/gpu/drm/radeon/radeon_kms.c > >> @@ -254,7 +254,14 @@ static int radeon_info_ioctl(struct drm_device *dev, void *data, struct drm_file > >> } > >> break; > >> case RADEON_INFO_ACCEL_WORKING2: > >> - *value = rdev->accel_working; > >> + if (rdev->family == CHIP_HAWAII) { > >> + if (rdev->accel_working && rdev->new_fw) > >> + *value = 2; > >> + else > >> + *value = 0; > >> + } else { > >> + *value = rdev->accel_working; > >> + } > >> break; > >> case RADEON_INFO_TILING_CONFIG: > >> if (rdev->family >= CHIP_BONAIRE) > >> -- > >> 1.8.3.1 > >> > >> _______________________________________________ > >> dri-devel mailing list > >> dri-devel@lists.freedesktop.org > >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
Am 29.07.2014 um 19:10 schrieb Jerome Glisse: > On Tue, Jul 29, 2014 at 01:05:15PM -0400, Alex Deucher wrote: >> On Tue, Jul 29, 2014 at 11:39 AM, Jerome Glisse <j.glisse@gmail.com> wrote: >>> On Tue, Jul 29, 2014 at 10:33:18AM -0400, Alex Deucher wrote: >>>> Return 2 so we can be sure the kernel has the necessary >>>> changes for acceleration to work. >>> I highly dislike that ? Why about just using nop2 in userspace ? >> How to we tell whether the version of mesa has that change or not? > You do not need to know that in kernel, all that is needed is for userspace > to test 3.16 kernel as it's all that is needed to get accel working. So i > would say enable accel on ddx now because truly if someone update its ddx > then it must have updated mesa too. > >> Also, packet2 nops are deprecated so may not work in future firmwares >> if we end up updating them again. > I do not want to go into discussion on closed source firmware, if they offer > no API stability i would consider that utterly broken.e And that's exactly what the firmware guys actually do here, they tell us that nop2 packets are not part of the API any more. The API between different hardware generations was never stable in the first place. Christian. > >> Alex >> >>>> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> >>>> --- >>>> drivers/gpu/drm/radeon/radeon_kms.c | 9 ++++++++- >>>> 1 file changed, 8 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c b/drivers/gpu/drm/radeon/radeon_kms.c >>>> index 35d9318..dcec4ff 100644 >>>> --- a/drivers/gpu/drm/radeon/radeon_kms.c >>>> +++ b/drivers/gpu/drm/radeon/radeon_kms.c >>>> @@ -254,7 +254,14 @@ static int radeon_info_ioctl(struct drm_device *dev, void *data, struct drm_file >>>> } >>>> break; >>>> case RADEON_INFO_ACCEL_WORKING2: >>>> - *value = rdev->accel_working; >>>> + if (rdev->family == CHIP_HAWAII) { >>>> + if (rdev->accel_working && rdev->new_fw) >>>> + *value = 2; >>>> + else >>>> + *value = 0; >>>> + } else { >>>> + *value = rdev->accel_working; >>>> + } >>>> break; >>>> case RADEON_INFO_TILING_CONFIG: >>>> if (rdev->family >= CHIP_BONAIRE) >>>> -- >>>> 1.8.3.1 >>>> >>>> _______________________________________________ >>>> dri-devel mailing list >>>> dri-devel@lists.freedesktop.org >>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Jul 29, 2014 at 1:10 PM, Jerome Glisse <j.glisse@gmail.com> wrote: > On Tue, Jul 29, 2014 at 01:05:15PM -0400, Alex Deucher wrote: >> On Tue, Jul 29, 2014 at 11:39 AM, Jerome Glisse <j.glisse@gmail.com> wrote: >> > On Tue, Jul 29, 2014 at 10:33:18AM -0400, Alex Deucher wrote: >> >> Return 2 so we can be sure the kernel has the necessary >> >> changes for acceleration to work. >> > >> > I highly dislike that ? Why about just using nop2 in userspace ? >> >> How to we tell whether the version of mesa has that change or not? > > You do not need to know that in kernel, all that is needed is for userspace > to test 3.16 kernel as it's all that is needed to get accel working. So i > would say enable accel on ddx now because truly if someone update its ddx > then it must have updated mesa too. > >> Also, packet2 nops are deprecated so may not work in future firmwares >> if we end up updating them again. > > I do not want to go into discussion on closed source firmware, if they offer > no API stability i would consider that utterly broken. > It is stable within a generation. The packet 2 nops were deprecated for CI which is way we switched all the CI parts to use the new packet 3 nop. I must have inadvertently grabbed an old version of the hawaii firmware when I initially released it. Alex >> >> Alex >> >> > >> >> >> >> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> >> >> --- >> >> drivers/gpu/drm/radeon/radeon_kms.c | 9 ++++++++- >> >> 1 file changed, 8 insertions(+), 1 deletion(-) >> >> >> >> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c b/drivers/gpu/drm/radeon/radeon_kms.c >> >> index 35d9318..dcec4ff 100644 >> >> --- a/drivers/gpu/drm/radeon/radeon_kms.c >> >> +++ b/drivers/gpu/drm/radeon/radeon_kms.c >> >> @@ -254,7 +254,14 @@ static int radeon_info_ioctl(struct drm_device *dev, void *data, struct drm_file >> >> } >> >> break; >> >> case RADEON_INFO_ACCEL_WORKING2: >> >> - *value = rdev->accel_working; >> >> + if (rdev->family == CHIP_HAWAII) { >> >> + if (rdev->accel_working && rdev->new_fw) >> >> + *value = 2; >> >> + else >> >> + *value = 0; >> >> + } else { >> >> + *value = rdev->accel_working; >> >> + } >> >> break; >> >> case RADEON_INFO_TILING_CONFIG: >> >> if (rdev->family >= CHIP_BONAIRE) >> >> -- >> >> 1.8.3.1 >> >> >> >> _______________________________________________ >> >> dri-devel mailing list >> >> dri-devel@lists.freedesktop.org >> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
On 30.07.2014 02:10, Jerome Glisse wrote: > On Tue, Jul 29, 2014 at 01:05:15PM -0400, Alex Deucher wrote: >> On Tue, Jul 29, 2014 at 11:39 AM, Jerome Glisse <j.glisse@gmail.com> wrote: >>> On Tue, Jul 29, 2014 at 10:33:18AM -0400, Alex Deucher wrote: >>>> Return 2 so we can be sure the kernel has the necessary >>>> changes for acceleration to work. >>> >>> I highly dislike that ? Why about just using nop2 in userspace ? >> >> How to we tell whether the version of mesa has that change or not? > > You do not need to know that in kernel, all that is needed is for userspace > to test 3.16 kernel as it's all that is needed to get accel working. What if the Hawaii fixes are backported to older kernels? > So i would say enable accel on ddx now because truly if someone update its ddx > then it must have updated mesa too. There is no such guarantee. This looks like a pretty good solution to me. Please add a check for this in the Gallium winsys code as well for the benefit of non-X apps such as Wayland compositors.
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c b/drivers/gpu/drm/radeon/radeon_kms.c index 35d9318..dcec4ff 100644 --- a/drivers/gpu/drm/radeon/radeon_kms.c +++ b/drivers/gpu/drm/radeon/radeon_kms.c @@ -254,7 +254,14 @@ static int radeon_info_ioctl(struct drm_device *dev, void *data, struct drm_file } break; case RADEON_INFO_ACCEL_WORKING2: - *value = rdev->accel_working; + if (rdev->family == CHIP_HAWAII) { + if (rdev->accel_working && rdev->new_fw) + *value = 2; + else + *value = 0; + } else { + *value = rdev->accel_working; + } break; case RADEON_INFO_TILING_CONFIG: if (rdev->family >= CHIP_BONAIRE)
Return 2 so we can be sure the kernel has the necessary changes for acceleration to work. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> --- drivers/gpu/drm/radeon/radeon_kms.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)