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(-)
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)
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.
dri-devel@lists.freedesktop.org