Re: kernel errors with HMM enabled
Hi Tom, Yes, we are missing some HMM fixes/changes from 5.1, but the crash log seems not related to those fixes/changes in 5.1. I did see the similar crash log in __mmu_notifier_release path that should be fixed by the patch "use reference counting for HMM struct" as Alex mentioned. Since you have applied that patch, this could be another new issue. May you provide steps how to reproduce the issue while running piglit? Regards, Philip On 2019-03-14 1:18 p.m., Michel Dänzer wrote: > On 2019-03-14 6:10 p.m., StDenis, Tom wrote: >> On 2019-03-14 12:37 p.m., Alex Deucher wrote: >>> Make sure you have this patch: >>> https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-5.2-wip=e811b0a799981eaa6fef1809278367471f14ba13 >> >> Hi Alex, >> >> The tip of our amd-staging-drm-next includes this patch (about 126 down >> from the tip). > > amd-staging-drm-next might be missing more HMM fixes from 5.1, probably > better to wait until we've rebased on that before spending too much more > effort on this. > > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: kernel errors with HMM enabled
On 2019-03-14 6:10 p.m., StDenis, Tom wrote: > On 2019-03-14 12:37 p.m., Alex Deucher wrote: >> Make sure you have this patch: >> https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-5.2-wip=e811b0a799981eaa6fef1809278367471f14ba13 > > Hi Alex, > > The tip of our amd-staging-drm-next includes this patch (about 126 down > from the tip). amd-staging-drm-next might be missing more HMM fixes from 5.1, probably better to wait until we've rebased on that before spending too much more effort on this. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: kernel errors with HMM enabled
On 2019-03-14 12:37 p.m., Alex Deucher wrote: > Make sure you have this patch: > https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-5.2-wip=e811b0a799981eaa6fef1809278367471f14ba13 Hi Alex, The tip of our amd-staging-drm-next includes this patch (about 126 down from the tip). Tom ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amd/display: Only put primary planes into the mode_info->planes list
We want DRM planes to be initialized in the following order:
- primary planes
- overlay planes
- cursor planes
to support existing userspace expectations for plane z-ordering. This
means that we also need to register CRTCs after all planes have been
initialized since overlay planes can be placed on any CRTC.
So the only reason why we have the mode_info->planes list is to
remember the primary planes for use later when we need to register
the CRTC.
Overlay planes have no purpose being in this list. DRM will cleanup
any planes that we've registered for us, so the only planes that need to
be explicitly cleaned up are the ones that have failed to register.
By dropping the explicit free on every plane in the mode_info->planes
list this patch also fixes a double-free in the case where we fail to
initialize only some of the planes.
Cc: Leo Li
Cc: Harry Wentland
Signed-off-by: Nicholas Kazlauskas
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index cde0da3ae964..f770de36121f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1818,8 +1818,6 @@ static int initialize_plane(struct amdgpu_display_manager
*dm,
int ret = 0;
plane = kzalloc(sizeof(struct drm_plane), GFP_KERNEL);
- mode_info->planes[plane_id] = plane;
-
if (!plane) {
DRM_ERROR("KMS: Failed to allocate plane\n");
return -ENOMEM;
@@ -1836,13 +1834,17 @@ static int initialize_plane(struct
amdgpu_display_manager *dm,
if (plane_id >= dm->dc->caps.max_streams)
possible_crtcs = 0xff;
- ret = amdgpu_dm_plane_init(dm, mode_info->planes[plane_id],
possible_crtcs);
+ ret = amdgpu_dm_plane_init(dm, plane, possible_crtcs);
if (ret) {
DRM_ERROR("KMS: Failed to initialize plane\n");
+ kfree(plane);
return ret;
}
+ if (mode_info)
+ mode_info->planes[plane_id] = plane;
+
return ret;
}
@@ -1885,7 +1887,7 @@ static int amdgpu_dm_initialize_drm_device(struct
amdgpu_device *adev)
struct amdgpu_encoder *aencoder = NULL;
struct amdgpu_mode_info *mode_info = >mode_info;
uint32_t link_cnt;
- int32_t overlay_planes, primary_planes, total_planes;
+ int32_t overlay_planes, primary_planes;
enum dc_connection_type new_connection_type = dc_connection_none;
link_cnt = dm->dc->caps.max_links;
@@ -1914,9 +1916,7 @@ static int amdgpu_dm_initialize_drm_device(struct
amdgpu_device *adev)
/* There is one primary plane per CRTC */
primary_planes = dm->dc->caps.max_streams;
-
- total_planes = primary_planes + overlay_planes;
- ASSERT(total_planes <= AMDGPU_MAX_PLANES);
+ ASSERT(primary_planes <= AMDGPU_MAX_PLANES);
/*
* Initialize primary planes, implicit planes for legacy IOCTLS.
@@ -1937,7 +1937,7 @@ static int amdgpu_dm_initialize_drm_device(struct
amdgpu_device *adev)
* Order is reversed to match iteration order in atomic check.
*/
for (i = (overlay_planes - 1); i >= 0; i--) {
- if (initialize_plane(dm, mode_info, primary_planes + i,
+ if (initialize_plane(dm, NULL, primary_planes + i,
DRM_PLANE_TYPE_OVERLAY)) {
DRM_ERROR("KMS: Failed to initialize overlay plane\n");
goto fail;
@@ -2041,8 +2041,7 @@ static int amdgpu_dm_initialize_drm_device(struct
amdgpu_device *adev)
fail:
kfree(aencoder);
kfree(aconnector);
- for (i = 0; i < primary_planes; i++)
- kfree(mode_info->planes[i]);
+
return -EINVAL;
}
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: Slow memory access when using OpenCL without X11
Yes it affects this a bit but it doesn't get the speed up to "normal" level. I got best results with "profile_peak" - then the memcpy speed on CPU is 1/3 of what it is without opencl initialization: echo "profile_peak" > /sys/class/drm/card0/device/power_dpm_force_performance_level ./cl_slow_test 1 5 got 1 platforms 1 devices speed 3710.360352 avg 3710.360352 mbytes/s speed 3713.660400 avg 3712.010254 mbytes/s speed 3797.630859 avg 3740.550537 mbytes/s speed 3708.004883 avg 3732.414062 mbytes/s speed 3796.403076 avg 3745.211914 mbytes/s Without calling clCreateContext: ./cl_slow_test 0 5 speed 7299.201660 avg 7299.201660 mbytes/s speed 9298.841797 avg 8299.021484 mbytes/s speed 9360.181641 avg 8652.742188 mbytes/s speed 9004.759766 avg 8740.746094 mbytes/s speed 9414.607422 avg 8875.518555 mbytes/s -- Lauri On Thu, Mar 14, 2019 at 5:46 PM Ernst Sjöstrand wrote: > Does > echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level > or setting cpu scaling governor to performance affect it at all? > > Regards > //Ernst > > Den tors 14 mars 2019 kl 14:31 skrev Lauri Ehrenpreis >: > > > > I tried also with those 2 boards now: > > https://www.asrock.com/MB/AMD/Fatal1ty%20B450%20Gaming-ITXac/index.asp > > https://www.msi.com/Motherboard/B450I-GAMING-PLUS-AC > > > > Both are using latest BIOS, ubuntu 18.10, kernel > https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.0.2/ > > > > There are some differences in dmesg (asrock has some amdgpu assert in > dmesg) but otherwise results are exactly the same. > > In desktop env cl_slow_test works fast, over ssh terminal it doesn't. If > i move mouse then it starts working fast in terminal as well. > > > > So one can't use OpenCL without monitor and desktop env running and this > happens with 2 different chipsets (b350 & b450), latest bios from 3 > different vendors, latest kernel and latest rocm. This doesn't look like > edge case with unusual setup to me.. > > > > Attached dmesg, dmidecode, and clinfo from both boards. > > > > -- > > Lauri > > > > On Wed, Mar 13, 2019 at 10:15 PM Lauri Ehrenpreis > wrote: > >> > >> For reproduction only the tiny cl_slow_test.cpp is needed which is > attached to first e-mail. > >> > >> System information is following: > >> CPU: Ryzen5 2400G > >> Main board: Gigabyte AMD B450 AORUS mini itx: > https://www.gigabyte.com/Motherboard/B450-I-AORUS-PRO-WIFI-rev-10#kf > >> BIOS: F5 8.47 MB 2019/01/25 (latest) > >> Kernel: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.0/ (amd64) > >> OS: Ubuntu 18.04 LTS > >> rocm-opencl-dev installation: > >> wget -qO - http://repo.radeon.com/rocm/apt/debian/rocm.gpg.key | sudo > apt-key add - > >> echo 'deb [arch=amd64] http://repo.radeon.com/rocm/apt/debian/ xenial > main' | sudo tee /etc/apt/sources.list.d/rocm.list > >> sudo apt install rocm-opencl-dev > >> > >> Also exactly the same issue happens with this board: > https://www.gigabyte.com/Motherboard/GA-AB350-Gaming-3-rev-1x#kf > >> > >> I have MSI and Asrock mini itx boards ready as well, So far didn't get > amdgpu & opencl working there but I'll try again tomorrow.. > >> > >> -- > >> Lauri > >> > >> > >> On Wed, Mar 13, 2019 at 8:51 PM Kuehling, Felix > wrote: > >>> > >>> Hi Lauri, > >>> > >>> I still think the SMU is doing something funny, but rocm-smi isn't > >>> showing enough information to really see what's going on. > >>> > >>> On APUs the SMU firmware is embedded in the system BIOS. Unlike > discrete > >>> GPUs, the SMU firmware is not loaded by the driver. You could try > >>> updating your system BIOS to the latest version available from your > main > >>> board vendor and see if that makes a difference. It may include a newer > >>> version of the SMU firmware, potentially with a fix. > >>> > >>> If that doesn't help, we'd have to reproduce the problem in house to > see > >>> what's happening, which may require the same main board and BIOS > version > >>> you're using. We can ask our SMU firmware team if they've ever > >>> encountered your type of problem. But I don't want to give you too much > >>> hope. It's a tricky problem involving HW, firmware and multiple driver > >>> components in a fairly unusual configuration. > >>> > >>> Regards, > >>>Felix > >>> > >>> On 2019-03-13 7:28 a.m., Lauri Ehrenpreis wrote: > >>> > What I observe is that moving the mouse made the memory speed go up > >>> > and also it made mclk=1200Mhz in rocm-smi output. > >>> > However if I force mclk to 1200Mhz myself then memory speed is still > >>> > slow. > >>> > > >>> > So rocm-smi output when memory speed went fast due to mouse movement: > >>> > rocm-smi > >>> > ROCm System Management Interface > >>> > > >>> > > > >>> > GPU Temp AvgPwr SCLKMCLKPCLK Fan Perf > >>> > PwrCap SCLK OD MCLK OD GPU% > >>> > GPU[0] : WARNING: Empty SysFS value: pclk > >>> > GPU[0] :
Re: kernel errors with HMM enabled
Make sure you have this patch: https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-5.2-wip=e811b0a799981eaa6fef1809278367471f14ba13 Alex On Thu, Mar 14, 2019 at 12:36 PM StDenis, Tom wrote: > > Hi Philip, > > With your HMM patches enabled I'm seeing (attached) kernel errors while > running piglit. Are these known? I see it all along > amd-staging-drm-next until I roll back before your very first HMM patches. > > Tom > ___ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
kernel errors with HMM enabled
Hi Philip, With your HMM patches enabled I'm seeing (attached) kernel errors while running piglit. Are these known? I see it all along amd-staging-drm-next until I roll back before your very first HMM patches. Tom log.gz Description: log.gz ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: Slow memory access when using OpenCL without X11
Does echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level or setting cpu scaling governor to performance affect it at all? Regards //Ernst Den tors 14 mars 2019 kl 14:31 skrev Lauri Ehrenpreis : > > I tried also with those 2 boards now: > https://www.asrock.com/MB/AMD/Fatal1ty%20B450%20Gaming-ITXac/index.asp > https://www.msi.com/Motherboard/B450I-GAMING-PLUS-AC > > Both are using latest BIOS, ubuntu 18.10, kernel > https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.0.2/ > > There are some differences in dmesg (asrock has some amdgpu assert in dmesg) > but otherwise results are exactly the same. > In desktop env cl_slow_test works fast, over ssh terminal it doesn't. If i > move mouse then it starts working fast in terminal as well. > > So one can't use OpenCL without monitor and desktop env running and this > happens with 2 different chipsets (b350 & b450), latest bios from 3 different > vendors, latest kernel and latest rocm. This doesn't look like edge case with > unusual setup to me.. > > Attached dmesg, dmidecode, and clinfo from both boards. > > -- > Lauri > > On Wed, Mar 13, 2019 at 10:15 PM Lauri Ehrenpreis wrote: >> >> For reproduction only the tiny cl_slow_test.cpp is needed which is attached >> to first e-mail. >> >> System information is following: >> CPU: Ryzen5 2400G >> Main board: Gigabyte AMD B450 AORUS mini itx: >> https://www.gigabyte.com/Motherboard/B450-I-AORUS-PRO-WIFI-rev-10#kf >> BIOS: F5 8.47 MB 2019/01/25 (latest) >> Kernel: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.0/ (amd64) >> OS: Ubuntu 18.04 LTS >> rocm-opencl-dev installation: >> wget -qO - http://repo.radeon.com/rocm/apt/debian/rocm.gpg.key | sudo >> apt-key add - >> echo 'deb [arch=amd64] http://repo.radeon.com/rocm/apt/debian/ xenial main' >> | sudo tee /etc/apt/sources.list.d/rocm.list >> sudo apt install rocm-opencl-dev >> >> Also exactly the same issue happens with this board: >> https://www.gigabyte.com/Motherboard/GA-AB350-Gaming-3-rev-1x#kf >> >> I have MSI and Asrock mini itx boards ready as well, So far didn't get >> amdgpu & opencl working there but I'll try again tomorrow.. >> >> -- >> Lauri >> >> >> On Wed, Mar 13, 2019 at 8:51 PM Kuehling, Felix >> wrote: >>> >>> Hi Lauri, >>> >>> I still think the SMU is doing something funny, but rocm-smi isn't >>> showing enough information to really see what's going on. >>> >>> On APUs the SMU firmware is embedded in the system BIOS. Unlike discrete >>> GPUs, the SMU firmware is not loaded by the driver. You could try >>> updating your system BIOS to the latest version available from your main >>> board vendor and see if that makes a difference. It may include a newer >>> version of the SMU firmware, potentially with a fix. >>> >>> If that doesn't help, we'd have to reproduce the problem in house to see >>> what's happening, which may require the same main board and BIOS version >>> you're using. We can ask our SMU firmware team if they've ever >>> encountered your type of problem. But I don't want to give you too much >>> hope. It's a tricky problem involving HW, firmware and multiple driver >>> components in a fairly unusual configuration. >>> >>> Regards, >>>Felix >>> >>> On 2019-03-13 7:28 a.m., Lauri Ehrenpreis wrote: >>> > What I observe is that moving the mouse made the memory speed go up >>> > and also it made mclk=1200Mhz in rocm-smi output. >>> > However if I force mclk to 1200Mhz myself then memory speed is still >>> > slow. >>> > >>> > So rocm-smi output when memory speed went fast due to mouse movement: >>> > rocm-smi >>> > ROCm System Management Interface >>> > >>> > >>> > GPU Temp AvgPwr SCLKMCLKPCLK Fan Perf >>> > PwrCap SCLK OD MCLK OD GPU% >>> > GPU[0] : WARNING: Empty SysFS value: pclk >>> > GPU[0] : WARNING: Unable to read >>> > /sys/class/drm/card0/device/gpu_busy_percent >>> > 0 44.0c N/A 400Mhz 1200Mhz N/A 0% manual N/A >>> > 0%0% N/A >>> > >>> > End of ROCm SMI Log >>> > >>> > >>> > And rocm-smi output when I forced memclk=1200MHz myself: >>> > rocm-smi --setmclk 2 >>> > rocm-smi >>> > ROCm System Management Interface >>> > >>> > >>> > GPU Temp AvgPwr SCLKMCLKPCLK Fan Perf >>> > PwrCap SCLK OD MCLK OD GPU% >>> > GPU[0] : WARNING: Empty SysFS value: pclk >>> > GPU[0] : WARNING: Unable to read >>> > /sys/class/drm/card0/device/gpu_busy_percent >>> > 0 39.0c N/A 400Mhz 1200Mhz N/A 0% manual N/A >>> > 0%0% N/A >>> >
Re: [PATCH xf86-video-ati] modesetting: add tile property support
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Michel
Dänzer
Sent: Thursday, March 14, 2019 6:19 AM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH xf86-video-ati] modesetting: add tile property support
From: Dave Airlie
This adds tiling support to the driver, it retrieves the tile info from
the kernel and translates it into the server format and exposes the
property.
(Ported from xserver commits 8fb8bbb3062f1a06621ab7030a9e89d5e8367b35
and 6abdb54a11dac4e8854ff94ecdcb90a14321ab31)
(Ported from amdgpu commit 6ee857726166f495abcd68e4ff60e3a09593d079)
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 54 +--
src/drmmode_display.h | 3 +++
2 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 002513f1a..0e9e24749 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -1576,6 +1576,51 @@ drmmode_output_mode_valid(xf86OutputPtr output,
DisplayModePtr pModes)
return MODE_OK;
}
+static void
+drmmode_output_attach_tile(xf86OutputPtr output)
+{
+#if XORG_VERSION_CURRENT >= XORG_VERSION_NUMERIC(1, 17, 99, 901, 0)
+ drmmode_output_private_ptr drmmode_output = output->driver_private;
+ drmModeConnectorPtr koutput = drmmode_output->mode_output;
+ RADEONEntPtr pRADEONEnt = RADEONEntPriv(output->scrn);
+ struct xf86CrtcTileInfo tile_info, *set = NULL;
+ int i;
+
+ if (!koutput) {
+ xf86OutputSetTile(output, NULL);
+ return;
+ }
+
+ /* look for a TILE property */
+ for (i = 0; i < koutput->count_props; i++) {
+ drmModePropertyPtr props;
+ props = drmModeGetProperty(pRADEONEnt->fd, koutput->props[i]);
+ if (!props)
+ continue;
+
+ if (!(props->flags & DRM_MODE_PROP_BLOB)) {
+ drmModeFreeProperty(props);
+ continue;
+ }
+
+ if (!strcmp(props->name, "TILE")) {
+ drmModeFreePropertyBlob(drmmode_output->tile_blob);
+ drmmode_output->tile_blob =
+ drmModeGetPropertyBlob(pRADEONEnt->fd,
+ koutput->prop_values[i]);
+ }
+ drmModeFreeProperty(props);
+ }
+ if (drmmode_output->tile_blob) {
+ if (xf86OutputParseKMSTile(drmmode_output->tile_blob->data,
+ drmmode_output->tile_blob->length,
+ _info) == TRUE)
+ set = _info;
+ }
+ xf86OutputSetTile(output, set);
+#endif
+}
+
static int
koutput_get_prop_idx(int fd, drmModeConnectorPtr koutput,
int type, const char *name)
@@ -1648,6 +1693,8 @@ drmmode_output_get_modes(xf86OutputPtr output)
}
xf86OutputSetEDID(output, mon);
+ drmmode_output_attach_tile(output);
+
/* modes should already be available */
for (i = 0; i < koutput->count_modes; i++) {
Mode = xnfalloc(sizeof(DisplayModeRec));
@@ -1665,8 +1712,11 @@ drmmode_output_destroy(xf86OutputPtr output)
drmmode_output_private_ptr drmmode_output = output->driver_private;
int i;
- if (drmmode_output->edid_blob)
- drmModeFreePropertyBlob(drmmode_output->edid_blob);
+ drmModeFreePropertyBlob(drmmode_output->edid_blob);
+#if XORG_VERSION_CURRENT >= XORG_VERSION_NUMERIC(1, 17, 99, 901, 0)
+ drmModeFreePropertyBlob(drmmode_output->tile_blob);
+#endif
+
for (i = 0; i < drmmode_output->num_props; i++) {
drmModeFreeProperty(drmmode_output->props[i].mode_prop);
free(drmmode_output->props[i].atoms);
diff --git a/src/drmmode_display.h b/src/drmmode_display.h
index 2c2c3d57f..96eaef0aa 100644
--- a/src/drmmode_display.h
+++ b/src/drmmode_display.h
@@ -142,6 +142,9 @@ typedef struct {
drmModeConnectorPtr mode_output;
drmModeEncoderPtr *mode_encoders;
drmModePropertyBlobPtr edid_blob;
+#if XORG_VERSION_CURRENT >= XORG_VERSION_NUMERIC(1, 17, 99, 901, 0)
+drmModePropertyBlobPtr tile_blob;
+#endif
int dpms_enum_id;
int num_props;
drmmode_prop_ptr props;
--
2.20.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH xf86-video-ati] Use radeon_finish in drmmode_crtc_scanout_update
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Michel
Dänzer
Sent: Thursday, March 14, 2019 6:15 AM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH xf86-video-ati] Use radeon_finish in drmmode_crtc_scanout_update
From: Michel Dänzer
radeon_glamor_finish only works if we're using glamor, otherwise it'll
crash.
Fixes: ce7db51020d3 "Cancel pending scanout update in
drmmode_crtc_scanout_update"
Bug: https://bugs.debian.org/924540
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index c5fccd2aa..002513f1a 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -785,7 +785,7 @@ drmmode_crtc_scanout_update(xf86CrtcPtr crtc,
DisplayModePtr mode,
screen->GetWindowPixmap(screen->root),
extents)) {
RegionEmpty(DamageRegion(drmmode_crtc->scanout_damage));
- radeon_glamor_finish(scrn);
+ radeon_finish(scrn,
drmmode_crtc->scanout[scanout_id].bo);
if (!drmmode_crtc->flip_pending) {
radeon_drm_abort_entry(drmmode_crtc->
--
2.20.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH xf86-video-ati] modesetting: add tile property support
From: Dave Airlie
This adds tiling support to the driver, it retrieves the tile info from
the kernel and translates it into the server format and exposes the
property.
(Ported from xserver commits 8fb8bbb3062f1a06621ab7030a9e89d5e8367b35
and 6abdb54a11dac4e8854ff94ecdcb90a14321ab31)
(Ported from amdgpu commit 6ee857726166f495abcd68e4ff60e3a09593d079)
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 54 +--
src/drmmode_display.h | 3 +++
2 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 002513f1a..0e9e24749 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -1576,6 +1576,51 @@ drmmode_output_mode_valid(xf86OutputPtr output,
DisplayModePtr pModes)
return MODE_OK;
}
+static void
+drmmode_output_attach_tile(xf86OutputPtr output)
+{
+#if XORG_VERSION_CURRENT >= XORG_VERSION_NUMERIC(1, 17, 99, 901, 0)
+ drmmode_output_private_ptr drmmode_output = output->driver_private;
+ drmModeConnectorPtr koutput = drmmode_output->mode_output;
+ RADEONEntPtr pRADEONEnt = RADEONEntPriv(output->scrn);
+ struct xf86CrtcTileInfo tile_info, *set = NULL;
+ int i;
+
+ if (!koutput) {
+ xf86OutputSetTile(output, NULL);
+ return;
+ }
+
+ /* look for a TILE property */
+ for (i = 0; i < koutput->count_props; i++) {
+ drmModePropertyPtr props;
+ props = drmModeGetProperty(pRADEONEnt->fd, koutput->props[i]);
+ if (!props)
+ continue;
+
+ if (!(props->flags & DRM_MODE_PROP_BLOB)) {
+ drmModeFreeProperty(props);
+ continue;
+ }
+
+ if (!strcmp(props->name, "TILE")) {
+ drmModeFreePropertyBlob(drmmode_output->tile_blob);
+ drmmode_output->tile_blob =
+ drmModeGetPropertyBlob(pRADEONEnt->fd,
+ koutput->prop_values[i]);
+ }
+ drmModeFreeProperty(props);
+ }
+ if (drmmode_output->tile_blob) {
+ if (xf86OutputParseKMSTile(drmmode_output->tile_blob->data,
+ drmmode_output->tile_blob->length,
+ _info) == TRUE)
+ set = _info;
+ }
+ xf86OutputSetTile(output, set);
+#endif
+}
+
static int
koutput_get_prop_idx(int fd, drmModeConnectorPtr koutput,
int type, const char *name)
@@ -1648,6 +1693,8 @@ drmmode_output_get_modes(xf86OutputPtr output)
}
xf86OutputSetEDID(output, mon);
+ drmmode_output_attach_tile(output);
+
/* modes should already be available */
for (i = 0; i < koutput->count_modes; i++) {
Mode = xnfalloc(sizeof(DisplayModeRec));
@@ -1665,8 +1712,11 @@ drmmode_output_destroy(xf86OutputPtr output)
drmmode_output_private_ptr drmmode_output = output->driver_private;
int i;
- if (drmmode_output->edid_blob)
- drmModeFreePropertyBlob(drmmode_output->edid_blob);
+ drmModeFreePropertyBlob(drmmode_output->edid_blob);
+#if XORG_VERSION_CURRENT >= XORG_VERSION_NUMERIC(1, 17, 99, 901, 0)
+ drmModeFreePropertyBlob(drmmode_output->tile_blob);
+#endif
+
for (i = 0; i < drmmode_output->num_props; i++) {
drmModeFreeProperty(drmmode_output->props[i].mode_prop);
free(drmmode_output->props[i].atoms);
diff --git a/src/drmmode_display.h b/src/drmmode_display.h
index 2c2c3d57f..96eaef0aa 100644
--- a/src/drmmode_display.h
+++ b/src/drmmode_display.h
@@ -142,6 +142,9 @@ typedef struct {
drmModeConnectorPtr mode_output;
drmModeEncoderPtr *mode_encoders;
drmModePropertyBlobPtr edid_blob;
+#if XORG_VERSION_CURRENT >= XORG_VERSION_NUMERIC(1, 17, 99, 901, 0)
+drmModePropertyBlobPtr tile_blob;
+#endif
int dpms_enum_id;
int num_props;
drmmode_prop_ptr props;
--
2.20.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH xf86-video-ati] Use radeon_finish in drmmode_crtc_scanout_update
From: Michel Dänzer
radeon_glamor_finish only works if we're using glamor, otherwise it'll
crash.
Fixes: ce7db51020d3 "Cancel pending scanout update in
drmmode_crtc_scanout_update"
Bug: https://bugs.debian.org/924540
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index c5fccd2aa..002513f1a 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -785,7 +785,7 @@ drmmode_crtc_scanout_update(xf86CrtcPtr crtc,
DisplayModePtr mode,
screen->GetWindowPixmap(screen->root),
extents)) {
RegionEmpty(DamageRegion(drmmode_crtc->scanout_damage));
- radeon_glamor_finish(scrn);
+ radeon_finish(scrn,
drmmode_crtc->scanout[scanout_id].bo);
if (!drmmode_crtc->flip_pending) {
radeon_drm_abort_entry(drmmode_crtc->
--
2.20.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
