[PATCH xf86-video-ati] Don't install Flush/EventCallback for GPU screens
From: Michel Dänzer <michel.daen...@amd.com>
Their purpose is to flush GPU rendering commands corresponding to damage
events, but there can be no damage events corresponding to GPU screen
rendering operations.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/radeon_kms.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/radeon_kms.c b/src/radeon_kms.c
index 2f783a0..a5943d1 100644
--- a/src/radeon_kms.c
+++ b/src/radeon_kms.c
@@ -302,7 +302,7 @@ radeon_flush_callback(CallbackListPtr *list,
static Bool RADEONCreateScreenResources_KMS(ScreenPtr pScreen)
{
-ExtensionEntry *damage_ext = CheckExtension("DAMAGE");
+ExtensionEntry *damage_ext;
ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
RADEONInfoPtr info = RADEONPTR(pScrn);
PixmapPtr pixmap;
@@ -360,7 +360,7 @@ static Bool RADEONCreateScreenResources_KMS(ScreenPtr
pScreen)
radeon_glamor_create_screen_resources(pScreen);
info->callback_event_type = -1;
-if (damage_ext) {
+if (!pScreen->isGPU && (damage_ext = CheckExtension("DAMAGE"))) {
info->callback_event_type = damage_ext->eventBase + XDamageNotify;
if (!AddCallback(, radeon_flush_callback, pScrn))
--
2.10.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH xf86-video-ati] Use DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags when available
From: Michel Dänzer <michel.daen...@amd.com>
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/drmmode_display.c | 100 --
src/drmmode_display.h | 11 +-
src/radeon_dri2.c | 3 +-
src/radeon_kms.c | 15
src/radeon_present.c | 5 ++-
src/radeon_probe.h| 1 +
6 files changed, 112 insertions(+), 23 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 070979d..8839616 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -2301,6 +2301,71 @@ drm_wakeup_handler(pointer data, int err, pointer p)
}
}
+static Bool drmmode_probe_page_flip_target(drmmode_ptr drmmode)
+{
+#ifdef DRM_CAP_PAGE_FLIP_TARGET
+ uint64_t cap_value;
+
+ return drmGetCap(drmmode->fd, DRM_CAP_PAGE_FLIP_TARGET,
+_value) == 0 && cap_value != 0;
+#else
+ return FALSE;
+#endif
+}
+
+static int
+drmmode_page_flip(drmmode_crtc_private_ptr drmmode_crtc, uint32_t flags,
+ uintptr_t drm_queue_seq)
+{
+ drmmode_ptr drmmode = drmmode_crtc->drmmode;
+
+ flags |= DRM_MODE_PAGE_FLIP_EVENT;
+ return drmModePageFlip(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id,
+ drmmode->fb_id, flags, (void*)drm_queue_seq);
+}
+
+int
+drmmode_page_flip_target_absolute(RADEONEntPtr pRADEONEnt,
+ drmmode_crtc_private_ptr drmmode_crtc,
+ uint32_t flags, uintptr_t drm_queue_seq,
+ uint32_t target_msc)
+{
+#ifdef DRM_MODE_PAGE_FLIP_TARGET
+ if (pRADEONEnt->has_page_flip_target) {
+ drmmode_ptr drmmode = drmmode_crtc->drmmode;
+
+ flags |= DRM_MODE_PAGE_FLIP_EVENT |
DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE;
+ return drmModePageFlipTarget(drmmode->fd,
+drmmode_crtc->mode_crtc->crtc_id,
+drmmode->fb_id, flags,
+(void*)drm_queue_seq, target_msc);
+ }
+#endif
+
+ return drmmode_page_flip(drmmode_crtc, flags, drm_queue_seq);
+}
+
+int
+drmmode_page_flip_target_relative(RADEONEntPtr pRADEONEnt,
+ drmmode_crtc_private_ptr drmmode_crtc,
+ uint32_t flags, uintptr_t drm_queue_seq,
+ uint32_t target_msc)
+{
+#ifdef DRM_MODE_PAGE_FLIP_TARGET
+ if (pRADEONEnt->has_page_flip_target) {
+ drmmode_ptr drmmode = drmmode_crtc->drmmode;
+
+ flags |= DRM_MODE_PAGE_FLIP_EVENT |
DRM_MODE_PAGE_FLIP_TARGET_RELATIVE;
+ return drmModePageFlipTarget(drmmode->fd,
+drmmode_crtc->mode_crtc->crtc_id,
+drmmode->fb_id, flags,
+(void*)drm_queue_seq, target_msc);
+ }
+#endif
+
+ return drmmode_page_flip(drmmode_crtc, flags, drm_queue_seq);
+}
+
Bool drmmode_pre_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, int cpp)
{
RADEONEntPtr pRADEONEnt = RADEONEntPriv(pScrn);
@@ -2366,6 +2431,8 @@ Bool drmmode_pre_init(ScrnInfoPtr pScrn, drmmode_ptr
drmmode, int cpp)
drmmode->event_context.vblank_handler = radeon_drm_queue_handler;
drmmode->event_context.page_flip_handler = radeon_drm_queue_handler;
+ pRADEONEnt->has_page_flip_target =
drmmode_probe_page_flip_target(drmmode);
+
drmModeFreeResources(mode_res);
return TRUE;
}
@@ -2714,8 +2781,10 @@ Bool radeon_do_pageflip(ScrnInfoPtr scrn, ClientPtr
client,
uint32_t new_front_handle, uint64_t id, void *data,
int ref_crtc_hw_id, radeon_drm_handler_proc handler,
radeon_drm_abort_proc abort,
- enum drmmode_flip_sync flip_sync)
+ enum drmmode_flip_sync flip_sync,
+ uint32_t target_msc)
{
+ RADEONEntPtr pRADEONEnt = RADEONEntPriv(scrn);
RADEONInfoPtr info = RADEONPTR(scrn);
xf86CrtcConfigPtr config = XF86_CRTC_CONFIG_PTR(scrn);
xf86CrtcPtr crtc = NULL;
@@ -2724,7 +2793,7 @@ Bool radeon_do_pageflip(ScrnInfoPtr scrn, ClientPtr
client,
unsigned int pitch;
int i;
uint32_t tiling_flags = 0;
- uint32_t flip_flags = DRM_MODE_PAGE_FLIP_EVENT;
+ uint32_t flip_flags = flip_sync == FLIP_ASYNC ?
DRM_MODE_PAGE_FLIP_ASYNC : 0;
drmmode_flipdata_ptr flipdata;
uintptr_t drm_queue_seq = 0;
@@ -2771,9 +2840,6 @@ Bool radeon_do_pageflip(ScrnInfoPtr scrn, ClientPtr
client,
flipdata->handler = handler;
flipdata->abort = abort;
- if (flip_sync == FLIP_ASYNC)
- flip_flags |= DRM_MODE_PAGE_FLIP_ASYNC;
Re: [1/4] amdgpu: add the function to get the marketing name (v2)
On 13/09/16 12:14 AM, Alex Deucher wrote:
> From: Junwei Zhang <jerry.zh...@amd.com>
>
> This function is used to look up the marking name
> for a specific board.
>
> v2: agd: Squash in subsequent updates to the table.
As is, this breaks make check:
> +struct amdgpu_asic_id_table_t {
Make this static, so the amdgpu_asic_id_table_t symbol doesn't get
exported from libdrm_amdgpu.
BTW, is there any particular reason for putting this table in a separate
header file?
> @@ -303,3 +304,17 @@ int amdgpu_device_deinitialize(amdgpu_device_handle dev)
> amdgpu_device_reference(, NULL);
> return 0;
> }
> +
> +const char *amdgpu_get_marketing_name(amdgpu_device_handle dev)
amdgpu_get_marketing_name needs to be added to amdgpu-symbols-check.
> + if ((t->did == dev->info.asic_id) &&
> + (t->rid == dev->info.pci_rev_id))
Wrong indentation of the second line.
With these issues fixed,
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
Would be nice to land this in master soon, as we're going to use it in
xf86-video-amdgpu: https://patchwork.freedesktop.org/patch/119501/
--
Earthling Michel Dänzer | http://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
[PATCH xf86-video-amdgpu 7/7] Remove generated header files
From: Michel Dänzer <michel.daen...@amd.com>
No longer used.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/Makefile.am | 7 --
src/amdgpu_chipinfo_gen.h | 194 --
src/amdgpu_chipset_gen.h | 216 --
src/amdgpu_pci_chipset_gen.h | 195 --
src/amdgpu_pci_device_match_gen.h | 195 --
src/amdgpu_probe.h| 29 -
src/ati_pciids_gen.h | 191 -
src/pcidb/ati_pciids.csv | 192 -
src/pcidb/parse_pci_ids.pl| 82 ---
9 files changed, 1301 deletions(-)
delete mode 100644 src/amdgpu_chipinfo_gen.h
delete mode 100644 src/amdgpu_chipset_gen.h
delete mode 100644 src/amdgpu_pci_chipset_gen.h
delete mode 100644 src/amdgpu_pci_device_match_gen.h
delete mode 100644 src/ati_pciids_gen.h
delete mode 100644 src/pcidb/ati_pciids.csv
delete mode 100755 src/pcidb/parse_pci_ids.pl
diff --git a/src/Makefile.am b/src/Makefile.am
index 8cc1362..7468bba 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -68,12 +68,5 @@ EXTRA_DIST = \
amdgpu_version.h \
amdgpu_video.h \
simple_list.h \
- ati_pciids_gen.h \
- amdgpu_chipinfo_gen.h \
- amdgpu_chipset_gen.h \
- amdgpu_pci_chipset_gen.h \
- amdgpu_pci_device_match_gen.h \
- pcidb/ati_pciids.csv \
- pcidb/parse_pci_ids.pl \
amdgpu_dri2.h \
drmmode_display.h
diff --git a/src/amdgpu_chipinfo_gen.h b/src/amdgpu_chipinfo_gen.h
deleted file mode 100644
index 90b13bb..000
--- a/src/amdgpu_chipinfo_gen.h
+++ /dev/null
@@ -1,194 +0,0 @@
-/* This file is autogenerated please do not edit */
-static AMDGPUCardInfo AMDGPUCards[] = {
- { 0x6600, CHIP_FAMILY_OLAND },
- { 0x6601, CHIP_FAMILY_OLAND },
- { 0x6602, CHIP_FAMILY_OLAND },
- { 0x6603, CHIP_FAMILY_OLAND },
- { 0x6604, CHIP_FAMILY_OLAND },
- { 0x6605, CHIP_FAMILY_OLAND },
- { 0x6606, CHIP_FAMILY_OLAND },
- { 0x6607, CHIP_FAMILY_OLAND },
- { 0x6608, CHIP_FAMILY_OLAND },
- { 0x6610, CHIP_FAMILY_OLAND },
- { 0x6611, CHIP_FAMILY_OLAND },
- { 0x6613, CHIP_FAMILY_OLAND },
- { 0x6617, CHIP_FAMILY_OLAND },
- { 0x6620, CHIP_FAMILY_OLAND },
- { 0x6621, CHIP_FAMILY_OLAND },
- { 0x6623, CHIP_FAMILY_OLAND },
- { 0x6631, CHIP_FAMILY_OLAND },
- { 0x6660, CHIP_FAMILY_HAINAN },
- { 0x6663, CHIP_FAMILY_HAINAN },
- { 0x6664, CHIP_FAMILY_HAINAN },
- { 0x6665, CHIP_FAMILY_HAINAN },
- { 0x6667, CHIP_FAMILY_HAINAN },
- { 0x666F, CHIP_FAMILY_HAINAN },
- { 0x6780, CHIP_FAMILY_TAHITI },
- { 0x6784, CHIP_FAMILY_TAHITI },
- { 0x6788, CHIP_FAMILY_TAHITI },
- { 0x678A, CHIP_FAMILY_TAHITI },
- { 0x6790, CHIP_FAMILY_TAHITI },
- { 0x6791, CHIP_FAMILY_TAHITI },
- { 0x6792, CHIP_FAMILY_TAHITI },
- { 0x6798, CHIP_FAMILY_TAHITI },
- { 0x6799, CHIP_FAMILY_TAHITI },
- { 0x679A, CHIP_FAMILY_TAHITI },
- { 0x679B, CHIP_FAMILY_TAHITI },
- { 0x679E, CHIP_FAMILY_TAHITI },
- { 0x679F, CHIP_FAMILY_TAHITI },
- { 0x6800, CHIP_FAMILY_PITCAIRN },
- { 0x6801, CHIP_FAMILY_PITCAIRN },
- { 0x6802, CHIP_FAMILY_PITCAIRN },
- { 0x6806, CHIP_FAMILY_PITCAIRN },
- { 0x6808, CHIP_FAMILY_PITCAIRN },
- { 0x6809, CHIP_FAMILY_PITCAIRN },
- { 0x6810, CHIP_FAMILY_PITCAIRN },
- { 0x6811, CHIP_FAMILY_PITCAIRN },
- { 0x6816, CHIP_FAMILY_PITCAIRN },
- { 0x6817, CHIP_FAMILY_PITCAIRN },
- { 0x6818, CHIP_FAMILY_PITCAIRN },
- { 0x6819, CHIP_FAMILY_PITCAIRN },
- { 0x6820, CHIP_FAMILY_VERDE },
- { 0x6821, CHIP_FAMILY_VERDE },
- { 0x6822, CHIP_FAMILY_VERDE },
- { 0x6823, CHIP_FAMILY_VERDE },
- { 0x6824, CHIP_FAMILY_VERDE },
- { 0x6825, CHIP_FAMILY_VERDE },
- { 0x6826, CHIP_FAMILY_VERDE },
- { 0x6827, CHIP_FAMILY_VERDE },
- { 0x6828, CHIP_FAMILY_VERDE },
- { 0x6829, CHIP_FAMILY_VERDE },
- { 0x682A, CHIP_FAMILY_VERDE },
- { 0x682B, CHIP_FAMILY_VERDE },
- { 0x682C, CHIP_FAMILY_VERDE },
- { 0x682D, CHIP_FAMILY_VERDE },
- { 0x682F, CHIP_FAMILY_VERDE },
- { 0x6830, CHIP_FAMILY_VERDE },
- { 0x6831, CHIP_FAMILY_VERDE },
- { 0x6835, CHIP_FAMILY_VERDE },
- { 0x6837, CHIP_FAMILY_VERDE },
- { 0x6838, CHIP_FAMILY_VERDE },
- { 0x6839, CHIP_FAMILY_VERDE },
- { 0x683B, CHIP_FAMILY_VERDE },
- { 0x683D, CHIP_FAMILY_VERDE },
- { 0x683F, CHIP_FAMILY_VERDE },
- { 0x684C, CHIP_FAMILY_PITCAIRN },
- { 0x6640, CHIP_FAMILY_BONAIRE },
- { 0x6641, CHIP_FAMILY_BONAIRE },
- { 0x6646, CHIP_FAMILY_BONAIRE },
- { 0x6647, CHIP_FAMILY_BONAIRE },
- { 0x6649, CHIP_FAMILY_BONAIRE },
- { 0x6650, CHIP_FAMILY_BONAIRE },
- { 0x6651, CHIP_FAMILY_BONAIRE },
- { 0x6658, CHIP_FAMILY_BONAIRE },
- { 0x665C, CHIP_FAMILY_BONAIRE },
- { 0x665D, CHIP_FAMILY_BONAIRE },
- { 0x665F, CHIP_FAMILY_BONAIRE },
- { 0x9830, CHIP_FAMILY_KABINI },
- { 0x9831, CHIP_FAMILY_KABINI },
- { 0x9832, CHIP_FAMILY_KABINI },
- { 0x9833, CHIP_FAMILY_KABINI },
- { 0x9834, CHIP_FAMILY_KABINI },
- { 0x9835, CHIP_FAMILY_KABINI },
- { 0x9836, CHIP_FAMILY_KABINI },
- { 0x9837, CHIP_F
[PATCH xf86-video-amdgpu 6/7] Stop using AMDGPU(Unique)Chipsets
From: Michel Dänzer <michel.daen...@amd.com>
Use libdrm_amdgpu's amdgpu_get_marketing_name for the chipset name, or
"Unknown AMD Radeon GPU" as a fallback.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/amdgpu_kms.c | 12
src/amdgpu_probe.c | 11 ++-
2 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/src/amdgpu_kms.c b/src/amdgpu_kms.c
index 890add5..1f5e6f0 100644
--- a/src/amdgpu_kms.c
+++ b/src/amdgpu_kms.c
@@ -58,7 +58,6 @@
static DevScreenPrivateKeyRec amdgpu_client_private_key;
-extern SymTabRec AMDGPUChipsets[];
static Bool amdgpu_setup_kernel_mem(ScreenPtr pScreen);
const OptionInfoRec AMDGPUOptions_KMS[] = {
@@ -1160,15 +1159,12 @@ static Bool AMDGPUPreInitChipType_KMS(ScrnInfoPtr pScrn,
struct amdgpu_gpu_info *gpu_info)
{
AMDGPUInfoPtr info = AMDGPUPTR(pScrn);
+ AMDGPUEntPtr pAMDGPUEnt = AMDGPUEntPriv(pScrn);
info->Chipset = info->PciInfo->device_id;
- pScrn->chipset =
- (char *)xf86TokenToString(AMDGPUChipsets, info->Chipset);
- if (!pScrn->chipset) {
- xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
- "ChipID 0x%04x is not recognized\n", info->Chipset);
- return FALSE;
- }
+ pScrn->chipset = amdgpu_get_marketing_name(pAMDGPUEnt->pDev);
+ if (!pScrn->chipset)
+ pScrn->chipset = "Unknown AMD Radeon GPU";
if (info->Chipset < 0) {
xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
diff --git a/src/amdgpu_probe.c b/src/amdgpu_probe.c
index acc0433..301e586 100644
--- a/src/amdgpu_probe.c
+++ b/src/amdgpu_probe.c
@@ -58,9 +58,6 @@
#include
#endif
-#include "ati_pciids_gen.h"
-#include "amdgpu_chipset_gen.h"
-
_X_EXPORT int gAMDGPUEntityIndex = -1;
/* Return the options for supported chipset 'n'; NULL otherwise */
@@ -69,11 +66,15 @@ static const OptionInfoRec *AMDGPUAvailableOptions(int
chipid, int busid)
return AMDGPUOptionsWeak();
}
+static SymTabRec AMDGPUAny[] = {
+ { 0, "All GPUs supported by the amdgpu kernel driver" },
+ { -1, NULL }
+};
+
/* Return the string name for supported chipset 'n'; NULL otherwise. */
static void AMDGPUIdentify(int flags)
{
- xf86PrintChipsets(AMDGPU_NAME,
- "Driver for AMD Radeon chipsets",
AMDGPUUniqueChipsets);
+ xf86PrintChipsets(AMDGPU_NAME, "Driver for AMD Radeon", AMDGPUAny);
}
static char *amdgpu_bus_id(ScrnInfoPtr pScrn, struct pci_device *dev)
--
2.10.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH xf86-video-amdgpu 4/7] Remove amdpciids.h
From: Michel Dänzer <michel.daen...@amd.com>
Not useful anymore.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/Makefile.am | 1 -
src/amdgpu_drv.h | 3 +--
src/amdgpu_kms.c | 4 +---
src/amdpciids.h | 39 ---
4 files changed, 2 insertions(+), 45 deletions(-)
delete mode 100644 src/amdpciids.h
diff --git a/src/Makefile.am b/src/Makefile.am
index a851b3b..8cc1362 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -68,7 +68,6 @@ EXTRA_DIST = \
amdgpu_version.h \
amdgpu_video.h \
simple_list.h \
- amdpciids.h \
ati_pciids_gen.h \
amdgpu_chipinfo_gen.h \
amdgpu_chipset_gen.h \
diff --git a/src/amdgpu_drv.h b/src/amdgpu_drv.h
index 62aa1c1..36cf26a 100644
--- a/src/amdgpu_drv.h
+++ b/src/amdgpu_drv.h
@@ -86,7 +86,6 @@
#include "compat-api.h"
#include "simple_list.h"
-#include "amdpciids.h"
struct _SyncFence;
@@ -191,7 +190,7 @@ struct amdgpu_client_priv {
typedef struct {
EntityInfoPtr pEnt;
- pciVideoPtr PciInfo;
+ struct pci_device *PciInfo;
int Chipset;
uint32_t family;
struct gbm_device *gbm;
diff --git a/src/amdgpu_kms.c b/src/amdgpu_kms.c
index 68570e4..890add5 100644
--- a/src/amdgpu_kms.c
+++ b/src/amdgpu_kms.c
@@ -41,8 +41,6 @@
#include "shadow.h"
#include
-#include "amdpciids.h"
-
/* DPMS */
#ifdef HAVE_XEXTPROTO_71
#include
@@ -1163,7 +1161,7 @@ static Bool AMDGPUPreInitChipType_KMS(ScrnInfoPtr pScrn,
{
AMDGPUInfoPtr info = AMDGPUPTR(pScrn);
- info->Chipset = PCI_DEV_DEVICE_ID(info->PciInfo);
+ info->Chipset = info->PciInfo->device_id;
pScrn->chipset =
(char *)xf86TokenToString(AMDGPUChipsets, info->Chipset);
if (!pScrn->chipset) {
diff --git a/src/amdpciids.h b/src/amdpciids.h
deleted file mode 100644
index 33ec6da..000
--- a/src/amdpciids.h
+++ /dev/null
@@ -1,39 +0,0 @@
-/*
- * Copyright 2014 Advanced Micro Devices, Inc.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
- *
-*/
-
-
-#ifndef _AMDPCIIDS_H
-#define _AMDPCIIDS_H
-
-#define PCI_VENDOR_ATI 0x1002
-
-#include "ati_pciids_gen.h"
-
-typedef struct pci_device *pciVideoPtr;
-
-#define PCI_DEV_DEVICE_ID(_pcidev) ((_pcidev)->device_id)
-
-#define ATI_DEVICE_MATCH(d, i) \
-{ PCI_VENDOR_ATI, (d), PCI_MATCH_ANY, PCI_MATCH_ANY, 0, 0, (i) }
-
-#endif /* AMDPCIIDS_H */
--
2.10.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH xf86-video-amdgpu 5/7] Stop using AMDGPUPciChipsets
From: Michel Dänzer <michel.daen...@amd.com> Not actually used by Xorg. Signed-off-by: Michel Dänzer <michel.daen...@amd.com> --- src/amdgpu_probe.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/amdgpu_probe.c b/src/amdgpu_probe.c index fb6f8a3..acc0433 100644 --- a/src/amdgpu_probe.c +++ b/src/amdgpu_probe.c @@ -61,8 +61,6 @@ #include "ati_pciids_gen.h" #include "amdgpu_chipset_gen.h" -#include "amdgpu_pci_chipset_gen.h" - _X_EXPORT int gAMDGPUEntityIndex = -1; /* Return the options for supported chipset 'n'; NULL otherwise */ @@ -177,7 +175,7 @@ static Bool amdgpu_get_scrninfo(int entity_num, struct pci_device *pci_dev) DevUnion *pPriv; AMDGPUEntPtr pAMDGPUEnt; - pScrn = xf86ConfigPciEntity(pScrn, 0, entity_num, AMDGPUPciChipsets, + pScrn = xf86ConfigPciEntity(pScrn, 0, entity_num, NULL, NULL, NULL, NULL, NULL, NULL); if (!pScrn) -- 2.10.2 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH xf86-video-amdgpu 0/7] Remove generated header files
From: Michel Dänzer <michel.daen...@amd.com> This series removes the reliance on information in generated header files, and removes the generated header files. The main motivation for this is to remove the need to add PCI ID entries for each supported GPU. Patch 6 relies on amdgpu_get_marketing_name from https://patchwork.freedesktop.org/patch/110050/ , it will be updated to require the libdrm release containing that before pushing. The series won't be pushed before the upcoming 1.2.0 release anyway. Michel Dänzer (7): Move struct amdgpu_gpu_info out of amdgpu_get_tile_config Use family information from libdrm_amdgpu / kernel Stop using generated amdgpu_device_match Remove amdpciids.h Stop using AMDGPUPciChipsets Stop using AMDGPU(Unique)Chipsets Remove generated header files src/Makefile.am | 8 -- src/amdgpu_chipinfo_gen.h | 194 -- src/amdgpu_chipset_gen.h | 216 -- src/amdgpu_drv.h | 5 +- src/amdgpu_kms.c | 52 - src/amdgpu_pci_chipset_gen.h | 195 -- src/amdgpu_pci_device_match_gen.h | 195 -- src/amdgpu_probe.c| 22 ++-- src/amdgpu_probe.h| 29 - src/amdpciids.h | 39 --- src/ati_pciids_gen.h | 191 - src/pcidb/ati_pciids.csv | 192 - src/pcidb/parse_pci_ids.pl| 82 --- 13 files changed, 32 insertions(+), 1388 deletions(-) delete mode 100644 src/amdgpu_chipinfo_gen.h delete mode 100644 src/amdgpu_chipset_gen.h delete mode 100644 src/amdgpu_pci_chipset_gen.h delete mode 100644 src/amdgpu_pci_device_match_gen.h delete mode 100644 src/amdpciids.h delete mode 100644 src/ati_pciids_gen.h delete mode 100644 src/pcidb/ati_pciids.csv delete mode 100755 src/pcidb/parse_pci_ids.pl -- 2.10.2 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH xf86-video-amdgpu 2/4] Always call PixmapStopDirtyTracking in drmmode_set_scanout_pixmap
From: Michel Dänzer <michel.daen...@amd.com>
Otherwise, we may leak screen->pixmap_dirty_list entries if
drmmode_set_scanout_pixmap is called repatedly with ppix != NULL, which
can happen from RRReplaceScanoutPixmap.
(Inspired by xserver commit b773a9c8126222e5fed2904d012fbf917a9f22fd)
(Ported from radeon commit 6c940446ddadf418ee4959e46fa552b6c1cf6704)
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/drmmode_display.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 5f0fdb0..9dfef40 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -1103,23 +1103,21 @@ static Bool drmmode_set_scanout_pixmap(xf86CrtcPtr
crtc, PixmapPtr ppix)
{
drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
AMDGPUInfoPtr info = AMDGPUPTR(crtc->scrn);
+ ScreenPtr screen = crtc->scrn->pScreen;
+ PixmapDirtyUpdatePtr dirty;
- if (!ppix) {
- ScreenPtr screen = crtc->scrn->pScreen;
- PixmapDirtyUpdatePtr dirty;
-
- xorg_list_for_each_entry(dirty, >pixmap_dirty_list,
ent) {
- if (dirty->slave_dst !=
-
drmmode_crtc->scanout[drmmode_crtc->scanout_id].pixmap)
- continue;
+ xorg_list_for_each_entry(dirty, >pixmap_dirty_list, ent) {
+ if (dirty->slave_dst !=
+ drmmode_crtc->scanout[drmmode_crtc->scanout_id].pixmap)
+ continue;
- PixmapStopDirtyTracking(dirty->src, dirty->slave_dst);
- drmmode_crtc_scanout_free(drmmode_crtc);
- break;
- }
+ PixmapStopDirtyTracking(dirty->src, dirty->slave_dst);
+ drmmode_crtc_scanout_free(drmmode_crtc);
+ break;
+ }
+ if (!ppix)
return TRUE;
- }
if (!drmmode_crtc_scanout_create(crtc, _crtc->scanout[0],
ppix->drawable.width,
--
2.10.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH xf86-video-amdgpu 1/4] Don't rely on randr_crtc->scanout_pixmap in drmmode_set_scanout_pixmap
From: Michel Dänzer <michel.daen...@amd.com>
RRReplaceScanoutPixmap may set randr_crtc->scanout_pixmap = NULL before
we get here.
(Inspired by xserver commit f4c377953df1fe0e3196eda452acf0078e61)
v2: Always return TRUE in the if (!ppix) block.
(Cherry picked from radeon commit 61df12e2377cbb19a19ca9d5624df8959822da9f)
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/drmmode_display.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index f291f6d..5f0fdb0 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -1105,10 +1105,19 @@ static Bool drmmode_set_scanout_pixmap(xf86CrtcPtr
crtc, PixmapPtr ppix)
AMDGPUInfoPtr info = AMDGPUPTR(crtc->scrn);
if (!ppix) {
- if (crtc->randr_crtc->scanout_pixmap)
-
PixmapStopDirtyTracking(crtc->randr_crtc->scanout_pixmap,
-
drmmode_crtc->scanout[drmmode_crtc->scanout_id].pixmap);
- drmmode_crtc_scanout_free(drmmode_crtc);
+ ScreenPtr screen = crtc->scrn->pScreen;
+ PixmapDirtyUpdatePtr dirty;
+
+ xorg_list_for_each_entry(dirty, >pixmap_dirty_list,
ent) {
+ if (dirty->slave_dst !=
+
drmmode_crtc->scanout[drmmode_crtc->scanout_id].pixmap)
+ continue;
+
+ PixmapStopDirtyTracking(dirty->src, dirty->slave_dst);
+ drmmode_crtc_scanout_free(drmmode_crtc);
+ break;
+ }
+
return TRUE;
}
--
2.10.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH xf86-video-amdgpu 3/4] PRIME: Fix swapping of provider sink / source capabilities
From: Hans de Goede <hdego...@redhat.com>
When a card has import capability it can be an offload _sink_, not a
source and vice versa for export capability.
This went unnoticed sofar because most gpus have both import and export
capability.
Signed-off-by: Hans de Goede <hdego...@redhat.com>
(Ported from xserver commit 94a1c77259ce39ba59ad87615df39b570ffab435)
(Ported from radeon commit 82d3c8f5500d2a6fb1495e217a0b79c396f1534c)
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/amdgpu_kms.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/amdgpu_kms.c b/src/amdgpu_kms.c
index 4ae7995..6fa63e9 100644
--- a/src/amdgpu_kms.c
+++ b/src/amdgpu_kms.c
@@ -1235,9 +1235,9 @@ static void AMDGPUSetupCapabilities(ScrnInfoPtr pScrn)
ret = drmGetCap(pAMDGPUEnt->fd, DRM_CAP_PRIME, );
if (ret == 0) {
if (value & DRM_PRIME_CAP_EXPORT)
- pScrn->capabilities |= RR_Capability_SourceOutput |
RR_Capability_SinkOffload;
+ pScrn->capabilities |= RR_Capability_SourceOutput |
RR_Capability_SourceOffload;
if (value & DRM_PRIME_CAP_IMPORT) {
- pScrn->capabilities |= RR_Capability_SourceOffload;
+ pScrn->capabilities |= RR_Capability_SinkOffload;
if (info->drmmode.count_crtcs)
pScrn->capabilities |= RR_Capability_SinkOutput;
}
--
2.10.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.
On 29/10/16 10:58 PM, Mike Lothian wrote: > I turned on vsync and everything works great in tomb raider > > :D > > Thanks again to everyone who made this possible > > On Fri, 28 Oct 2016 at 19:37 Mike Lothian <m...@fireburn.co.uk > <mailto:m...@fireburn.co.uk>> wrote: > > Hi Mario > > That fixes the tearing, it's been replaced with a strange stutter, > like it's only showing half the number of frames being reported - > it's really noticeable in tomb raider I wonder if the stutter might be due to the dGPU writing another frame before the iGPU is done processing the previous one. Christian, does the amdgpu scheduler wait for shared fences of shared BOs to signal before submitting jobs using them to the GPU? -- Earthling Michel Dänzer | http://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: [PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.
On 29/10/16 02:37 AM, Mario Kleiner wrote:
> On 10/28/2016 03:34 AM, Michel Dänzer wrote:
>> On 27/10/16 10:33 PM, Mike Lothian wrote:
>>>
>>> Just another gentle ping to see where you are with this?
>>
>> I haven't got a chance to look into this any further.
>
> Fwiw., as a proof of concept, the attached experimental patch does work
> as tested on Intel HD Haswell + AMD R9 380 Tonga under amdgpu and
> DRI3/Present when applied to drm-next (updated from a few days ago).
> With DRI_PRIME=1 tearing for page-flipped fullscreen windows is gone
> under all loads. The tearing with "windowed" windows now looks as
> expected for regular tearing not related to Prime.
>
> ftrace confirms the i915 driver's pageflip function is waiting on the
> fence in reservation_object_wait_timeout_rcu() as it should.
>
> That entry->tv.shared needs to be set false for such buffers in
> amdgpu_bo_list_set() makes sense to me, as that is part of the buffer
> validation for command stream submission. There are other places in the
> driver where tv.shared is set, which i didn't check so far.
>
> I don't know which of these would need to be updated with a "exported
> bo" check as well, e.g., for video decoding or maybe gpu compute? Adding
> or removing the check to amdgpu_gem_va_update_vm(), e.g., made no
> difference. I assume that makes sense because that functions seems to
> deal with amdgpu internal vm page tables or page table entries for such
> a bo, not with something visible to external clients?
>
> All i can say is it fixes 3D rendering under DRI3 + Prime + pageflipping
> without causing any obvious new problems.
[...]
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> index 7700dc2..bfbfeb9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> @@ -121,5 +121,8 @@ struct dma_buf *amdgpu_gem_prime_export(struct drm_device
> *dev,
> if (amdgpu_ttm_tt_get_usermm(bo->tbo.ttm))
> return ERR_PTR(-EPERM);
>
> + bo->prime_exported = true;
> + DRM_DEBUG_PRIME("Exporting prime bo %p\n", bo);
> +
> return drm_gem_prime_export(dev, gobj, flags);
> }
>
This will take effect in non-PRIME cases as well, at least DRI3 and
GL<->[other API] interop off the top of my head. Is that okay?
--
Earthling Michel Dänzer | http://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: [PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.
On 31/10/16 05:00 PM, Christian König wrote: > Am 31.10.2016 um 07:44 schrieb Michel Dänzer: >> On 29/10/16 10:58 PM, Mike Lothian wrote: >>> I turned on vsync and everything works great in tomb raider >>> >>> :D >>> >>> Thanks again to everyone who made this possible >>> >>> On Fri, 28 Oct 2016 at 19:37 Mike Lothian <m...@fireburn.co.uk >>> <mailto:m...@fireburn.co.uk>> wrote: >>> >>> Hi Mario >>> >>> That fixes the tearing, it's been replaced with a strange stutter, >>> like it's only showing half the number of frames being reported - >>> it's really noticeable in tomb raider >> I wonder if the stutter might be due to the dGPU writing another frame >> before the iGPU is done processing the previous one. Christian, does the >> amdgpu scheduler wait for shared fences of shared BOs to signal before >> submitting jobs using them to the GPU? > > Yeah, that should work. We wait for both the exclusive as well as all > shared fences before CS or pageflip. > > Only on CS we filter the shared fences so that we don't necessary wait > for submissions from the same process. Note that it can be the same process (Xorg) in the RandR 1.4 multihead case. But it sounds like Mike's stutter can't be due to the issue I was thinking of. -- Earthling Michel Dänzer | http://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
Fwd: [PATCH libdrm] xf86drm: Parse the separate files to retrieve the vendor/device info
The first attached patch will result in drmParsePciDeviceInfo always
reporting revision 0 on kernels without the second attached patch. Will
that be an issue for the amdgpu-pro stack?
Please follow up directly to the patch e-mails with any comments on the
patches.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
--- Begin Message ---
From: Emil Velikov <emil.veli...@collabora.com>
Currently the revision isn't available via sysfs/libudev thus if one
wants to know the value they need to read through the config file.
This in itself wakes/powers up the device, causing unwanted delay
since it can be quite costly.
Expose the revision as a separate file, just like we do for the device,
vendor, their subsystem version and class.
Cc: Jammy Zhou <jammy.z...@amd.com>
Cc: Michel Dänzer <michel.daen...@amd.com>
Cc: Bjorn Helgaas <bhelg...@google.com>
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Emil Velikov <emil.veli...@collabora.com>
---
Gents, I'm not subscribed to the mailing list so please keep me in the
CC chain.
Thanks
Emil
---
drivers/pci/pci-sysfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index bcd10c7..0666287 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -50,6 +50,7 @@ pci_config_attr(vendor, "0x%04x\n");
pci_config_attr(device, "0x%04x\n");
pci_config_attr(subsystem_vendor, "0x%04x\n");
pci_config_attr(subsystem_device, "0x%04x\n");
+pci_config_attr(revision, "0x%02x\n");
pci_config_attr(class, "0x%06x\n");
pci_config_attr(irq, "%u\n");
@@ -568,6 +569,7 @@ static struct attribute *pci_dev_attrs[] = {
_attr_device.attr,
_attr_subsystem_vendor.attr,
_attr_subsystem_device.attr,
+ _attr_revision.attr,
_attr_class.attr,
_attr_irq.attr,
_attr_local_cpus.attr,
--
2.9.3
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
--- End Message ---
--- Begin Message ---
From: Emil Velikov <emil.veli...@collabora.com>
Parsing config sysfs file wakes up the device. The latter of which may
be slow and isn't required to begin with.
Reading through config is/was required since the revision is not
available by other means, although with a kernel patch in the way we can
'cheat' temporarily.
That should be fine, since no open-source project has ever used the
value.
Cc: Michel Dänzer <michel.daen...@amd.com>
Cc: Mauro Santos <registo.maill...@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98502
Signed-off-by: Emil Velikov <emil.veli...@collabora.com>
---
Mauro can you apply this against libdrm and rebuild it. You do _not_
need to rebuild mesa afterwords.
Thanks
---
xf86drm.c | 50 +++---
1 file changed, 35 insertions(+), 15 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 52add5e..5a5100c 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2950,25 +2950,45 @@ static int drmParsePciDeviceInfo(const char *d_name,
drmPciDeviceInfoPtr device)
{
#ifdef __linux__
+#define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
+static const char *attrs[] = {
+ "revision", /* XXX: make sure it's always first, see note below */
+ "vendor",
+ "device",
+ "subsystem_vendor",
+ "subsystem_device",
+};
char path[PATH_MAX + 1];
-unsigned char config[64];
-int fd, ret;
+unsigned int data[ARRAY_SIZE(attrs)];
+FILE *fp;
+int ret;
-snprintf(path, PATH_MAX, "/sys/class/drm/%s/device/config", d_name);
-fd = open(path, O_RDONLY);
-if (fd < 0)
-return -errno;
+for (unsigned i = 0; i < ARRAY_SIZE(attrs); i++) {
+snprintf(path, PATH_MAX, "/sys/class/drm/%s/device/%s",
+ d_name, attrs[i]);
+fp = fopen(path, "r");
+if (!fp) {
+/* Note: First we check the revision, since older kernels
+ * may not have it. Default to zero in such cases. */
+if (i == 0) {
+data[i] = 0;
+continue;
+}
+return -errno;
+}
-ret = read(fd, config, sizeof(config));
-close(fd);
-if (ret < 0)
-return -errno;
+ret = fscanf(fp, "%x", [i]);
+fclose(fp);
+if (ret != 1)
+return -errno;
+
+}
-device->vendor_id = config[0] | (config[1] << 8);
-device->device_id = config[2] | (config[3] << 8);
-device->revision_id = config[8];
-device->subvendor_id = config[4
[PATCH xf86-video-amdgpu] Check Xorg version at runtime instead of build time in two places
From: Michel Dänzer <michel.daen...@amd.com>
This means that all possible paths can be handled as intended, no matter
which Xorg version the driver happened to be compiled against.
(Ported from radeon commit 350a2645a1b127227ff294c0b62d2d0fd48a)
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
man/amdgpu.man| 2 +-
src/amdgpu_kms.c | 6 +-
src/drmmode_display.c | 8
3 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/man/amdgpu.man b/man/amdgpu.man
index 93244a4..948cd70 100644
--- a/man/amdgpu.man
+++ b/man/amdgpu.man
@@ -65,7 +65,7 @@ will assign xrandr outputs LVDS and VGA-0 to this instance of
the driver.
Define the maximum level of DRI to enable. Valid values are 2 for DRI2 or 3
for DRI3.
The default is
.B 3 for DRI3
-if the driver was compiled for Xorg >= 1.18.3, otherwise
+if the Xorg version is >= 1.18.3, otherwise
.B 2 for DRI2.
.TP
.BI "Option \*qEnablePageFlip\*q \*q" boolean \*q
diff --git a/src/amdgpu_kms.c b/src/amdgpu_kms.c
index acf3a7d..b21cd37 100644
--- a/src/amdgpu_kms.c
+++ b/src/amdgpu_kms.c
@@ -1713,11 +1713,7 @@ Bool AMDGPUScreenInit_KMS(SCREEN_INIT_ARGS_DECL)
}
#endif
-#if XORG_VERSION_CURRENT >= XORG_VERSION_NUMERIC(1,18,3,0,0)
- value = TRUE;
-#else
- value = FALSE;
-#endif
+ value = xorgGetVersion() >= XORG_VERSION_NUMERIC(1,18,3,0,0);
from = X_DEFAULT;
if (info->use_glamor) {
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index f514866..2d36881 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -607,10 +607,10 @@ drmmode_can_use_hw_cursor(xf86CrtcPtr crtc)
return FALSE;
#endif
-#if defined(AMDGPU_PIXMAP_SHARING) && \
- XORG_VERSION_CURRENT <= XORG_VERSION_NUMERIC(1,18,99,901,0)
- /* HW cursor not supported with RandR 1.4 multihead */
- if (!xorg_list_is_empty(>scrn->pScreen->pixmap_dirty_list))
+#if defined(AMDGPU_PIXMAP_SHARING)
+ /* HW cursor not supported with RandR 1.4 multihead up to 1.18.99.901 */
+ if (xorgGetVersion() <= XORG_VERSION_NUMERIC(1,18,99,901,0) &&
+ !xorg_list_is_empty(>scrn->pScreen->pixmap_dirty_list))
return FALSE;
#endif
--
2.10.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [1/4] amdgpu: add the function to get the marketing name (v2)
On 01/11/16 06:34 PM, Michel Dänzer wrote:
> On 13/09/16 12:14 AM, Alex Deucher wrote:
>> From: Junwei Zhang <jerry.zh...@amd.com>
>>
>> This function is used to look up the marking name
>> for a specific board.
>>
>> v2: agd: Squash in subsequent updates to the table.
>
> As is, this breaks make check:
>
>
>> +struct amdgpu_asic_id_table_t {
>
> Make this static, so the amdgpu_asic_id_table_t symbol doesn't get
> exported from libdrm_amdgpu.
>
> BTW, is there any particular reason for putting this table in a separate
> header file?
>
>
>> @@ -303,3 +304,17 @@ int amdgpu_device_deinitialize(amdgpu_device_handle dev)
>> amdgpu_device_reference(, NULL);
>> return 0;
>> }
>> +
>> +const char *amdgpu_get_marketing_name(amdgpu_device_handle dev)
>
> amdgpu_get_marketing_name needs to be added to amdgpu-symbols-check.
>
>
>> +if ((t->did == dev->info.asic_id) &&
>> + (t->rid == dev->info.pci_rev_id))
>
> Wrong indentation of the second line.
>
>
> With these issues fixed,
>
> Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
>
> Would be nice to land this in master soon, as we're going to use it in
> xf86-video-amdgpu: https://patchwork.freedesktop.org/patch/119501/
Junwei, if it's okay with you, I can amend the patch and push it to master.
--
Earthling Michel Dänzer | http://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: [PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.
On 11/10/16 09:04 PM, Christian König wrote: > Am 11.10.2016 um 05:58 schrieb Michel Dänzer: >> On 07/10/16 09:34 PM, Mike Lothian wrote: >>> This has discussion has gone a little quiet >>> >>> Was there any agreement about what needed doing to get this working >>> for i965/amdgpu? >> Christian, do you see anything which could prevent the solution I >> outlined from working? > > I thought about that approach as well, but unfortunately it also has a > couple of downsides. Especially keeping the exclusive fence set while we > actually don't need it isn't really clean either. I was wondering if it's possible to have a singleton pseudo exclusive fence which is used for all BOs. That might keep the overhead acceptably low. > I'm currently a bit busy with other tasks and so put Nayan on a road to > get a bit into the kernel driver (he asked for that anyway). > > Implementing the simple workaround to sync when we export the DMA-buf > should be something like 20 lines of code and fortunately Nayan has an > I+A system and so can actually test it. > > If it turns out to be more problematic or somebody really starts to need > it I'm going to hack on that myself a bit more. If you mean only syncing when a DMA-buf is exported, that's not enough, as I explained before. The BOs being shared are long-lived, and synchronization between GPUs is required for every command stream submission. -- Earthling Michel Dänzer | http://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: [PATCH] drm/amd/amdgpu: Allow broadcast on debugfs read (v2)
On 11/10/16 09:32 PM, StDenis, Tom wrote: > It's used by the UMD though they read from 0/*/* when reading the > RASTER_CONFIG registers (which may be a bug...) We should probably clarify what userspace is trying to do there, and whether the hardware actually does that. -- Earthling Michel Dänzer | http://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: mm: fix cache mode tracking in vm_insert_mixed() breaks AMDGPU [was: Re: Latest testing with drm-next-4.9-wip and latest LLVM/mesa stack - Regression in PowerPlay/DPM on CIK?]
[ Adding Dan Williams and dri-devel ] On 14/10/16 03:28 AM, Shawn Starr wrote: > Hello AMD folks, > > I have discovered a problem in Linus master that affects AMDGPU, nobody would > notice this in drm-next-4.9-wip since its not in this repo. [...] > 87744ab3832b83ba71b931f86f9cfdb000d07da5 is the first bad commit > commit 87744ab3832b83ba71b931f86f9cfdb000d07da5 > Author: Dan Williams <dan.j.willi...@intel.com> > Date: Fri Oct 7 17:00:18 2016 -0700 > > mm: fix cache mode tracking in vm_insert_mixed() > > vm_insert_mixed() unlike vm_insert_pfn_prot() and vmf_insert_pfn_pmd(), > fails to check the pgprot_t it uses for the mapping against the one > recorded in the memtype tracking tree. Add the missing call to > track_pfn_insert() to preclude cases where incompatible aliased mappings > are established for a given physical address range. > > Link: http://lkml.kernel.org/r/ > 147328717909.35069.14256589123570653697.stgit@dwillia2- > desk3.amr.corp.intel.com > Signed-off-by: Dan Williams <dan.j.willi...@intel.com> > Cc: David Airlie <airl...@linux.ie> > Cc: Matthew Wilcox <mawil...@microsoft.com> > Cc: Ross Zwisler <ross.zwis...@linux.intel.com> > Signed-off-by: Andrew Morton <a...@linux-foundation.org> > Signed-off-by: Linus Torvalds <torva...@linux-foundation.org> > > :04 04 7517c0019fe49c1830b5a1d81f1dc099c5aab98a > fd497a604a2af5995db2b8ed1e9c640bede6adf3 M mm > > > Removal of this patch stops graphics stalls. Thanks for bisecting this Shawn. > A friend of mine mentions, > > "looks like a graphics thingy you depend on is requesting a mapping with a > not-allowed cache mode, and now you are (rightfully) getting errors?" It would be nice to get some more specific pointers what amdgpu (or maybe ttm, since that calls vm_insert_mixed in ttm_bo_vm_fault) might be doing wrong. -- Earthling Michel Dänzer | http://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: [PATCH] drm/amd/amdgpu: Allow broadcast on debugfs read (v2)
On 13/10/16 12:39 AM, StDenis, Tom wrote:
> It comes from amdgpu_query_gpu_info_init()
>
>
> for (i = 0; i < (int)dev->info.num_shader_engines; i++) {
> unsigned instance = (i << AMDGPU_INFO_MMR_SE_INDEX_SHIFT) |
> (*AMDGPU_INFO_MMR_SH_INDEX_MASK*<<
> AMDGPU_INFO_MMR_SH_INDEX_SHIFT);
>
> r = amdgpu_read_mm_registers(dev, 0x263d, 1, instance, 0,
> >info.backend_disable[i]);
>
> This effectively reads from 0/* where the kernel adds the instance of *
> so it's 0/*/*. That line was last changed by Alex
>
> *0936139536380* (Alex Deucher 2015-04-20 12:04:22 -0400 174)
> (AMDGPU_INFO_MMR_SH_INDEX_MASK <<
As a side note, following that to the end in the kernel code, I noticed
an interesting minor difference between the AMDGPU_INFO_READ_MMR_REG
functionality used by this code and the debugfs interface:
With AMDGPU_INFO_READ_MMR_REG, the effect is that
amdgpu_asic_read_register() doesn't call amdgpu_gfx_select_se_sh() at
all before reading the register, so the read is performed from whichever
SH instance is currently selected.
Whereas with this patch, amdgpu_debugfs_regs_read() calls
amdgpu_gfx_select_se_sh(adev, se_bank, 0x, instance_bank) before
the register read, which translates to only the SH_BROADCAST_WRITES bit
being set for the SH instance index.
The end result should be the same though, since
amdgpu_gfx_select_se_sh(adev, 0x, 0x, 0x) is
normally called after every register read.
> I still don't get why this is a reason to hit pause on the patch(es)
> though.
At the very least, it should be documented in an appropriate place
(commit log and/or code, or any other place where the debugfs interface
semantics are documented) what actually happens when passing all ones
for the SE/SH index. Does the hardware ignore the *_BROADCAST_WRITES bit
for reads, so they're performed from instance 0, or does it combine the
values from all instances with logical and/or?
--
Earthling Michel Dänzer | http://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: [PATCH 1/2] drm/radeon: fix up dp aux tear down
On 12/10/16 01:26 AM, Alex Deucher wrote: > Port the amdgpu fixes from Grazvydas to radeon. > > bug: > https://bugs.freedesktop.org/show_bug.cgi?id=98200 > > Signed-off-by: Alex Deucher <alexander.deuc...@amd.com> [...] > @@ -938,6 +948,7 @@ static void radeon_connector_destroy(struct drm_connector > *connector) > kfree(connector); > } > > + > static int radeon_lvds_set_property(struct drm_connector *connector, > struct drm_property *property, > uint64_t value) I'd drop this hunk. Either way though, the series is Reviewed-and-Tested-by: Michel Dänzer <michel.daen...@amd.com> -- Earthling Michel Dänzer | http://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
[PATCH xf86-video-amdgpu] Enable HW cursor support with PRIME slave output & Xorg > 1.18.99.901
From: Michel Dänzer <michel.daen...@amd.com> Supported since Xorg 1.18.99.2, but buggy until 1.18.99.901. Signed-off-by: Michel Dänzer <michel.daen...@amd.com> --- src/drmmode_display.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/drmmode_display.c b/src/drmmode_display.c index fb41975..f291f6d 100644 --- a/src/drmmode_display.c +++ b/src/drmmode_display.c @@ -611,8 +611,9 @@ drmmode_can_use_hw_cursor(xf86CrtcPtr crtc) return FALSE; #endif -#ifdef AMDGPU_PIXMAP_SHARING - /* HW cursor not supported yet with RandR 1.4 multihead */ +#if defined(AMDGPU_PIXMAP_SHARING) && \ + XORG_VERSION_CURRENT <= XORG_VERSION_NUMERIC(1,18,99,901,0) + /* HW cursor not supported with RandR 1.4 multihead */ if (!xorg_list_is_empty(>scrn->pScreen->pixmap_dirty_list)) return FALSE; #endif -- 2.9.3 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH xf86-video-ati 2/4] Fix radeon_scanout_extents_intersect for GPU screens
From: Michel Dänzer <michel.daen...@amd.com>
Fixes incorrect screen updates with TearFree enabled on PRIME slave
outputs which are not located at (0, 0).
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/radeon_kms.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/src/radeon_kms.c b/src/radeon_kms.c
index 090ea3f..8bb261e 100644
--- a/src/radeon_kms.c
+++ b/src/radeon_kms.c
@@ -383,11 +383,21 @@ static Bool RADEONCreateScreenResources_KMS(ScreenPtr
pScreen)
static Bool
radeon_scanout_extents_intersect(xf86CrtcPtr xf86_crtc, BoxPtr extents)
{
-extents->x1 -= xf86_crtc->filter_width >> 1;
-extents->x2 += xf86_crtc->filter_width >> 1;
-extents->y1 -= xf86_crtc->filter_height >> 1;
-extents->y2 += xf86_crtc->filter_height >> 1;
-pixman_f_transform_bounds(_crtc->f_framebuffer_to_crtc, extents);
+#ifdef RADEON_PIXMAP_SHARING
+if (xf86_crtc->scrn->is_gpu) {
+ extents->x1 -= xf86_crtc->x;
+ extents->y1 -= xf86_crtc->y;
+ extents->x2 -= xf86_crtc->x;
+ extents->y2 -= xf86_crtc->y;
+} else
+#endif
+{
+ extents->x1 -= xf86_crtc->filter_width >> 1;
+ extents->x2 += xf86_crtc->filter_width >> 1;
+ extents->y1 -= xf86_crtc->filter_height >> 1;
+ extents->y2 += xf86_crtc->filter_height >> 1;
+ pixman_f_transform_bounds(_crtc->f_framebuffer_to_crtc, extents);
+}
extents->x1 = max(extents->x1, 0);
extents->y1 = max(extents->y1, 0);
--
2.10.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH xf86-video-ati 1/4] Take current scanout_id into account everywhere involved with TearFree
From: Michel Dänzer <michel.daen...@amd.com>
Fixes various potential issues with TearFree enabled, e.g. outputs
freezing after display configuration changes.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/drmmode_display.c | 22 +++---
src/radeon.h | 3 +--
src/radeon_kms.c | 6 +++---
3 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 95e3acd..e02a6f5 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -722,6 +722,7 @@ drmmode_set_mode_major(xf86CrtcPtr crtc, DisplayModePtr
mode,
RADEONInfoPtr info = RADEONPTR(pScrn);
xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(crtc->scrn);
drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
+ unsigned scanout_id = drmmode_crtc->scanout_id ^ info->tear_free;
drmmode_ptr drmmode = drmmode_crtc->drmmode;
int saved_x, saved_y;
Rotation saved_rotation;
@@ -771,7 +772,7 @@ drmmode_set_mode_major(xf86CrtcPtr crtc, DisplayModePtr
mode,
fb_id = drmmode->fb_id;
#ifdef RADEON_PIXMAP_SHARING
if (crtc->randr_crtc && crtc->randr_crtc->scanout_pixmap) {
- fb_id = drmmode_crtc->scanout[0].fb_id;
+ fb_id = drmmode_crtc->scanout[scanout_id].fb_id;
x = y = 0;
} else
#endif
@@ -815,12 +816,11 @@ drmmode_set_mode_major(xf86CrtcPtr crtc, DisplayModePtr
mode,
pBox->x2 = max(pBox->x2, pScrn->virtualX);
pBox->y2 = max(pBox->y2, pScrn->virtualY);
- drmmode_crtc->scanout_id = 0;
- fb_id = drmmode_crtc->scanout[0].fb_id;
+ fb_id = drmmode_crtc->scanout[scanout_id].fb_id;
x = y = 0;
- radeon_scanout_update_handler(crtc, 0, 0,
drmmode_crtc);
- radeon_bo_wait(drmmode_crtc->scanout[0].bo);
+ radeon_scanout_do_update(crtc, scanout_id);
+
radeon_bo_wait(drmmode_crtc->scanout[scanout_id].bo);
}
}
@@ -897,7 +897,7 @@ done:
} else {
crtc->active = TRUE;
- if (fb_id != drmmode_crtc->scanout[0].fb_id)
+ if (fb_id != drmmode_crtc->scanout[scanout_id].fb_id)
drmmode_crtc_scanout_free(drmmode_crtc);
}
@@ -1134,13 +1134,13 @@ static Bool
drmmode_set_scanout_pixmap(xf86CrtcPtr crtc, PixmapPtr ppix)
{
drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
+ unsigned scanout_id = drmmode_crtc->scanout_id;
RADEONInfoPtr info = RADEONPTR(crtc->scrn);
ScreenPtr screen = crtc->scrn->pScreen;
PixmapDirtyUpdatePtr dirty;
xorg_list_for_each_entry(dirty, >pixmap_dirty_list, ent) {
- if (dirty->slave_dst !=
- drmmode_crtc->scanout[drmmode_crtc->scanout_id].pixmap)
+ if (dirty->slave_dst !=
drmmode_crtc->scanout[scanout_id].pixmap)
continue;
PixmapStopDirtyTracking(dirty->src, dirty->slave_dst);
@@ -1165,13 +1165,13 @@ drmmode_set_scanout_pixmap(xf86CrtcPtr crtc, PixmapPtr
ppix)
}
#ifdef HAS_DIRTYTRACKING_ROTATION
- PixmapStartDirtyTracking(ppix, drmmode_crtc->scanout[0].pixmap,
+ PixmapStartDirtyTracking(ppix, drmmode_crtc->scanout[scanout_id].pixmap,
0, 0, 0, 0, RR_Rotate_0);
#elif defined(HAS_DIRTYTRACKING2)
- PixmapStartDirtyTracking2(ppix, drmmode_crtc->scanout[0].pixmap,
+ PixmapStartDirtyTracking2(ppix,
drmmode_crtc->scanout[scanout_id].pixmap,
0, 0, 0, 0);
#else
- PixmapStartDirtyTracking(ppix, drmmode_crtc->scanout[0].pixmap, 0, 0);
+ PixmapStartDirtyTracking(ppix,
drmmode_crtc->scanout[scanout_id].pixmap, 0, 0);
#endif
return TRUE;
}
diff --git a/src/radeon.h b/src/radeon.h
index 8ca8d31..5797bed 100644
--- a/src/radeon.h
+++ b/src/radeon.h
@@ -630,8 +630,7 @@ extern Bool RADEONGetPixmapOffsetPitch(PixmapPtr pPix,
Bool radeon_dri3_screen_init(ScreenPtr screen);
/* radeon_kms.c */
-void radeon_scanout_update_handler(xf86CrtcPtr crtc, uint32_t frame,
- uint64_t usec, void *event_data);
+Bool radeon_scanout_do_update(xf86CrtcPtr xf86_crtc, int scanout_id);
/* radeon_present.c */
Bool radeon_present_screen_init(ScreenPtr screen);
diff --git a/src/radeon_kms.c b/src/radeon_kms.c
index 6281fa5..090ea3f 100644
--- a/src/radeon_kms.c
+++ b/src/radeon_kms.c
@@ -676,7 +676,7 @@ radeon_prime_scanout_do_updat
[PATCH xf86-video-ati 4/4] Call radeon_drm_abort_entry on failure to flip to a scanout pixmap
From: Michel Dänzer <michel.daen...@amd.com>
Fixes leaking the corresponding struct radeon_drm_queue list entry in
that case.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/radeon_kms.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/radeon_kms.c b/src/radeon_kms.c
index 5764c20..48dec96 100644
--- a/src/radeon_kms.c
+++ b/src/radeon_kms.c
@@ -807,6 +807,7 @@ radeon_prime_scanout_flip(PixmapDirtyUpdatePtr ent)
0, drm_queue_seq, 0) != 0) {
xf86DrvMsg(scrn->scrnIndex, X_WARNING, "flip queue failed in %s: %s\n",
__func__, strerror(errno));
+ radeon_drm_abort_entry(drm_queue_seq);
return;
}
@@ -1083,6 +1084,7 @@ radeon_scanout_flip(ScreenPtr pScreen, RADEONInfoPtr info,
0, drm_queue_seq, 0) != 0) {
xf86DrvMsg(scrn->scrnIndex, X_WARNING, "flip queue failed in %s: %s\n",
__func__, strerror(errno));
+ radeon_drm_abort_entry(drm_queue_seq);
return;
}
--
2.10.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 2/2] drm/amdgpu: fix cursor setting of dce6/dce8
On 14/12/16 03:45 PM, Flora Cui wrote:
> Change-Id: Ic900051ece1bf7aaf01b3811dde4cbe426be8b42
> Signed-off-by: Flora Cui <flora@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 6 +-
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 --
> 2 files changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> index b3846c2..ca1bcf7 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> @@ -1944,9 +1944,7 @@ static int dce_v6_0_crtc_cursor_set2(struct drm_crtc
> *crtc,
>
> dce_v6_0_lock_cursor(crtc, true);
>
> - if (width != amdgpu_crtc->cursor_width ||
> - height != amdgpu_crtc->cursor_height ||
> - hot_x != amdgpu_crtc->cursor_hot_x ||
> + if (hot_x != amdgpu_crtc->cursor_hot_x ||
> hot_y != amdgpu_crtc->cursor_hot_y) {
> int x, y;
>
> @@ -1955,8 +1953,6 @@ static int dce_v6_0_crtc_cursor_set2(struct drm_crtc
> *crtc,
>
> dce_v6_0_cursor_move_locked(crtc, x, y);
>
> - amdgpu_crtc->cursor_width = width;
> - amdgpu_crtc->cursor_height = height;
> amdgpu_crtc->cursor_hot_x = hot_x;
> amdgpu_crtc->cursor_hot_y = hot_y;
> }
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> index c0abadf..fb7c0e9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> @@ -2437,8 +2437,6 @@ static int dce_v8_0_crtc_cursor_set2(struct drm_crtc
> *crtc,
>
> dce_v8_0_cursor_move_locked(crtc, x, y);
>
> - amdgpu_crtc->cursor_width = width;
> - amdgpu_crtc->cursor_height = height;
> amdgpu_crtc->cursor_hot_x = hot_x;
> amdgpu_crtc->cursor_hot_y = hot_y;
> }
>
Good catch, thanks Flora! Please add
Fixes: 7c83d7abc999 ("drm/amdgpu: Only update the CUR_SIZE register when
necessary")
to get
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling Michel Dänzer | http://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: [PATCH] udev_monitor_receive_device() will block when hotplug monitor
On 13/12/16 05:33 PM, jimqu wrote: > udev_monitor_receive_device() will block and wait for the event of udev > use select() to ensure that this will not block. > > Change-Id: I4e8f4629580222e94f55a4c03070741bf5f4024c > Signed-off-by: JimQu <jim...@amd.com> Reviewed and pushed, thanks! P.S. Please run git config --global user.name "Jim Qu" git config email.prefix "PATCH $(basename $PWD)" in your Git tree. -- Earthling Michel Dänzer | http://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: [V3 04/11] drm/amdgpu/virt: use kiq to access registers
On 12/01/17 12:21 PM, Liu, Monk wrote: > >if (in_interrupt()) > BUG(); Current coding style is BUG_ON(in_interrupt()); according to https://kernelnewbies.org/FAQ/BUG . -- Earthling Michel Dänzer | http://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: [PATCH] Revert "drm/amdgpu: Only update the CUR_SIZE register when necessary"
On 12/01/17 02:35 AM, Deucher, Alexander wrote: >> -Original Message- >> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf >> Of Michel Dänzer >> Sent: Wednesday, January 11, 2017 4:36 AM >> To: amd-gfx@lists.freedesktop.org >> Cc: Harald Judt; Johannes Hirte >> Subject: [PATCH] Revert "drm/amdgpu: Only update the CUR_SIZE register >> when necessary" >> >> From: Michel Dänzer <michel.daen...@amd.com> >> >> This reverts commits 7c83d7abc9997cf1efac2c0ce384b5e8453ee870 and >> a1f49cc179ce6b7b7758ae3ff5cdb138d0ee0f56. >> >> They caused the HW cursor to disappear under various circumstances in >> the wild. I wasn't able to reproduce any of them, and I'm not sure >> what's going on. But those changes aren't a big deal anyway, so let's >> just revert for now. >> >> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=191291 >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99143 >> Signed-off-by: Michel Dänzer <michel.daen...@amd.com> > > Acked-by: Alex Deucher <alexander.deuc...@amd.com> Thanks Alex. Which tree should I commit this to, in order for you to pick it up for 4.10? -- Earthling Michel Dänzer | http://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
[PATCH] Revert "drm/amdgpu: Only update the CUR_SIZE register when necessary"
From: Michel Dänzer <michel.daen...@amd.com>
This reverts commits 7c83d7abc9997cf1efac2c0ce384b5e8453ee870 and
a1f49cc179ce6b7b7758ae3ff5cdb138d0ee0f56.
They caused the HW cursor to disappear under various circumstances in
the wild. I wasn't able to reproduce any of them, and I'm not sure
what's going on. But those changes aren't a big deal anyway, so let's
just revert for now.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=191291
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99143
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 22 +++---
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 22 +++---
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 24 +---
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 22 +++---
4 files changed, 30 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 4fa12933e1fe..db6e2992b49c 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -2513,6 +2513,8 @@ static int dce_v10_0_cursor_move_locked(struct drm_crtc
*crtc,
WREG32(mmCUR_POSITION + amdgpu_crtc->crtc_offset, (x << 16) | y);
WREG32(mmCUR_HOT_SPOT + amdgpu_crtc->crtc_offset, (xorigin << 16) |
yorigin);
+ WREG32(mmCUR_SIZE + amdgpu_crtc->crtc_offset,
+ ((amdgpu_crtc->cursor_width - 1) << 16) |
(amdgpu_crtc->cursor_height - 1));
return 0;
}
@@ -2538,7 +2540,6 @@ static int dce_v10_0_crtc_cursor_set2(struct drm_crtc
*crtc,
int32_t hot_y)
{
struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
- struct amdgpu_device *adev = crtc->dev->dev_private;
struct drm_gem_object *obj;
struct amdgpu_bo *aobj;
int ret;
@@ -2579,7 +2580,9 @@ static int dce_v10_0_crtc_cursor_set2(struct drm_crtc
*crtc,
dce_v10_0_lock_cursor(crtc, true);
- if (hot_x != amdgpu_crtc->cursor_hot_x ||
+ if (width != amdgpu_crtc->cursor_width ||
+ height != amdgpu_crtc->cursor_height ||
+ hot_x != amdgpu_crtc->cursor_hot_x ||
hot_y != amdgpu_crtc->cursor_hot_y) {
int x, y;
@@ -2588,16 +2591,10 @@ static int dce_v10_0_crtc_cursor_set2(struct drm_crtc
*crtc,
dce_v10_0_cursor_move_locked(crtc, x, y);
- amdgpu_crtc->cursor_hot_x = hot_x;
- amdgpu_crtc->cursor_hot_y = hot_y;
- }
-
- if (width != amdgpu_crtc->cursor_width ||
- height != amdgpu_crtc->cursor_height) {
- WREG32(mmCUR_SIZE + amdgpu_crtc->crtc_offset,
- (width - 1) << 16 | (height - 1));
amdgpu_crtc->cursor_width = width;
amdgpu_crtc->cursor_height = height;
+ amdgpu_crtc->cursor_hot_x = hot_x;
+ amdgpu_crtc->cursor_hot_y = hot_y;
}
dce_v10_0_show_cursor(crtc);
@@ -2621,7 +2618,6 @@ static int dce_v10_0_crtc_cursor_set2(struct drm_crtc
*crtc,
static void dce_v10_0_cursor_reset(struct drm_crtc *crtc)
{
struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
- struct amdgpu_device *adev = crtc->dev->dev_private;
if (amdgpu_crtc->cursor_bo) {
dce_v10_0_lock_cursor(crtc, true);
@@ -2629,10 +2625,6 @@ static void dce_v10_0_cursor_reset(struct drm_crtc *crtc)
dce_v10_0_cursor_move_locked(crtc, amdgpu_crtc->cursor_x,
amdgpu_crtc->cursor_y);
- WREG32(mmCUR_SIZE + amdgpu_crtc->crtc_offset,
- (amdgpu_crtc->cursor_width - 1) << 16 |
- (amdgpu_crtc->cursor_height - 1));
-
dce_v10_0_show_cursor(crtc);
dce_v10_0_lock_cursor(crtc, false);
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index 297b1f241ec9..8a116b733f25 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -2533,6 +2533,8 @@ static int dce_v11_0_cursor_move_locked(struct drm_crtc
*crtc,
WREG32(mmCUR_POSITION + amdgpu_crtc->crtc_offset, (x << 16) | y);
WREG32(mmCUR_HOT_SPOT + amdgpu_crtc->crtc_offset, (xorigin << 16) |
yorigin);
+ WREG32(mmCUR_SIZE + amdgpu_crtc->crtc_offset,
+ ((amdgpu_crtc->cursor_width - 1) << 16) |
(amdgpu_crtc->cursor_height - 1));
return 0;
}
@@ -2558,7 +2560,6 @@ static int dce_v11_0_crtc_cursor_set2(struct drm_crtc
*crtc,
int32_t hot_y)
{
struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
- struct amdgpu_device *adev = crtc->dev->dev_private;
Re: [PATCH] drm/amd/amdgpu: validate the shadow BO.
On 02/12/16 01:21 AM, Alex Deucher wrote: > From: Alex Xie <alexbin@amd.com> > > Fixes a rare NULL pointer dereference in amdgpu_ttm_bind. > > The issue was found by Nicolai Haehnle. > The patch was tested by Nicolai Haehnle. Just as a suggestion for next time, this can be simplified to Reported-and-Tested-by: Nicolai Haehnle <nicolai.haeh...@amd.com> :) -- Earthling Michel Dänzer | http://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
[PATCH xf86-video-amdgpu 4/4] Call amdgpu_drm_abort_entry on failure to flip to a scanout pixmap
From: Michel Dänzer <michel.daen...@amd.com>
Fixes leaking the corresponding struct amdgpu_drm_queue list entry in
that case.
(Ported from radeon commit e2942449171fe628a7726e59bcaab65e27d88563)
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/amdgpu_kms.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/amdgpu_kms.c b/src/amdgpu_kms.c
index f8556c9..b2d098a 100644
--- a/src/amdgpu_kms.c
+++ b/src/amdgpu_kms.c
@@ -714,6 +714,7 @@ amdgpu_prime_scanout_flip(PixmapDirtyUpdatePtr ent)
0, drm_queue_seq, 0) != 0) {
xf86DrvMsg(scrn->scrnIndex, X_WARNING, "flip queue failed in
%s: %s\n",
__func__, strerror(errno));
+ amdgpu_drm_abort_entry(drm_queue_seq);
return;
}
@@ -985,6 +986,7 @@ amdgpu_scanout_flip(ScreenPtr pScreen, AMDGPUInfoPtr info,
0, drm_queue_seq, 0) != 0) {
xf86DrvMsg(scrn->scrnIndex, X_WARNING, "flip queue failed in
%s: %s\n",
__func__, strerror(errno));
+ amdgpu_drm_abort_entry(drm_queue_seq);
return;
}
--
2.10.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH xf86-video-amdgpu 2/4] Fix amdgpu_scanout_extents_intersect for GPU screens
From: Michel Dänzer <michel.daen...@amd.com>
Fixes incorrect screen updates with TearFree enabled on PRIME slave
outputs which are not located at (0, 0).
(Ported from radeon commit a995f5830916a0fee5126263d1bfe48632be3a15)
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/amdgpu_kms.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/src/amdgpu_kms.c b/src/amdgpu_kms.c
index 48e65a1..8a2fd30 100644
--- a/src/amdgpu_kms.c
+++ b/src/amdgpu_kms.c
@@ -300,11 +300,21 @@ static Bool AMDGPUCreateScreenResources_KMS(ScreenPtr
pScreen)
static Bool
amdgpu_scanout_extents_intersect(xf86CrtcPtr xf86_crtc, BoxPtr extents)
{
- extents->x1 -= xf86_crtc->filter_width >> 1;
- extents->x2 += xf86_crtc->filter_width >> 1;
- extents->y1 -= xf86_crtc->filter_height >> 1;
- extents->y2 += xf86_crtc->filter_height >> 1;
- pixman_f_transform_bounds(_crtc->f_framebuffer_to_crtc, extents);
+#ifdef AMDGPU_PIXMAP_SHARING
+ if (xf86_crtc->scrn->is_gpu) {
+ extents->x1 -= xf86_crtc->x;
+ extents->y1 -= xf86_crtc->y;
+ extents->x2 -= xf86_crtc->x;
+ extents->y2 -= xf86_crtc->y;
+ } else
+#endif
+ {
+ extents->x1 -= xf86_crtc->filter_width >> 1;
+ extents->x2 += xf86_crtc->filter_width >> 1;
+ extents->y1 -= xf86_crtc->filter_height >> 1;
+ extents->y2 += xf86_crtc->filter_height >> 1;
+ pixman_f_transform_bounds(_crtc->f_framebuffer_to_crtc,
extents);
+ }
extents->x1 = max(extents->x1, 0);
extents->y1 = max(extents->y1, 0);
--
2.10.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH xf86-video-amdgpu 1/4] Take current scanout_id into account everywhere involved with TearFree
From: Michel Dänzer <michel.daen...@amd.com>
Fixes various potential issues with TearFree enabled, e.g. outputs
freezing after display configuration changes.
(Ported from radeon commit e543ef3a2fb304cbe3a965fb780632af2e4186f4)
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/amdgpu_drv.h | 3 +--
src/amdgpu_kms.c | 6 +++---
src/drmmode_display.c | 20 ++--
3 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/src/amdgpu_drv.h b/src/amdgpu_drv.h
index 4eb4cf4..3a24fa7 100644
--- a/src/amdgpu_drv.h
+++ b/src/amdgpu_drv.h
@@ -292,8 +292,7 @@ typedef struct {
Bool amdgpu_dri3_screen_init(ScreenPtr screen);
/* amdgpu_kms.c */
-void amdgpu_scanout_update_handler(xf86CrtcPtr crtc, uint32_t frame,
- uint64_t usec, void *event_data);
+Bool amdgpu_scanout_do_update(xf86CrtcPtr xf86_crtc, int scanout_id);
/* amdgpu_present.c */
Bool amdgpu_present_screen_init(ScreenPtr screen);
diff --git a/src/amdgpu_kms.c b/src/amdgpu_kms.c
index bc48ca6..48e65a1 100644
--- a/src/amdgpu_kms.c
+++ b/src/amdgpu_kms.c
@@ -582,7 +582,7 @@ amdgpu_prime_scanout_do_update(xf86CrtcPtr crtc, unsigned
scanout_id)
return ret;
}
-void
+static void
amdgpu_prime_scanout_update_handler(xf86CrtcPtr crtc, uint32_t frame, uint64_t
usec,
void *event_data)
{
@@ -757,7 +757,7 @@ amdgpu_dirty_update(ScrnInfoPtr scrn)
}
#endif
-static Bool
+Bool
amdgpu_scanout_do_update(xf86CrtcPtr xf86_crtc, int scanout_id)
{
drmmode_crtc_private_ptr drmmode_crtc = xf86_crtc->driver_private;
@@ -863,7 +863,7 @@ amdgpu_scanout_update_abort(xf86CrtcPtr crtc, void
*event_data)
drmmode_crtc->scanout_update_pending = FALSE;
}
-void
+static void
amdgpu_scanout_update_handler(xf86CrtcPtr crtc, uint32_t frame, uint64_t usec,
void *event_data)
{
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 30a0f54..79c9390 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -663,6 +663,7 @@ drmmode_set_mode_major(xf86CrtcPtr crtc, DisplayModePtr
mode,
AMDGPUEntPtr pAMDGPUEnt = AMDGPUEntPriv(pScrn);
xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(crtc->scrn);
drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
+ unsigned scanout_id = drmmode_crtc->scanout_id ^ info->tear_free;
drmmode_ptr drmmode = drmmode_crtc->drmmode;
int saved_x, saved_y;
Rotation saved_rotation;
@@ -714,7 +715,7 @@ drmmode_set_mode_major(xf86CrtcPtr crtc, DisplayModePtr
mode,
fb_id = drmmode->fb_id;
#ifdef AMDGPU_PIXMAP_SHARING
if (crtc->randr_crtc && crtc->randr_crtc->scanout_pixmap) {
- fb_id = drmmode_crtc->scanout[0].fb_id;
+ fb_id = drmmode_crtc->scanout[scanout_id].fb_id;
x = y = 0;
} else
#endif
@@ -758,11 +759,10 @@ drmmode_set_mode_major(xf86CrtcPtr crtc, DisplayModePtr
mode,
pBox->x2 = max(pBox->x2, pScrn->virtualX);
pBox->y2 = max(pBox->y2, pScrn->virtualY);
- drmmode_crtc->scanout_id = 0;
- fb_id = drmmode_crtc->scanout[0].fb_id;
+ fb_id = drmmode_crtc->scanout[scanout_id].fb_id;
x = y = 0;
- amdgpu_scanout_update_handler(crtc, 0, 0,
drmmode_crtc);
+ amdgpu_scanout_do_update(crtc, scanout_id);
amdgpu_glamor_finish(pScrn);
}
}
@@ -845,7 +845,7 @@ done:
} else {
crtc->active = TRUE;
- if (fb_id != drmmode_crtc->scanout[0].fb_id)
+ if (fb_id != drmmode_crtc->scanout[scanout_id].fb_id)
drmmode_crtc_scanout_free(drmmode_crtc);
}
@@ -1096,13 +1096,13 @@ drmmode_crtc_gamma_set(xf86CrtcPtr crtc, uint16_t *
red, uint16_t * green,
static Bool drmmode_set_scanout_pixmap(xf86CrtcPtr crtc, PixmapPtr ppix)
{
drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
+ unsigned scanout_id = drmmode_crtc->scanout_id;
AMDGPUInfoPtr info = AMDGPUPTR(crtc->scrn);
ScreenPtr screen = crtc->scrn->pScreen;
PixmapDirtyUpdatePtr dirty;
xorg_list_for_each_entry(dirty, >pixmap_dirty_list, ent) {
- if (dirty->slave_dst !=
- drmmode_crtc->scanout[drmmode_crtc->scanout_id].pixmap)
+ if (dirty->slave_dst !=
drmmode_crtc->scanout[scanout_id].pixmap)
continue;
PixmapStopDirtyTracking(dirty->src, dirty
Re: [PATCH] drm/amdgpu: don't add files at control minor debugfs directory
On 06/12/16 05:07 AM, Alex Deucher wrote:
> Since commit 8a357d10043c ("drm: Nerf DRM_CONTROL nodes"), a
> struct drm_device's ->control member is always NULL.
>
> In the case of CONFIG_DEBUG_FS=y, amdgpu_debugfs_add_files() accesses
> ->control->debugfs_root though. This results in the following Oops:
>
> [9.627636] BUG: unable to handle kernel NULL pointer dereference at
> 0018
> [9.628274] IP: amdgpu_debugfs_add_files+0x8d/0x100 [amdgpu]
> [9.628867] PGD 2514c7067
> [9.628876] PUD 2514c8067
> [9.629448] PMD 0
> [9.630026] Oops: [#1] PREEMPT SMP
> [...]
> [9.639906] Call Trace:
> [9.640538] amdgpu_fence_driver_init+0x1e/0x40 [amdgpu]
> [9.641186] amdgpu_device_init+0xa6d/0x1410 [amdgpu]
> [9.641900] ? kmalloc_order_trace+0x2e/0x100
> [9.642587] amdgpu_driver_load_kms+0x5b/0x200 [amdgpu]
> [9.643355] drm_dev_register+0xa7/0xd0
> [9.644016] drm_get_pci_dev+0xde/0x1d0
> [9.644659] amdgpu_pci_probe+0xbe/0xf0 [amdgpu]
> [...]
>
> Fix this by omitting the drm_debugfs_create_files() call for the
> control minor debugfs directory which is now non-existent anyway.
>
> Port of Nicolai Stange's radeon patch to amdgpu.
>
> bug: https://bugs.freedesktop.org/show_bug.cgi?id=98915
Not sure about the kernel, but in other projects the convention is
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98915
> Fixes: 8a357d10043c ("drm: Nerf DRM_CONTROL nodes")
> Signed-off-by: Alex Deucher <alexander.deuc...@amd.com>
Regardless of the above,
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling Michel Dänzer | http://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
[PATCH] drm/amdgpu/dce6: Set MASTER_UPDATE_MODE to 0 in resume_mc_access as well
From: Michel Dänzer <michel.daen...@amd.com>
Looks like this was missed when dce_v6_0.c was added.
Fixes: e2cdf640cbb5 ("drm/amdgpu: add display controller implementation for si
v10")
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
index 03c8529a8e02..c81ae9c4e4b8 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
@@ -456,9 +456,8 @@ static void dce_v6_0_resume_mc_access(struct amdgpu_device
*adev,
for (i = 0; i < adev->mode_info.num_crtc; i++) {
if (save->crtc_enabled[i]) {
tmp = RREG32(EVERGREEN_MASTER_UPDATE_MODE +
crtc_offsets[i]);
- if ((tmp & 0x7) != 3) {
+ if ((tmp & 0x7) != 0) {
tmp &= ~0x7;
- tmp |= 0x3;
WREG32(EVERGREEN_MASTER_UPDATE_MODE +
crtc_offsets[i], tmp);
}
tmp = RREG32(EVERGREEN_GRPH_UPDATE + crtc_offsets[i]);
--
2.11.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH xf86-video-ati] Replace loop with clz to calculate log base 2 on non-x86 platforms in radeon.h
On 01/12/16 02:52 AM, Jochen Rollwagen wrote:
> Am 29.11.2016 um 08:32 schrieb Michel Dänzer:
>> On 29/11/16 03:18 AM, Jochen Rollwagen wrote:
>>> This commit replaces the loop for calculating log base 2 for
>>> non-x86-platforms in radeon.h with a clz (count leading zeroes)-based
>>> version to simplify the code and, well, eliminate the loop.
>>> Note: There’s no check for val=0 case, since x86-bsr is undefined for
>>> that case too, that should be okay.
>>> ---
>>> src/radeon.h |7 +++
>>> 1 file changed, 3 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/src/radeon.h b/src/radeon.h
>>> index cbc7866..b1a1ce0 100644
>>> --- a/src/radeon.h
>>> +++ b/src/radeon.h
>>> @@ -933,17 +933,16 @@ enum {
>>> static __inline__ int
>>> RADEONLog2(int val)
>>> {
>>> -int bits;
>>> #if (defined __i386__ || defined __x86_64__) && (defined __GNUC__)
>>> +int bits;
>>> +
>>> __asm volatile("bsrl%1, %0"
>>> : "=r" (bits)
>>> : "c" (val)
>>> );
>>> return bits;
>>> #else
>>> -for (bits = 0; val != 0; val >>= 1, ++bits)
>>> -;
>>> -return bits - 1;
>>> +return (31 - __builtin_clz(val));
>>> #endif
>>> }
>> Any reason for not using __builtin_clz on x86 as well? AFAICT both gcc
>> and clang seem to generate more or less the same code with that as with
>> the inline assembly.
>>
>>
> I guess not. According to
> http://stackoverflow.com/questions/9353973/implementation-of-builtin-clz
> "bsr and clz are related but different.
>
> On x86 for clz gcc (-O2) generates:
>
> bsrl %edi, %eax
> xorl $31, %eax
> ret "
That's not what I'm seeing. Have you compared the code generated by your
compiler in both cases?
--
Earthling Michel Dänzer | http://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: [PATCH] drm/amdgpu: add flag for high priority contexts
On 05/01/17 05:51 AM, Andres Rodriguez wrote: > On 2017-01-04 06:54 AM, Mao, David wrote: >> Hi Andres, >> I did not follow the previous discussion, so please remind me if my >> questions have been covered already~ >> - The priority should be the queue properties, and do we really want >> to expose high priority on none-compute queue? > I exposing the concept across all queues is good for consistency. It > will probably end up staying as a SW-scheduler feature for all queues > except for compute. > > However, if we do end up getting some HW features that enable priority > support on other engines, then the API will be ready, and we'll only > need a kernel side change to enable the support. > >> - Another question is we may need to do per submission priority tweak >> if we don't reserve one compute queue ahead of time. >> From the patch, it seems you only tweak the GPU scheduler's priority, >> but I think it is still insufficient given we don't have OS preemption >> supported, > Correct, the current patch is just to get an environment in place to > start doing measurements. With this framework in place we can start > adding HW support to increase the priorities. > > Dynamic tweaking might be necessary depending on how CU reservation is > going to work. It sounds like it's still too early to tell if this simple priority mechanism will end up being useful. It's probably better to hold off on merging this upstream until you have at least a proof of concept showing that it's actually useful in practice. -- Earthling Michel Dänzer | http://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
[PATCH xf86-video-amdgpu] Pass pitch from drmmode_crtc_scanout_allocate to drmmode_create_bo_pixmap
From: Michel Dänzer <michel.daen...@amd.com>
Mostly to align with radeon commit
ea30d856ba5e7274c8ea499293b8b0e721b8e082, but also gets rid of a
gbm_bo_get_stride call.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/drmmode_display.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 63b3b076..4c35657b 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -497,14 +497,13 @@ drmmode_scanout_free(ScrnInfoPtr scrn)
static void *
drmmode_crtc_scanout_allocate(xf86CrtcPtr crtc,
struct drmmode_scanout *scanout,
- int width, int height)
+ int width, int height, int *pitch)
{
ScrnInfoPtr pScrn = crtc->scrn;
AMDGPUEntPtr pAMDGPUEnt = AMDGPUEntPriv(pScrn);
drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
drmmode_ptr drmmode = drmmode_crtc->drmmode;
int ret;
- int pitch;
union gbm_bo_handle bo_handle;
if (scanout->bo) {
@@ -515,8 +514,8 @@ drmmode_crtc_scanout_allocate(xf86CrtcPtr crtc,
}
scanout->bo = amdgpu_alloc_pixmap_bo(pScrn, width, height,
- pScrn->depth, 0,
- pScrn->bitsPerPixel, );
+pScrn->depth, 0,
+pScrn->bitsPerPixel, pitch);
if (!scanout->bo) {
xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
"Failed to allocate rotation buffer memory\n");
@@ -525,7 +524,7 @@ drmmode_crtc_scanout_allocate(xf86CrtcPtr crtc,
bo_handle = gbm_bo_get_handle(scanout->bo->bo.gbm);
ret = drmModeAddFB(pAMDGPUEnt->fd, width, height, pScrn->depth,
- pScrn->bitsPerPixel, pitch,
+ pScrn->bitsPerPixel, *pitch,
bo_handle.u32, >fb_id);
if (ret) {
ErrorF("failed to add rotate fb\n");
@@ -547,7 +546,7 @@ drmmode_crtc_scanout_create(xf86CrtcPtr crtc,
ScrnInfoPtr pScrn = crtc->scrn;
drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
drmmode_ptr drmmode = drmmode_crtc->drmmode;
- unsigned long rotate_pitch;
+ int pitch;
if (scanout->pixmap) {
if (scanout->width == width && scanout->height == height)
@@ -557,18 +556,16 @@ drmmode_crtc_scanout_create(xf86CrtcPtr crtc,
}
if (!scanout->bo) {
- if (!drmmode_crtc_scanout_allocate(crtc, scanout, width,
height))
+ if (!drmmode_crtc_scanout_allocate(crtc, scanout, width, height,
+ ))
return NULL;
}
- rotate_pitch = gbm_bo_get_stride(scanout->bo->bo.gbm);
-
scanout->pixmap = drmmode_create_bo_pixmap(pScrn,
width, height,
pScrn->depth,
pScrn->bitsPerPixel,
-rotate_pitch,
-scanout->bo);
+pitch, scanout->bo);
if (scanout->pixmap == NULL) {
xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
"Couldn't allocate shadow pixmap for rotated
CRTC\n");
@@ -1054,9 +1051,10 @@ static void *drmmode_crtc_shadow_allocate(xf86CrtcPtr
crtc, int width,
int height)
{
drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
+ int pitch;
return drmmode_crtc_scanout_allocate(crtc, _crtc->rotate,
-width, height);
+width, height, );
}
static PixmapPtr
--
2.11.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH xf86-video-ati] Pass pitch from drmmode_crtc_scanout_allocate to drmmode_create_bo_pixmap
From: Michel Dänzer <michel.daen...@amd.com>
radeon_bo_get_tiling can fail, e.g. for linear BOs.
Fixes TearFree not working in those cases.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97873
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/drmmode_display.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index ce8064644..0fb0d7700 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -116,14 +116,6 @@ static PixmapPtr drmmode_create_bo_pixmap(ScrnInfoPtr
pScrn,
if (!pixmap)
return NULL;
- if (pitch <= 0 &&
- (radeon_bo_get_tiling(bo, , (uint32_t*)) != 0 ||
-pitch <= 0)) {
- ErrorF("radeon_bo_get_tiling failed to determine pitch\n");
- pScreen->DestroyPixmap(pixmap);
- return NULL;
- }
-
if (!(*pScreen->ModifyPixmapHeader)(pixmap, width, height,
depth, bpp, pitch, NULL)) {
goto fail;
@@ -561,7 +553,7 @@ drmmode_scanout_free(ScrnInfoPtr scrn)
static void *
drmmode_crtc_scanout_allocate(xf86CrtcPtr crtc,
struct drmmode_scanout *scanout,
- int width, int height)
+ int width, int height, int *pitch)
{
ScrnInfoPtr pScrn = crtc->scrn;
RADEONInfoPtr info = RADEONPTR(pScrn);
@@ -570,7 +562,6 @@ drmmode_crtc_scanout_allocate(xf86CrtcPtr crtc,
struct radeon_surface surface;
uint32_t tiling = RADEON_CREATE_PIXMAP_TILING_MACRO;
int ret;
- int pitch;
if (scanout->bo) {
if (scanout->width == width && scanout->height == height)
@@ -583,14 +574,14 @@ drmmode_crtc_scanout_allocate(xf86CrtcPtr crtc,
tiling |= RADEON_CREATE_PIXMAP_TILING_MICRO;
scanout->bo = radeon_alloc_pixmap_bo(pScrn, width, height, pScrn->depth,
tiling, pScrn->bitsPerPixel,
-, , );
+pitch, , );
if (scanout->bo == NULL)
return NULL;
radeon_bo_map(scanout->bo, 1);
ret = drmModeAddFB(drmmode->fd, width, height, pScrn->depth,
- pScrn->bitsPerPixel, pitch,
+ pScrn->bitsPerPixel, *pitch,
scanout->bo->handle,
>fb_id);
if (ret) {
@@ -612,6 +603,7 @@ drmmode_crtc_scanout_create(xf86CrtcPtr crtc, struct
drmmode_scanout *scanout,
ScrnInfoPtr pScrn = crtc->scrn;
drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
drmmode_ptr drmmode = drmmode_crtc->drmmode;
+ int pitch;
if (scanout->pixmap) {
if (scanout->width == width && scanout->height == height)
@@ -621,7 +613,8 @@ drmmode_crtc_scanout_create(xf86CrtcPtr crtc, struct
drmmode_scanout *scanout,
}
if (!scanout->bo) {
- if (!drmmode_crtc_scanout_allocate(crtc, scanout, width,
height))
+ if (!drmmode_crtc_scanout_allocate(crtc, scanout, width, height,
+ ))
return NULL;
}
@@ -629,7 +622,7 @@ drmmode_crtc_scanout_create(xf86CrtcPtr crtc, struct
drmmode_scanout *scanout,
width, height,
pScrn->depth,
pScrn->bitsPerPixel,
--1, scanout->bo, NULL);
+pitch, scanout->bo, NULL);
if (scanout->pixmap == NULL)
xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
"Couldn't allocate scanout pixmap for CRTC\n");
@@ -1092,9 +1085,10 @@ static void *
drmmode_crtc_shadow_allocate(xf86CrtcPtr crtc, int width, int height)
{
drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
+ int pitch;
return drmmode_crtc_scanout_allocate(crtc, _crtc->rotate,
-width, height);
+width, height, );
}
static PixmapPtr
--
2.11.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH libdrm 2/7] amdgpu: update amdgpu_drm.h for Vega10
On 22/03/17 07:13 PM, Marek Olšák wrote: > On Mar 22, 2017 2:44 AM, "Michel Dänzer" <mic...@daenzer.net > <mailto:mic...@daenzer.net>> wrote: >> On 22/03/17 06:46 AM, Marek Olšák wrote: >>> On Tue, Mar 21, 2017 at 10:27 PM, Nicolai Hähnle >>> <nhaeh...@gmail.com <mailto:nhaeh...@gmail.com>> wrote: >>>> In the past, I was told off for patches that update this file >>>> without following the procedure described in >>>> include/drm/README. Tbh, that procedure causes some >>>> annoyances. >>>> >>>> Anyway, it's definitely useful to have the patch out on the >>>> mailing list in any case. >>> >>> Yeah, I know the correct process and I plan to ignore it this >>> time if I don't get too much backlash, because the alternative >>> (#ifdef/#define/#endif) is probably even worse. >> >> FWIW, only AMDGPU_TILING_SET/GET need #undef, >> AMDGPU_TILING_SWIZZLE_MODE_SHIFT/MASK and AMDGPU_FAMILY_AI can just >> be #defined directly, that way the preprocessor will warn if the >> definitions in libdrm and Mesa end up being inconsistent for some >> reason. >> >> >> The alternative is rushing out a libdrm release and making Mesa >> require that, right? That doesn't seem obviously better than a >> handful of temporary redundant defines in Mesa, hardly >> justification for bypassing the normal process. > > I need a libdrm release because of the 3rd patch. I can't allow Mesa > to run without that. Gotcha, thanks for the clarification. -- Earthling Michel Dänzer | http://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: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"
On 23/03/17 03:19 AM, Zachary Michaels wrote: > We were experiencing an infinite loop due to VRAM bos getting added back > to the VRAM lru on eviction via ttm_bo_mem_force_space, Can you share more details about what happened? I can imagine that moving a BO from CPU visible to CPU invisible VRAM would put it back on the LRU, but next time around it shouldn't hit this code anymore but get evicted to GTT directly. Was userspace maybe performing concurrent CPU access to the BOs in question? > and reverting this commit solves the problem. I hope we can find a better solution. -- Earthling Michel Dänzer | http://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: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"
On 24/03/17 06:50 PM, Julien Isorce wrote: > Hi Michel, > > (Just for other readers my reply has been delayed on the mailing lists > and should have been on second position) It is on https://patchwork.freedesktop.org/patch/145731/ , did you mean something else? The delay was because you weren't subscribed to the amd-gfx mailing list yet, so your post went through the moderation queue. > I will have a go with that change and let you know. I do not remember if > I tried it for this soft lockup. But for sure it does not solve the hard > lockup that Zach also mentioned at the end of his reply. I'll follow up to his post about that. > But in general, isn't "radeon_lockup_timeout" supposed to detect this > situation ? No, it's for detecting GPU hangs, whereas this is a CPU "hang" (infinite loop). -- Earthling Michel Dänzer | http://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: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"
On 28/03/17 05:24 PM, Julien Isorce wrote: > Hi Michel, > > About the hard lockup, I noticed that I cannot have it with the > following conditions: > > 1. soft lockup fix (the 0->i change which avoids infinite loop) > 2. Your suggestion: (!(rbo->flags & RADEON_GEM_CPU_ACCESS) > 3. radeon.gartsize=512 radeon.vramlimit=1024 (any other values above do > not help, for example (1024, 1024) or (1024, 2048)) > > Without 1 and 2, but with 3, our test reproduces the soft lockup (just > discovered few days ago). > Without 3 (and with or without 1., 2.), our test reproduces the hard > lockup which one does not give any info in kern.log (sometimes some NUL > ^@ characters but not always). What exactly does "hard lockup" mean? What are the symptoms? -- Earthling Michel Dänzer | http://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: Plan: BO move throttling for visible VRAM evictions
On 28/03/17 05:29 PM, Christian König wrote: > Am 28.03.2017 um 08:00 schrieb Michel Dänzer: >> On 28/03/17 12:50 PM, zhoucm1 wrote: >>> On 2017年03月28日 10:40, Michel Dänzer wrote: >>>> On 27/03/17 04:53 PM, Zhou, David(ChunMing) wrote: >>>>> For APU special case, can we prevent eviction happening between VRAM >>>>> <> GTT? >>>> We can, if we can close the performance gap between VRAM and GTT. We >>>> measured around 30% gap a while ago, though right now I'm only >>>> measuring >>>> ~5%, but the test system has slower RAM now (still dual channel >>>> though). >>> My impression VRAM and GTT have no much difference for APU case, if I'm >>> wrong, pls correct me. >> The Mesa patch below makes radeonsi use mostly GTT instead of mostly >> VRAM, and slows down Unigine Valley by about 5% on my desktop Kaveri. >> You can try it for yourself. > > Additional to that you still need the stolen VRAM on APUs for page > tables and DCE. > > So we need to keep the eviction from VRAM to GTT enabled, but what we > don't do is swapping them back in because Marek added the GTT flags on > APUs as extra domain to look into. As long as there's a performance gap between VRAM and GTT, this means that performance of long-running apps (e.g. Xorg or the compositor) will degrade over time, or after e.g. a suspend-resume cycle. OTOH, if we can close the gap, we can stop trying to put most BOs in VRAM in the first place with APUs. -- Earthling Michel Dänzer | http://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: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"
On 25/03/17 03:59 AM, Julien Isorce wrote: > Hi Michel, > > I double checked and you are right, the change 0 -> i works. Thanks for testing, fix submitted for review. -- Earthling Michel Dänzer | http://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: Plan: BO move throttling for visible VRAM evictions
On 25/03/17 01:33 AM, Marek Olšák wrote: > Hi, > > I'm sharing this idea here, because it's something that has been > decreasing our performance a lot recently, for example: > http://openbenchmarking.org/prospect/1703011-RI-RADEONDIR06/7b7668cfc109d1c3dc27e871c8aea71ca13f23fa > > I think the problem there is that Mesa git started uploading > descriptors and uniforms to VRAM, which helps when TC L2 has a low > hit/miss ratio, but the performance can randomly drop by an order of > magnitude. I've heard rumours that kernel 4.11 has an improved > allocator that should perform better, but the situation is still far > from ideal. > > AMD CPUs and APUs will hopefully suffer less, because we can resize > the visible VRAM with the help of our CPU hw specs, but Intel CPUs > will remain limited to 256 MB. The following plan describes how to do > throttling for visible VRAM evictions. > > > 1) Theory > > Initially, the driver doesn't care about where buffers are in VRAM, > because VRAM buffers are only moved to visible VRAM on CPU page faults > (when the CPU touches the buffer memory but the memory is in the > invisible part of VRAM). When it happens, > amdgpu_bo_fault_reserve_notify is called, which moves the buffer to > visible VRAM, and the app continues. amdgpu_bo_fault_reserve_notify > also marks the buffer as contiguous, which makes memory fragmentation > worse. > > I verified this with DiRT Rally where amdgpu_bo_fault_reserve_notify > was much higher in a CPU profiler than anything else in the kernel. > > > 2) Monitoring via Gallium HUD > > We need to expose 2 kernel counters via the INFO ioctl and display > those via Gallium HUD: > - The number of VRAM CPU page faults. (the number of calls to > amdgpu_bo_fault_reserve_notify). > - The number of bytes moved by ttm_bo_validate inside > amdgpu_bo_fault_reserve_notify. > > This will help us observe what exactly is happening and fine-tune the > throttling when it's done. > > > 3) Solution > > a) When amdgpu_bo_fault_reserve_notify is called, record the fact. > (amdgpu_bo::had_cpu_page_fault = true) > > b) Monitor the MB/s rate at which buffers are moved by > amdgpu_bo_fault_reserve_notify. If we get above a specific threshold, > don't move the buffer to visible VRAM. Move it to GTT instead. Note > that moving to GTT can be cheaper, because moving to visible VRAM is > likely to evict a lot of buffers there and unmap them from the CPU, FWIW, this can be avoided by only setting GTT in busy_placement. Then TTM will only move the BO to visible VRAM if that can be done without evicting anything from there. > but moving to GTT shouldn't evict or unmap anything. > > c) When we get into the CS ioctl and a buffer has had_cpu_page_fault, > it can be moved to VRAM if: > - the GTT->VRAM move rate is low enough to allow it (this is the > existing throttling mechanism) > - the visible VRAM move rate is low enough that we will be OK with > another CPU page fault if it happens. Some other ideas that might be worth trying: Evicting BOs to GTT instead of moving them to CPU accessible VRAM in principle in some cases (e.g. for all BOs except those with AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED) or even always. Implementing eviction from CPU visible to CPU invisible VRAM, similar to how it's done in radeon. Note that there's potential for userspace triggering an infinite loop in the kernel in cases where BOs are moved back from invisible to visible VRAM on page faults. -- Earthling Michel Dänzer | http://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: [PATCH] Fix IB va_start+ib_bytes range check on 32Bit systems
On 29/03/17 10:22 PM, Christian König wrote:
> Am 29.03.2017 um 11:18 schrieb Jan Burgmeier:
>> Signed-off-by: Jan Burgmeier <jan.burgme...@unicon-software.com>
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> index 99424cb8020b..583d22974e14 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> @@ -908,6 +908,7 @@ static int amdgpu_cs_ib_fill(struct amdgpu_device
>> *adev,
>> struct amdgpu_bo *aobj = NULL;
>> uint64_t offset;
>> uint8_t *kptr;
>> +uint64_t it_last;
>> m = amdgpu_cs_find_mapping(parser, chunk_ib->va_start,
>> );
>> @@ -916,8 +917,9 @@ static int amdgpu_cs_ib_fill(struct amdgpu_device
>> *adev,
>> return -EINVAL;
>> }
>> +it_last = m->it.last;
>> if ((chunk_ib->va_start + chunk_ib->ib_bytes) >
>> -(m->it.last + 1) * AMDGPU_GPU_PAGE_SIZE) {
>> +(it_last + 1) * AMDGPU_GPU_PAGE_SIZE) {
>
> Nice catch, but just adding a u64 case should do here as well. E.g:
>
> if ((chunk_ib->va_start + chunk_ib->ib_bytes) >
> (u64)(m->it.last + 1) * AMDGPU_GPU_PAGE_SIZE) {
That won't work correctly if m->it.last == 0x ? Or is that not
possible?
--
Earthling Michel Dänzer | http://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: [PATCH 3/3] drm/amdgpu: Fix multi-level page table bugs for large BOs
On 29/03/17 11:32 PM, Felix Kuehling wrote: > On 17-03-29 02:52 AM, Christian König wrote: >> >> Please clean that up and also remove all those WARN_ON(), we don't >> want to spam the system log with backtraces like this. > > I disagree. When you see the backtraces from WARN_ONs in > amdgpu_vm_get_pt, it means the driver is trying to update a page table > that hasn't been allocated. Without those WARN_ONs there is absolutely > no warning of any kind - amdgpu_vm_update_pte just fails silently (it's > a void function). > > Therefore I wouldn't call those warnings spam. Given that the VM PT > allocation code for multi-levels is non-trivial, I think that's a good > sanity check to have and really helpful to see in a log when user report > random VM faults. WARN_ON_ONCE might be a compromise. We'll still get a backtrace, but it won't cause crazy log spam if the bad condition is consistently hit. -- Earthling Michel Dänzer | http://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: [PATCH 3/3] drm/amdgpu: do not block gpu resume when cp ring test failed.
On 30/03/17 03:45 PM, Zhu, Rex wrote: > Yes, we tried to fix it. it is a timing issue. > But it was not a critical error. So no need to block gpu resume. > > In fact, We only return error when the last ring test failed in the original > logic That makes some sense to me, but at least the commit log would need to be changed not to talk about the KIQ related random failures but just about that gfx_v8_0_kiq_resume would only return failure if the last ring test failed anyway. -- Earthling Michel Dänzer | http://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: Plan: BO move throttling for visible VRAM evictions
On 25/03/17 01:33 AM, Marek Olšák wrote:
> Hi,
>
> I'm sharing this idea here, because it's something that has been
> decreasing our performance a lot recently, for example:
> http://openbenchmarking.org/prospect/1703011-RI-RADEONDIR06/7b7668cfc109d1c3dc27e871c8aea71ca13f23fa
The attached proof-of-concept patch (on top of Christian's "CPU mapping
of split VRAM buffers" series, ported from radeon) results in 145.05 fps
on my Tonga.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 7f9710502bcc..0bb9c0059497 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -205,6 +205,29 @@ static void amdgpu_evict_flags(struct ttm_buffer_object *bo,
case TTM_PL_VRAM:
if (adev->mman.buffer_funcs_ring->ready == false) {
amdgpu_ttm_placement_from_domain(abo, AMDGPU_GEM_DOMAIN_CPU);
+ } else if (adev->mc.visible_vram_size < adev->mc.real_vram_size &&
+ bo->mem.start < (adev->mc.visible_vram_size >> PAGE_SHIFT)) {
+ unsigned fpfn = adev->mc.visible_vram_size >> PAGE_SHIFT;
+ int i;
+
+ /* Try evicting to the CPU inaccessible part of VRAM
+ * first, but only set GTT as busy placement, so this
+ * BO will be evicted to GTT rather than causing other
+ * BOs to be evicted from VRAM
+ */
+ amdgpu_ttm_placement_from_domain(abo, AMDGPU_GEM_DOMAIN_VRAM |
+ AMDGPU_GEM_DOMAIN_GTT);
+ abo->placement.num_busy_placement = 0;
+ for (i = 0; i < abo->placement.num_placement; i++) {
+if (abo->placements[i].flags & TTM_PL_FLAG_VRAM) {
+ if (abo->placements[i].fpfn < fpfn)
+ abo->placements[i].fpfn = fpfn;
+} else {
+ abo->placement.busy_placement =
+ >placements[i];
+ abo->placement.num_busy_placement = 1;
+}
+ }
} else {
amdgpu_ttm_placement_from_domain(abo, AMDGPU_GEM_DOMAIN_GTT);
for (i = 0; i < abo->placement.num_placement; ++i) {
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: CPU mapping of split VRAM buffers
On 29/03/17 09:55 PM, Christian König wrote: > Hi guys, > > this set implements CPU mapping of split VRAM buffers and could > help with some performance issues regarding this. > > Please review and/or comment, Patches 5 & 6 look mostly good to me, but I don't fully understand all changes in there, so I only feel comfortable giving Acked-by: Michel Dänzer <michel.daen...@amd.com> for them. -- Earthling Michel Dänzer | http://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: [PATCH 1/3] drm/amdgpu: delete duplicated printk info.
On 30/03/17 02:42 PM, Rex Zhu wrote:
> Change-Id: I5f336cc41b1868b98f263874fe5c6ea20e430744
> Signed-off-by: Rex Zhu <rex@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 57ccac4..eaf44fb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -2288,9 +2288,6 @@ int amdgpu_device_resume(struct drm_device *dev, bool
> resume, bool fbcon)
> if (r)
> DRM_ERROR("amdgpu_resume failed (%d).\n", r);
>
> - if (r)
> - DRM_ERROR("amdgpu_resume failed (%d).\n", r);
> -
> amdgpu_fence_driver_resume(adev);
>
> if (resume) {
>
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling Michel Dänzer | http://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: [PATCH] Fix IB va_start+ib_bytes range check on 32Bit systems
On 30/03/17 12:18 AM, Christian König wrote:
> Am 29.03.2017 um 16:54 schrieb Michel Dänzer:
>> On 29/03/17 10:22 PM, Christian König wrote:
>>> Am 29.03.2017 um 11:18 schrieb Jan Burgmeier:
>>>> Signed-off-by: Jan Burgmeier <jan.burgme...@unicon-software.com>
>>>> ---
>>>>drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 +++-
>>>>1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>>>> index 99424cb8020b..583d22974e14 100644
>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>>>> @@ -908,6 +908,7 @@ static int amdgpu_cs_ib_fill(struct amdgpu_device
>>>> *adev,
>>>>struct amdgpu_bo *aobj = NULL;
>>>>uint64_t offset;
>>>>uint8_t *kptr;
>>>> +uint64_t it_last;
>>>> m = amdgpu_cs_find_mapping(parser, chunk_ib->va_start,
>>>> );
>>>> @@ -916,8 +917,9 @@ static int amdgpu_cs_ib_fill(struct amdgpu_device
>>>> *adev,
>>>>return -EINVAL;
>>>>}
>>>>+it_last = m->it.last;
>>>>if ((chunk_ib->va_start + chunk_ib->ib_bytes) >
>>>> -(m->it.last + 1) * AMDGPU_GPU_PAGE_SIZE) {
>>>> +(it_last + 1) * AMDGPU_GPU_PAGE_SIZE) {
>>> Nice catch, but just adding a u64 case should do here as well. E.g:
>>>
>>> if ((chunk_ib->va_start + chunk_ib->ib_bytes) >
>>> (u64)(m->it.last + 1) * AMDGPU_GPU_PAGE_SIZE) {
>> That won't work correctly if m->it.last == 0x ? Or is that not
>> possible?
> Hui, why? is it.last signed?
No. If m->it.last == 0x, (m->it.last + 1) == 0, the u64 cast
won't change that. I thought that would be bad, but maybe not?
--
Earthling Michel Dänzer | http://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
Regression caused by "drm/amdgpu: get display info from DC when DC enabled."
Hi Rex, Andy bisected a regression to your commit 91561a39fa74e79b88e0e9d70f3072501c8df2ce, see https://bugs.freedesktop.org/100395 . Any ideas? -- Earthling Michel Dänzer | http://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: [PATCH 3/3] drm/amdgpu: do not block gpu resume when cp ring test failed.
On 30/03/17 02:42 PM, Rex Zhu wrote: > As kiq enabled, ring test may randomly failed because of timing. > it was not critial error, gpu can continue to resume. > > Change-Id: I5d85c7d5b5989dd6892a13b47a5322b33e8a48ac > Signed-off-by: Rex Zhu <rex@amd.com> > --- > drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c > b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c > index 31b1312..cdda93b 100644 > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c > @@ -4975,8 +4975,7 @@ static int gfx_v8_0_kiq_resume(struct amdgpu_device > *adev) > goto done; > > ring->ready = true; > - r = amdgpu_ring_test_ring(ring); > - if (r) > + if (amdgpu_ring_test_ring(ring)) > ring->ready = false; > } > > The random failures in amdgpu_ring_test_ring need to be fixed instead. Failure in there normally does mean we cannot continue. -- Earthling Michel Dänzer | http://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: [PATCH 4/6] drm/amdgpu: drop alpha support
On 29/03/17 09:55 PM, Christian König wrote: > From: Christian König <christian.koe...@amd.com> > > We will probably never see this combination. > > Signed-off-by: Christian König <christian.koe...@amd.com> > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 25 - > 1 file changed, 25 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > index 7bf5ba7..524abca 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > @@ -538,31 +538,6 @@ static int amdgpu_ttm_io_mem_reserve(struct > ttm_bo_device *bdev, struct ttm_mem_ > return -EINVAL; > mem->bus.base = adev->mc.aper_base; > mem->bus.is_iomem = true; > -#ifdef __alpha__ > - /* > - * Alpha: use bus.addr to hold the ioremap() return, > - * so we can modify bus.base below. > - */ > - if (mem->placement & TTM_PL_FLAG_WC) > - mem->bus.addr = > - ioremap_wc(mem->bus.base + mem->bus.offset, > -mem->bus.size); > - else > - mem->bus.addr = > - ioremap_nocache(mem->bus.base + mem->bus.offset, > - mem->bus.size); > - if (!mem->bus.addr) > - return -ENOMEM; > - > - /* > - * Alpha: Use just the bus offset plus > - * the hose/domain memory base for bus.base. > - * It then can be used to build PTEs for VRAM > - * access, as done in ttm_bo_vm_fault(). > - */ > - mem->bus.base = (mem->bus.base & 0x0UL) + > - adev->ddev->hose->dense_mem_base; > -#endif > break; > default: > return -EINVAL; > Maybe leave an #error line, or make AMDGPU depend on !ALPHA in Kconfig, to prevent somebody from trying this driver on an Alpha machine, and it mysteriously failing due to the lack of this? Either way, Acked-by: Michel Dänzer <michel.daen...@amd.com> -- Earthling Michel Dänzer | http://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: [PATCH 3/6] drm/ttm: add TTM_PL_FLAG_CONTIGUOUS
On 29/03/17 09:55 PM, Christian König wrote: > From: Christian König <christian.koe...@amd.com> > > This allows drivers to specify if they need a contiguous allocation or not. > > Signed-off-by: Christian König <christian.koe...@amd.com> [...] > diff --git a/include/drm/ttm/ttm_placement.h b/include/drm/ttm/ttm_placement.h > index 932be0c..40f947f 100644 > --- a/include/drm/ttm/ttm_placement.h > +++ b/include/drm/ttm/ttm_placement.h > @@ -63,6 +63,7 @@ > #define TTM_PL_FLAG_CACHED (1 << 16) > #define TTM_PL_FLAG_UNCACHED(1 << 17) > #define TTM_PL_FLAG_WC (1 << 18) > +#define TTM_PL_FLAG_CONTIGUOUS (1 << 19) The value on this line doesn't line up, because it uses a tab instead of spaces. -- Earthling Michel Dänzer | http://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: [PATCH 1/6] drm/ttm: cleanup and optimize ttm_bo_mem_compat
On 29/03/17 09:55 PM, Christian König wrote:
> From: Christian König <christian.koe...@amd.com>
>
> No need to implement the same logic twice. Also check if the busy placements
> are identical to the already scanned placements before checking them.
>
> Signed-off-by: Christian König <christian.koe...@amd.com>
[...]
> @@ -1077,6 +1065,23 @@ bool ttm_bo_mem_compat(struct ttm_placement *placement,
> (*new_flags & mem->placement & TTM_PL_MASK_MEM))
> return true;
> }
> + return false;
> +}
> +
> +bool ttm_bo_mem_compat(struct ttm_placement *placement,
> +struct ttm_mem_reg *mem,
> +uint32_t *new_flags)
> +{
> + if (ttm_bo_places_compat(placement->placement, placement->num_placement,
> + mem, new_flags))
> + return true;
> +
> + if ((placement->busy_placement != placement->placement ||
> + placement->num_busy_placement != placement->num_placement) &&
placement->num_busy_placement > placement->num_placement) &&
?
--
Earthling Michel Dänzer | http://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: [PATCH 2/6] drm/ttm: add io_mem_pfn callback
On 29/03/17 09:55 PM, Christian König wrote: > From: Christian König <christian.koe...@amd.com> > > This allows the driver to handle io_mem mappings on their own. > > Signed-off-by: Christian König <christian.koe...@amd.com> Reviewed-by: Michel Dänzer <michel.daen...@amd.com> -- Earthling Michel Dänzer | http://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: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"
On 28/03/17 08:00 PM, Julien Isorce wrote: > > On 28 March 2017 at 10:36, Michel Dänzer <mic...@daenzer.net > <mailto:mic...@daenzer.net>> wrote: > > On 28/03/17 05:24 PM, Julien Isorce wrote: > > Hi Michel, > > > > About the hard lockup, I noticed that I cannot have it with the > > following conditions: > > > > 1. soft lockup fix (the 0->i change which avoids infinite loop) > > 2. Your suggestion: (!(rbo->flags & RADEON_GEM_CPU_ACCESS) > > 3. radeon.gartsize=512 radeon.vramlimit=1024 (any other values above do > > not help, for example (1024, 1024) or (1024, 2048)) > > > > Without 1 and 2, but with 3, our test reproduces the soft lockup (just > > discovered few days ago). > > Without 3 (and with or without 1., 2.), our test reproduces the hard > > lockup which one does not give any info in kern.log (sometimes some NUL > > ^@ characters but not always). > > What exactly does "hard lockup" mean? What are the symptoms? > > > Screens are frozen, cannot ssh, no mouse/keyboard, no kernel panic. > Requires hard reboot. > After reboot, nothing in /var/crash, nothing in /sys/fs/pstore, nothing > in kern.log except sometimes some nul characters ^@. Does it still respond to ping when it's hung? > Using a serial console did not show additional debug messages. kgdb was > not useful but probably worth another attempt. Right. Anyway, I'm afraid it sounds like it's probably not directly related to the issue I was thinking of for my previous test patch or other similar ones I was thinking of writing. -- Earthling Michel Dänzer | http://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: [PATCH v2] drm/amdgpu: Fail fb creation from imported dma-bufs. (v2)
On 29/03/17 01:02 PM, r...@ubuntu.com wrote:
> From: Christopher James Halse Rogers <christopher.halse.rog...@canonical.com>
>
> Any use of the framebuffer will migrate it to VRAM, which is not sensible for
> an imported dma-buf.
>
> v2: Use DRM_DEBUG_KMS to prevent userspace accidentally spamming dmesg.
>
> Signed-off-by: Christopher James Halse Rogers
> <christopher.halse.rog...@canonical.com>
> CC: amd-gfx@lists.freedesktop.org
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 39fc388f222a..2f2e9b5c8a6a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -612,6 +612,12 @@ amdgpu_user_framebuffer_create(struct drm_device *dev,
> return ERR_PTR(-ENOENT);
> }
>
> + /* Handle is imported dma-buf, so cannot be migrated to VRAM for
> scanout */
> + if (obj->import_attach) {
> + DRM_DEBUG_KMS("Cannot create framebuffer from imported
> dma_buf\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> amdgpu_fb = kzalloc(sizeof(*amdgpu_fb), GFP_KERNEL);
> if (amdgpu_fb == NULL) {
> drm_gem_object_unreference_unlocked(obj);
>
This patch and v2 of patch 5 are
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling Michel Dänzer | http://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: [PATCH 3/6] drm/amdgpu: Fail fb creation from imported dma-bufs.
On 29/03/17 09:27 AM, r...@ubuntu.com wrote:
> From: Christopher James Halse Rogers <christopher.halse.rog...@canonical.com>
>
> Any use of the framebuffer will migrate it to VRAM, which is not sensible for
> an imported dma-buf.
>
> Signed-off-by: Christopher James Halse Rogers
> <christopher.halse.rog...@canonical.com>
> CC: amd-gfx@lists.freedesktop.org
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 39fc388f222a..e7c3cc5b7d62 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -612,6 +612,12 @@ amdgpu_user_framebuffer_create(struct drm_device *dev,
> return ERR_PTR(-ENOENT);
> }
>
> + /* Handle is imported dma-buf, so cannot be migrated to VRAM for
> scanout */
Newer APUs support scanout from GTT, though they still impose some
restrictions which will probably not be satisfied in general by BOs
imported from other drivers. So this is probably okay for now.
> + if (obj->import_attach) {
> + dev_err(>pdev->dev, "Cannot create framebuffer from
> imported dma_buf\n");
This should probably be something like DRM_DEBUG, so userspace can't
spam dmesg by default. Same for patch 5.
> + return ERR_PTR(-EINVAL);
> + }
> +
> amdgpu_fb = kzalloc(sizeof(*amdgpu_fb), GFP_KERNEL);
> if (amdgpu_fb == NULL) {
> drm_gem_object_unreference_unlocked(obj);
>
--
Earthling Michel Dänzer | http://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: [PATCH 4/6] drm/amd/amdgpu: Pin bos from imported dma-bufs to GTT.
On 29/03/17 09:27 AM, r...@ubuntu.com wrote: > From: Christopher James Halse Rogers <christopher.halse.rog...@canonical.com> > > Attempting to migrate the bo will break the sharing of the buffer. > > Signed-off-by: Christopher James Halse Rogers > <christopher.halse.rog...@canonical.com> > CC: amd-gfx@lists.freedesktop.org > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c > index 3826d5aea0a6..3c84ec5c6ac8 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c > @@ -74,6 +74,17 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev, > if (ret) > return ERR_PTR(ret); > > + /* Imported bo must be pinned to GTT, as moving it breaks sharing */ > + ret = amdgpu_bo_reserve(bo, false); > + if (ret) > + return ERR_PTR(ret); > + > + ret = amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT, NULL); > + if (ret) > + return ERR_PTR(ret); > + > + amdgpu_bo_unreserve(bo); > + > bo->prime_shared_count = 1; > return >gem_base; > } > Thanks for beating me to this! :) This patch and patch 6 are Reviewed-by: Michel Dänzer <michel.daen...@amd.com> -- Earthling Michel Dänzer | http://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: [PATCH 4/6] drm/amd/amdgpu: Pin bos from imported dma-bufs to GTT.
On 29/03/17 04:14 PM, Christian König wrote: > Am 29.03.2017 um 02:27 schrieb r...@ubuntu.com: >> From: Christopher James Halse Rogers >> <christopher.halse.rog...@canonical.com> >> >> Attempting to migrate the bo will break the sharing of the buffer. >> >> Signed-off-by: Christopher James Halse Rogers >> <christopher.halse.rog...@canonical.com> >> CC: amd-gfx@lists.freedesktop.org > > NAK on this one and the radeon version. > > We can't migrate the buffers to VRAM, but we shouldn't pin it either > cause that will lock down the GTT space used for it. Ah, good point, didn't think of that. > Instead you should modify amdgpu_bo_pin() and fail if anybody tries to > migrate a BO which has prime_shared_count != 0 to VRAM (you migth need > to add this for radeon). This would also need to be checked in the AMDGPU_GEM_OP_SET_PLACEMENT case of amdgpu_gem_op_ioctl, otherwise userspace can change prefered_domains to AMDGPU_GEM_DOMAIN_VRAM, and using the BO for GPU operations may move it to VRAM. Or maybe there's a central place which can catch both of these cases (and any others). -- Earthling Michel Dänzer | http://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: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"
On 29/03/17 06:07 PM, Christian König wrote: > Am 29.03.2017 um 10:59 schrieb Michel Dänzer: >> On 28/03/17 08:00 PM, Julien Isorce wrote: >>> On 28 March 2017 at 10:36, Michel Dänzer <mic...@daenzer.net >>> <mailto:mic...@daenzer.net>> wrote: >>> >>> On 28/03/17 05:24 PM, Julien Isorce wrote: >>> > Hi Michel, >>> > >>> > About the hard lockup, I noticed that I cannot have it with the >>> > following conditions: >>> > >>> > 1. soft lockup fix (the 0->i change which avoids infinite loop) >>> > 2. Your suggestion: (!(rbo->flags & RADEON_GEM_CPU_ACCESS) >>> > 3. radeon.gartsize=512 radeon.vramlimit=1024 (any other values >>> above do >>> > not help, for example (1024, 1024) or (1024, 2048)) >>> > >>> > Without 1 and 2, but with 3, our test reproduces the soft >>> lockup (just >>> > discovered few days ago). >>> > Without 3 (and with or without 1., 2.), our test reproduces >>> the hard >>> > lockup which one does not give any info in kern.log (sometimes >>> some NUL >>> > ^@ characters but not always). >>> >>> What exactly does "hard lockup" mean? What are the symptoms? >>> >>> >>> Screens are frozen, cannot ssh, no mouse/keyboard, no kernel panic. >>> Requires hard reboot. >>> After reboot, nothing in /var/crash, nothing in /sys/fs/pstore, nothing >>> in kern.log except sometimes some nul characters ^@. >> Does it still respond to ping when it's hung? >> >> >>> Using a serial console did not show additional debug messages. kgdb was >>> not useful but probably worth another attempt. >> Right. >> >> Anyway, I'm afraid it sounds like it's probably not directly related to >> the issue I was thinking of for my previous test patch or other similar >> ones I was thinking of writing. > > Yeah, agree. > > Additional to that a complete crash where you don't even get anything > over serial console is rather unlikely to be cause by something an > application can do directly. > > Possible causes are more likely power management or completely messing > up a bus system. Have you tried disabling dpm as well? Might also be worth trying the amdgpu kernel driver instead of radeon, not sure how well the former currently works with Cape Verde though. -- Earthling Michel Dänzer | http://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: Plan: BO move throttling for visible VRAM evictions
On 27/03/17 04:53 PM, Zhou, David(ChunMing) wrote: > For APU special case, can we prevent eviction happening between VRAM <> > GTT? We can, if we can close the performance gap between VRAM and GTT. We measured around 30% gap a while ago, though right now I'm only measuring ~5%, but the test system has slower RAM now (still dual channel though). -- Earthling Michel Dänzer | http://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: Plan: BO move throttling for visible VRAM evictions
On 27/03/17 07:29 PM, Marek Olšák wrote: > On Mar 27, 2017 9:35 AM, "Michel Dänzer" <mic...@daenzer.net > <mailto:mic...@daenzer.net>> wrote: > > On 25/03/17 01:33 AM, Marek Olšák wrote: > > Hi, > > > > I'm sharing this idea here, because it's something that has been > > decreasing our performance a lot recently, for example: > > > > http://openbenchmarking.org/prospect/1703011-RI-RADEONDIR06/7b7668cfc109d1c3dc27e871c8aea71ca13f23fa > > <http://openbenchmarking.org/prospect/1703011-RI-RADEONDIR06/7b7668cfc109d1c3dc27e871c8aea71ca13f23fa> > > > > I think the problem there is that Mesa git started uploading > > descriptors and uniforms to VRAM, which helps when TC L2 has a low > > hit/miss ratio, but the performance can randomly drop by an order of > > magnitude. I've heard rumours that kernel 4.11 has an improved > > allocator that should perform better, but the situation is still far > > from ideal. > > > > AMD CPUs and APUs will hopefully suffer less, because we can resize > > the visible VRAM with the help of our CPU hw specs, but Intel CPUs > > will remain limited to 256 MB. The following plan describes how to do > > throttling for visible VRAM evictions. > > > > > > 1) Theory > > > > Initially, the driver doesn't care about where buffers are in VRAM, > > because VRAM buffers are only moved to visible VRAM on CPU page faults > > (when the CPU touches the buffer memory but the memory is in the > > invisible part of VRAM). When it happens, > > amdgpu_bo_fault_reserve_notify is called, which moves the buffer to > > visible VRAM, and the app continues. amdgpu_bo_fault_reserve_notify > > also marks the buffer as contiguous, which makes memory fragmentation > > worse. > > > > I verified this with DiRT Rally where amdgpu_bo_fault_reserve_notify > > was much higher in a CPU profiler than anything else in the kernel. > > > > > > 2) Monitoring via Gallium HUD > > > > We need to expose 2 kernel counters via the INFO ioctl and display > > those via Gallium HUD: > > - The number of VRAM CPU page faults. (the number of calls to > > amdgpu_bo_fault_reserve_notify). > > - The number of bytes moved by ttm_bo_validate inside > > amdgpu_bo_fault_reserve_notify. > > > > This will help us observe what exactly is happening and fine-tune the > > throttling when it's done. > > > > > > 3) Solution > > > > a) When amdgpu_bo_fault_reserve_notify is called, record the fact. > > (amdgpu_bo::had_cpu_page_fault = true) > > > > b) Monitor the MB/s rate at which buffers are moved by > > amdgpu_bo_fault_reserve_notify. If we get above a specific threshold, > > don't move the buffer to visible VRAM. Move it to GTT instead. Note > > that moving to GTT can be cheaper, because moving to visible VRAM is > > likely to evict a lot of buffers there and unmap them from the CPU, > > FWIW, this can be avoided by only setting GTT in busy_placement. Then > TTM will only move the BO to visible VRAM if that can be done without > evicting anything from there. > > > > but moving to GTT shouldn't evict or unmap anything. > > > > c) When we get into the CS ioctl and a buffer has had_cpu_page_fault, > > it can be moved to VRAM if: > > - the GTT->VRAM move rate is low enough to allow it (this is the > > existing throttling mechanism) > > - the visible VRAM move rate is low enough that we will be OK with > > another CPU page fault if it happens. > > Some other ideas that might be worth trying: > > Evicting BOs to GTT instead of moving them to CPU accessible VRAM in > principle in some cases (e.g. for all BOs except those with > AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED) or even always. > > > I've tried this and it made things even worse. What exactly did you try? -- Earthling Michel Dänzer | http://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: [PATCH] Fix a misspelling of 'acceleration' in amdgpu_kms.c
On 25/03/17 10:38 PM, Nicholas Molloy wrote:
> ---
> src/amdgpu_kms.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/amdgpu_kms.c b/src/amdgpu_kms.c
> index 4821e93..c4ac90d 100644
> --- a/src/amdgpu_kms.c
> +++ b/src/amdgpu_kms.c
> @@ -1796,7 +1796,7 @@ Bool AMDGPUScreenInit_KMS(SCREEN_INIT_ARGS_DECL)
> xf86DrvMsg(pScrn->scrnIndex, X_INFO, "3D acceleration
> disabled\n");
> xf86DrvMsg(pScrn->scrnIndex, X_INFO, "2D acceleration
> disabled\n");
> } else {
> - xf86DrvMsg(pScrn->scrnIndex, X_INFO, "2D and 3D cceleration
> disabled\n");
> + xf86DrvMsg(pScrn->scrnIndex, X_INFO, "2D and 3D acceleration
> disabled\n");
> }
>
> /* Init DPMS */
>
Reviewed and pushed, thanks!
P.S. In the future, please include your Signed-off-by tag in patches
that you want to be applied, in particular if they're more than one-liners.
--
Earthling Michel Dänzer | http://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: [PATCH] drm/radeon: Override fpfn for all VRAM placements in radeon_evict_flags
On 27/03/17 06:33 PM, Julien Isorce wrote: > Hi Michel, > > Great ! Would you mind to just add a note to mention that the infinite > loop actually happens in ttm_bo_mem_force_space ? Thx! I'm afraid it might be too late, as I already pushed the fix to the amd-staging-4.9 branch. I guess Alex could still add it before he includes the fix in a pull request though. -- Earthling Michel Dänzer | http://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: Plan: BO move throttling for visible VRAM evictions
On 28/03/17 12:50 PM, zhoucm1 wrote:
> On 2017年03月28日 10:40, Michel Dänzer wrote:
>> On 27/03/17 04:53 PM, Zhou, David(ChunMing) wrote:
>>> For APU special case, can we prevent eviction happening between VRAM
>>> <> GTT?
>> We can, if we can close the performance gap between VRAM and GTT. We
>> measured around 30% gap a while ago, though right now I'm only measuring
>> ~5%, but the test system has slower RAM now (still dual channel though).
> My impression VRAM and GTT have no much difference for APU case, if I'm
> wrong, pls correct me.
The Mesa patch below makes radeonsi use mostly GTT instead of mostly
VRAM, and slows down Unigine Valley by about 5% on my desktop Kaveri.
You can try it for yourself.
diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
b/src/gallium/drivers/radeon/r600_buffer_common.c
index da6f0206d7..47661cab76 100644
--- a/src/gallium/drivers/radeon/r600_buffer_common.c
+++ b/src/gallium/drivers/radeon/r600_buffer_common.c
@@ -175,9 +175,11 @@ void r600_init_resource_fields(struct r600_common_screen
*rscreen,
* placements even with a low amount of stolen VRAM.
*/
if (!rscreen->info.has_dedicated_vram &&
- (rscreen->info.drm_major < 3 || rscreen->info.drm_minor < 6) &&
- res->domains == RADEON_DOMAIN_VRAM)
- res->domains = RADEON_DOMAIN_VRAM_GTT;
+ res->domains == RADEON_DOMAIN_VRAM &&
+ !(res->b.b.bind & PIPE_BIND_SCANOUT)) {
+ res->domains = RADEON_DOMAIN_GTT;
+ res->flags |= RADEON_FLAG_GTT_WC;
+ }
if (rscreen->debug_flags & DBG_NO_WC)
res->flags &= ~RADEON_FLAG_GTT_WC;
--
Earthling Michel Dänzer | http://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: [PATCH 4/6] drm/amdgpu: drop alpha support
On 30/03/17 10:09 PM, Alex Deucher wrote: > On Thu, Mar 30, 2017 at 2:39 AM, Michel Dänzer <mic...@daenzer.net> wrote: >> On 29/03/17 09:55 PM, Christian König wrote: >>> From: Christian König <christian.koe...@amd.com> >>> >>> We will probably never see this combination. >>> >>> Signed-off-by: Christian König <christian.koe...@amd.com> >>> --- >>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 25 - >>> 1 file changed, 25 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >>> index 7bf5ba7..524abca 100644 >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >>> @@ -538,31 +538,6 @@ static int amdgpu_ttm_io_mem_reserve(struct >>> ttm_bo_device *bdev, struct ttm_mem_ >>> return -EINVAL; >>> mem->bus.base = adev->mc.aper_base; >>> mem->bus.is_iomem = true; >>> -#ifdef __alpha__ >>> - /* >>> - * Alpha: use bus.addr to hold the ioremap() return, >>> - * so we can modify bus.base below. >>> - */ >>> - if (mem->placement & TTM_PL_FLAG_WC) >>> - mem->bus.addr = >>> - ioremap_wc(mem->bus.base + mem->bus.offset, >>> -mem->bus.size); >>> - else >>> - mem->bus.addr = >>> - ioremap_nocache(mem->bus.base + >>> mem->bus.offset, >>> - mem->bus.size); >>> - if (!mem->bus.addr) >>> - return -ENOMEM; >>> - >>> - /* >>> - * Alpha: Use just the bus offset plus >>> - * the hose/domain memory base for bus.base. >>> - * It then can be used to build PTEs for VRAM >>> - * access, as done in ttm_bo_vm_fault(). >>> - */ >>> - mem->bus.base = (mem->bus.base & 0x0UL) + >>> - adev->ddev->hose->dense_mem_base; >>> -#endif >>> break; >>> default: >>> return -EINVAL; >>> >> >> Maybe leave an #error line, or make AMDGPU depend on !ALPHA in Kconfig, >> to prevent somebody from trying this driver on an Alpha machine, and it >> mysteriously failing due to the lack of this? >> >> Either way, >> >> Acked-by: Michel Dänzer <michel.daen...@amd.com> > > Does this code even work on alpha (or compile for that matter)? If it doesn't compile, that makes it obvious to somebody who tries compiling it on Alpha that there's something wrong. Whereas if we just remove it, the driver might build but probably won't work. -- Earthling Michel Dänzer | http://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: Plan: BO move throttling for visible VRAM evictions
On 30/03/17 07:03 PM, Michel Dänzer wrote: > On 25/03/17 01:33 AM, Marek Olšák wrote: >> Hi, >> >> I'm sharing this idea here, because it's something that has been >> decreasing our performance a lot recently, for example: >> http://openbenchmarking.org/prospect/1703011-RI-RADEONDIR06/7b7668cfc109d1c3dc27e871c8aea71ca13f23fa > > The attached proof-of-concept patch (on top of Christian's "CPU mapping > of split VRAM buffers" series, ported from radeon) results in 145.05 fps > on my Tonga. I get the same result without my or Christian's patches though, with 4.11 based DRM or amd-staging-4.9. So I guess I just can't reproduce the problem with this test. Are there any other tests for it? -- Earthling Michel Dänzer | http://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
[ANNOUNCE] xf86-video-ati 7.9.0
I'm pleased to announce the 7.9.0 release of xf86-video-ati, the Xorg driver for ATI/AMD Radeon GPUs supported by the radeon kernel driver. This release supports xserver versions 1.10-1.19. NOTE for packagers: Please ship the new 10-radeon.conf file in the same package as radeon_drv.so. Highlights: * Allow TearFree to be toggled at runtime via an RandR output property "TearFree". The xorg.conf option "TearFree" now controls the default value of the output properties. * Use glamor by default for 2D acceleration with >= R600 and Xorg >= 1.18.3. * Ship 10-radeon.conf xorg.conf.d snippet for Xorg >= 1.16, so that the radeon driver can be loaded automatically even when the ati wrapper driver isn't installed. * Support loading the amdgpu driver from the ati wrapper driver. * Use DRM render nodes for DRI3 clients when available. Plus many other improvements and fixes. Thanks to everybody who contributed to this release in any way! Emil Velikov (1): autogen.sh: use quoted string variables Jammy Zhou (1): Use render node for DRI3 if available Jochen Rollwagen (3): fix build for xserver < 1.13 Calculate log base 2 in radeon.h based on clz for all platforms Fix build for XServer 1.13 Michel Dänzer (38): Post-release version bump Use DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags when available Enable glamor by default with >= R600 and Xorg >= 1.18.3 Don't install Flush/EventCallback for GPU screens Pass fb_id into drmmode_page_flip_target_absolute/relative Add radeon_is_gpu_screen helper Take current scanout_id into account everywhere involved with TearFree Fix radeon_scanout_extents_intersect for GPU screens Call ValidateGC after ChangeClip in radeon_sync_scanout_pixmaps Call radeon_drm_abort_entry on failure to flip to a scanout pixmap Simplify drmmode_handle_uevents Pass pitch from drmmode_crtc_scanout_allocate to drmmode_create_bo_pixmap .editorconfig: src/ati.c only uses spaces for indentation ati: Support loading the amdgpu driver from the ati wrapper Add 10-radeon.conf xorg.conf.d snippet Enable tiling by default with glamor on PALM Don't handle Option "SwapbuffersWait" at all with glamor Fix flip event data leak if calloc or drmModeAddFB fails Don't destroy current FB if drmModeAddFB fails Factor out radeon_prime_dirty_to_crtc helper Factor out drmmode_crtc_scanout_update helper Allow toggling TearFree at runtime via output property Use drmmode_crtc_scanout_free in drmmode_fini present: Only call drmModeRmFB after setting modes for unflip present: Wait for screen pixmap BO idle before setting modes for unflip Call drmmode_crtc_scanout_create in drmmode_crtc_shadow_allocate as well Fold drmmode_crtc_scanout_allocate into drmmode_crtc_scanout_create Handle rotation in the driver also with Xorg 1.12-1.18 present: Also flush before using a flip to unflip present: Use async flip for unflip if possible present: Flush before flipping Fix bogus indentation Call drmmode_set_desired_modes from a WindowExposures hook Move DPMS check from radeon_scanout_do_update to radeon_scanout_flip Don't call radeon_cs_flush_indirect & radeon_bo_wait in drmmode_copy_fb Skip some initialization steps for GPU screens Pass TRUE to drmmode_set_desired_modes the first time for GPU screens Bump version for 7.9.0 release Mihail Konev (1): autogen: add default patch prefix Peter Hutterer (1): autogen.sh: use exec instead of waiting for configure to finish jimqu (1): udev_monitor_receive_device() will block when hotplug monitor git tag: xf86-video-ati-7.9.0 https://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-7.9.0.tar.bz2 MD5: bf3dfdae23879bdc0c8a7b955572ad90 xf86-video-ati-7.9.0.tar.bz2 SHA1: 86ee6db1d7dcdeb1948aeb7965be8102c18be46b xf86-video-ati-7.9.0.tar.bz2 SHA256: 3cad872e6330afb1707da11e4e959e6887ebe5bcd81854b4d2e496c52c059875 xf86-video-ati-7.9.0.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-7.9.0.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-7.9.0.tar.gz MD5: 4dd41ed1ad2f86f1b3e0b18e28f203fc xf86-video-ati-7.9.0.tar.gz SHA1: 70a8cee6da49738b7769f82e8130e9463825e3a1 xf86-video-ati-7.9.0.tar.gz SHA256: e9580679e189be6edfd308ccc14588d1cac04e6b79a21f5c5061f4fef4191349 xf86-video-ati-7.9.0.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-7.9.0.tar.gz.sig -- Earthling Michel Dänzer | http://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
[ANNOUNCE] xf86-video-amdgpu 1.3.0
I'm pleased to announce the 1.3.0 release of xf86-video-amdgpu, the Xorg driver for AMD Radeon GPUs supported by the amdgpu kernel driver. This release supports xserver versions 1.10-1.19. Highlights: * Allow TearFree to be toggled at runtime via an RandR output property "TearFree". The xorg.conf option "TearFree" now controls the default value of the output properties. * Use libdrm_amdgpu functionality to determine the GPU marketing name, remove corresponding tables from this driver. * Use DRM render nodes for DRI3 clients when available. Plus many other improvements and fixes. Thanks to everybody who contributed to this release in any way! Emil Velikov (1): autogen.sh: use quoted string variables Hans De Goede (1): amdgpu_probe: Do not close server managed drm fds Jammy Zhou (1): Use render node for DRI3 if available Michel Dänzer (44): Post-release version bump Move struct amdgpu_gpu_info out of amdgpu_get_tile_config Use family information from libdrm_amdgpu / kernel Stop using generated amdgpu_device_match Remove amdpciids.h Stop using AMDGPUPciChipsets Stop using AMDGPU(Unique)Chipsets Remove generated header files Use DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags when available Make libdrm >= 2.4.72 requirement explicit Don't install Flush/EventCallback for GPU screens Add amdgpu_is_gpu_screen helper Take current scanout_id into account everywhere involved with TearFree Fix amdgpu_scanout_extents_intersect for GPU screens Call ValidateGC after ChangeClip in amdgpu_sync_scanout_pixmaps Call amdgpu_drm_abort_entry on failure to flip to a scanout pixmap Simplify drmmode_handle_uevents Pass pitch from drmmode_crtc_scanout_allocate to drmmode_create_bo_pixmap Call drmmode_crtc_scanout_create in drmmode_crtc_shadow_allocate as well Fold drmmode_crtc_scanout_allocate into drmmode_crtc_scanout_create Handle rotation in the driver also with Xorg 1.12-1.18 Fix flip event data leak if calloc or drmModeAddFB fails Don't destroy current FB if drmModeAddFB fails Factor out amdgpu_prime_dirty_to_crtc helper Factor out drmmode_crtc_scanout_update helper Allow toggling TearFree at runtime via output property Use drmmode_crtc_scanout_free in drmmode_fini present: Only call drmModeRmFB after setting modes for unflip present: Wait for GPU idle before setting modes for unflip present: Also flush before using a flip to unflip present: Use async flip for unflip if possible present: Flush before flipping Call drmmode_set_desired_modes from a WindowExposures hook Move DPMS check from amdgpu_scanout_do_update to amdgpu_scanout_flip Don't call amdgpu_glamor_flush in drmmode_copy_fb Don't use pScrn->is_gpu in AMDGPUCreateScreenResources_KMS Use local implementation of RegionDuplicate for older xserver Only define transform_region for XF86_CRTC_VERSION >= 4 glamor: Don't flush in BlockHandler with Xorg >= 1.19 Refactor amdgpu_kernel_close_fd helper glamor: Use glamor_finish when available Skip some initialization steps for GPU screens Pass TRUE to drmmode_set_desired_modes the first time for GPU screens Bump version for 1.3.0 release Mihail Konev (1): autogen: add default patch prefix Peter Hutterer (1): autogen.sh: use exec instead of waiting for configure to finish jimqu (1): udev_monitor_receive_device() will block when hotplug monitor git tag: xf86-video-amdgpu-1.3.0 https://xorg.freedesktop.org/archive/individual/driver/xf86-video-amdgpu-1.3.0.tar.bz2 MD5: e2ee9e16ffbd45ebda68a7ff638a04f2 xf86-video-amdgpu-1.3.0.tar.bz2 SHA1: 7b89fe6e22e6739257c0f03c9f034c9c579a8bce xf86-video-amdgpu-1.3.0.tar.bz2 SHA256: c1630f228938be949273f72b29ae70822dde064ad79c3ccb14d55f427e3f4e70 xf86-video-amdgpu-1.3.0.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/driver/xf86-video-amdgpu-1.3.0.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/driver/xf86-video-amdgpu-1.3.0.tar.gz MD5: c0c3d95fb2865008f1347bf9f38c0f44 xf86-video-amdgpu-1.3.0.tar.gz SHA1: cc5766dd9a7851ef18f271898054f31e9cd2 xf86-video-amdgpu-1.3.0.tar.gz SHA256: 05f4a1bbd3a0653551cb9871a554ec4b84c35d00a8fb101f772fc154253eb1e0 xf86-video-amdgpu-1.3.0.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/driver/xf86-video-amdgpu-1.3.0.tar.gz.sig -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer signature.asc Description: OpenPGP digital signature ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 0/1] Add infrastructure for handling underlay planes
On 17/03/17 04:51 PM, Shirish S wrote: > I would like to use this letter to explain what this patche does. > (Note its tested on Carrizo & Stoney) > > * Firstly it decouples the per-plane per-crtc design, as a result, > now with the unit test called as 'modetest' we can see 3 planes > and 2 crtc's compared to what it was 2 planes for 2 crtc's w/o > this patch. > * I have introduced new variable of max_surfaces to the public > caps structure that can be used for all asic's in future as well. > Basic understanding being: > max_streams == crtc > link_count == connector > max_surfaces== plane > * The drm device initialization loops now for number of surfaces > instead of stream. > * Have taken care that it won't break other asic's > * Am able to reach __setplane_internal() in drm_plane.c which > does the final update to plane, had to put a sanity patch there > as we do not have update_plane() and disable_plane() implemented >--> also testifies, that now we are able to handle planes with > this patch. > * The YUV formats supported right now are default, will refine it > going further. Sounds nice. BTW, are you aware of the KMS tests in the intel-gpu-tools tree (https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/)? There should be much more comprehensive tests for this functionality there compared to modetest. -- Earthling Michel Dänzer | http://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: [PATCH 1/4] amdgpu: add new VA operations CLEAR and REPLACE
On 17/03/17 09:16 AM, Zhang, Jerry wrote: > > Thanks for your reminder. > > I always keep it in mind. [...] > *From:*Koenig, Christian > >> fell free to use this patch internally, but the upstream copy of >> include/drm/amdgpu_drm.h should be updated when the kernel change land. >> >> Emil usually points out how to do this correctly whenever we try to add >> changes manually. See include/drm/README in the libdrm tree. -- Earthling Michel Dänzer | http://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: [PATCH libdrm 2/7] amdgpu: update amdgpu_drm.h for Vega10
On 22/03/17 06:46 AM, Marek Olšák wrote: > On Tue, Mar 21, 2017 at 10:27 PM, Nicolai Hähnle <nhaeh...@gmail.com> wrote: >> In the past, I was told off for patches that update this file without >> following the procedure described in include/drm/README. Tbh, that procedure >> causes some annoyances. >> >> Anyway, it's definitely useful to have the patch out on the mailing list in >> any case. > > Yeah, I know the correct process and I plan to ignore it this time if > I don't get too much backlash, because the alternative > (#ifdef/#define/#endif) is probably even worse. FWIW, only AMDGPU_TILING_SET/GET need #undef, AMDGPU_TILING_SWIZZLE_MODE_SHIFT/MASK and AMDGPU_FAMILY_AI can just be #defined directly, that way the preprocessor will warn if the definitions in libdrm and Mesa end up being inconsistent for some reason. The alternative is rushing out a libdrm release and making Mesa require that, right? That doesn't seem obviously better than a handful of temporary redundant defines in Mesa, hardly justification for bypassing the normal process. -- Earthling Michel Dänzer | http://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
[PATCH xf86-video-amdgpu] manpage: Don't put "'" at the beginning of a line
From: Michel Dänzer <michel.daen...@amd.com>
It caused the whole line to be dropped.
Fixes: af0b24c1aca4 ("Allow toggling TearFree at runtime via output
property")
Reported-by: Andy Furniss <adf.li...@gmail.com>
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
man/amdgpu.man | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/man/amdgpu.man b/man/amdgpu.man
index 53bd768a1..13ffb7a27 100644
--- a/man/amdgpu.man
+++ b/man/amdgpu.man
@@ -78,8 +78,8 @@ tearing prevention using the hardware page flipping
mechanism. TearFree is
on for any CRTC associated with one or more outputs with TearFree on. Two
separate scanout buffers need to be allocated for each CRTC with TearFree
on. While TearFree is on for any CRTC, it currently prevents clients from using
-DRI page flipping. If this option is set, the default value of the property is
-'on' or 'off' accordingly. If this option isn't set, the default value of the
+DRI page flipping. If this option is set, the default value of the property
+is 'on' or 'off' accordingly. If this option isn't set, the default value of
the
property is
.B auto,
which means that TearFree is on for outputs with rotation or other RandR
--
2.11.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [ANNOUNCE] xf86-video-amdgpu 1.3.0
[ Dropping the xorg(-announce) lists ] On 17/03/17 07:12 PM, Andy Furniss wrote: > Michel Dänzer wrote: >> >> I'm pleased to announce the 1.3.0 release of xf86-video-amdgpu, > >> Highlights: >> >> * Allow TearFree to be toggled at runtime via an RandR output property >> "TearFree". The xorg.conf option "TearFree" now controls the default >> value of the output properties. > > Nice feature. Glad you like it. :) > Minor man page glitch = the line starting with 'on' in the > patch snippet below doesn't show up when viewed with man amdgpu. > > +Set the default value of the per-output 'TearFree' property, which > controls > +tearing prevention using the hardware page flipping mechanism. TearFree is > +on for any CRTC associated with one or more outputs with TearFree on. Two > +separate scanout buffers need to be allocated for each CRTC with TearFree > +on. While TearFree is on for any CRTC, it currently prevents clients > from using > +DRI page flipping. If this option is set, the default value of the > property is > +'on' or 'off' accordingly. If this option isn't set, the default value > of the > +property is > +.B auto, > +which means that TearFree is on for outputs with rotation or other RandR > +transforms, and for RandR 1.4 slave outputs, otherwise off. Ah! Thanks, I had noticed "property is property is" in the generated manpage, but totally missed that a whole line was missing in between! Fix posted for review: https://patchwork.freedesktop.org/patch/145647/ -- Earthling Michel Dänzer | http://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: Linux 4.11: Reported regressions as of Tuesday, 20176-03-14
[ Moving this sub-thread to the amd-gfx mailing list ] On 14/03/17 07:02 PM, Thorsten Leemhuis wrote: > Hi! Find below my first regression report for Linux 4.11. It lists 9 > regressions I'm currently aware of. [...] > Desc: DRM BUG while initializing cape verde (2nd card) > Repo: 2017-03-13 https://bugzilla.kernel.org/show_bug.cgi?id=194867 > Stat: n/a > Note: patch proposed by reporter I don't see any patch. Looks like the amdgpu driver has never fully initialized GDS support for SI family GPUs, and this now triggers the DRM_MM_BUG_ON which was added to drm_mm_init in 4.11. AMD folks, should this be addressed by fleshing out SI GDS support, or by completely disabling GDS initialization for SI? -- Earthling Michel Dänzer | http://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: Linux 4.11: Reported regressions as of Tuesday, 20176-03-14
On 15/03/17 04:33 PM, Christian König wrote: > Am 15.03.2017 um 02:59 schrieb Michel Dänzer: >> [ Moving this sub-thread to the amd-gfx mailing list ] >> >> On 14/03/17 07:02 PM, Thorsten Leemhuis wrote: >>> Hi! Find below my first regression report for Linux 4.11. It lists 9 >>> regressions I'm currently aware of. >> [...] >> >>> Desc: DRM BUG while initializing cape verde (2nd card) >>> Repo: 2017-03-13 https://bugzilla.kernel.org/show_bug.cgi?id=194867 >>> Stat: n/a >>> Note: patch proposed by reporter >> I don't see any patch. >> >> Looks like the amdgpu driver has never fully initialized GDS support for >> SI family GPUs, and this now triggers the DRM_MM_BUG_ON which was added >> to drm_mm_init in 4.11. >> >> AMD folks, should this be addressed by fleshing out SI GDS support, or >> by completely disabling GDS initialization for SI? > Uff, good question. IIRC GDS was significantly different between SI and > CIK in the hardware and requires pinned buffers on SI (userspace needs > to know the physical address of the buffer). > > So the current implementation most likely doesn't work as expected. > > I would say disable it for now, but keep any existing code for at least > one release. If nobody finds time to fix it properly (which is likely) > we can throw away that and move on. Any takers for 4.11? :) -- Earthling Michel Dänzer | http://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: [PATCH 0/4] [libdrm] support PRT and replace interface
On 16/03/17 06:28 PM, Christian König wrote: > Am 16.03.2017 um 10:14 schrieb Zhang, Jerry: >> >> So I prepare the patch 2 to use the input flags: >> * [PATCH 2/4] amdgpu: set va flag with input parameter > > Nicolai handled both issues by creating a new function where the BO is > optional and the flags taken into account. > > Please take a look at his patches, they are on the mailing list. Or on Patchwork: https://patchwork.freedesktop.org/project/amd-xorg-ddx/patches/?submitter=15673 Speaking of Patchwork, it's accumulating a lot of stale patches. Everybody submitting patches, please at least periodically go through your patches and change their state as appropriate. -- Earthling Michel Dänzer | http://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: [PATCH 2/2] drm/amd/sched: add schuduling policy
On 17/03/17 11:35 AM, Zhou, David(ChunMing) wrote: > Hi Christian, Andres, > > I understand your mean, especially high priority queue from Andres is > for VR, which is liking an engine to himself, but our scheduler is a > generic thing, which is used by multiple case. From scheduler > perspective, scheduling policy is popular, e.g. CPU scheduler, it > provides different time piece for different priority queue, high > priority has long time to execute, low has short time, but everyone > has the chance to run, just sooner or later. The CPU scheduler supports the SCHED_FIFO scheduling policy, which doesn't preempt a running process. It's only available to root. -- Earthling Michel Dänzer | http://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: [ANNOUNCE] xf86-video-amdgpu 1.3.0
On 17/03/17 11:32 AM, Zhang, Jerry wrote: > Hi Michel, > >> * Use libdrm_amdgpu functionality to determine the GPU marketing name, >> remove corresponding tables from this driver. > > Could you elaborate it? > I'd like to know how DDX(amdgpu) get the marketing name. It uses libdrm_amdgpu's amdgpu_get_marketing_name API. -- Earthling Michel Dänzer | http://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: [PATCH 1/3] drm/radeon: Make CIK support in Radeon conditional (v2)
On 11/04/17 03:13 AM, Felix Kuehling wrote: > On 17-04-09 09:28 PM, Michel Dänzer wrote: >> On 10/04/17 09:56 AM, Michel Dänzer wrote: >>> On 08/04/17 05:15 AM, Felix Kuehling wrote: >>>> Advertise CIK PCI IDs only when they are not supported by amdgpu. >>>> Use the CONFIG_DRM_AMDGPU_CIK to check so that a single option in >>>> the kernel config keeps both drivers in sync. >>>> >>>> This is the simplest possible change. A more complete solution >>>> may want to conditionally disable more CIK-specific code in the >>>> Radeon driver. >>>> >>>> v2: Add CONFIG_DRM_RADEON_FORCE_CIK option >>>> >>>> Signed-off-by: Felix Kuehling <felix.kuehl...@amd.com> >>> I don't think this is good enough a solution. >> To elaborate, my main objection is that people who still want to be able >> to use the radeon driver for CIK/SI GPUs with CONFIG_DRM_AMDGPU_CIK >> enabled have to enable the new CONFIG_DRM_RADEON_FORCE_CIK/SI option, >> and then they're merely back to square one, in the current situation >> where it's not clearly defined which driver will end up being used for >> such GPUs. > > So what's the usage model here? I think the situation that both AMDGPU > and Radeon support CIK is for developers only. "Normal end users" would > never be in this situation. I agree in the long term, but for now, there's still too many bugs which force users to use one or the other driver. Since this patch would require distros to choose one driver for all of their users, with no way to override at runtime, it would probably result in bad user experiences and/or a support nightmare at least in the short term. > For developers, Christian is OK with having just a compile time option, > and probably choosing the driver by loading the right module manually. > You want to have a boot time kernel option. Note that I'm okay with an inconvenient mechanism for choosing the driver at runtime, as long as there is one. The important thing is to fix the current situation where it's essentially up to chance which driver ends up driving a GPU supported by both. -- Earthling Michel Dänzer | http://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: [PATCH] drm: Harmonize CIK ASIC support in radeon and amdgpu (v2)
On 11/04/17 08:29 AM, Felix Kuehling wrote: > I tested this with Hawaii on the KFD branch and > DRM_CIK_BOTH_DEFAULT_AMDGPU. Both modules get loaded, but radeon doesn't > initialize the device. Amdgpu works with kfdtest. Did radeon print the "CIK support disabled by module param" message? -- Earthling Michel Dänzer | http://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: [PATCH] drm/amdgpu:fix race condition
On 10/04/17 07:24 PM, Monk Liu wrote:
>
> struct drm_amdgpu_wait_cs_in {
> - /** Command submission handle */
> + /* Command submission handle
Any particular reason for dropping the /** comment opening?
> + * handle equals 0 means none to wait for
This line and the following lines are indented incorrectly (9 spaces,
should be 1 tab + 1 space).
> + * handle equal ~0ull meanas wait for the latest sequence number
> + */
Typo: "meanas" (vi(m) accident? :)
--
Earthling Michel Dänzer | http://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: [PATCH 4/6] drm/amdgpu: drop alpha support
On 31/03/17 04:09 PM, Christian König wrote: > Am 31.03.2017 um 03:07 schrieb Michel Dänzer: >> On 30/03/17 10:09 PM, Alex Deucher wrote: >>> On Thu, Mar 30, 2017 at 2:39 AM, Michel Dänzer <mic...@daenzer.net> >>> wrote: >>>> On 29/03/17 09:55 PM, Christian König wrote: >>>>> From: Christian König <christian.koe...@amd.com> >>>>> >>>>> We will probably never see this combination. >>>>> >>>>> Signed-off-by: Christian König <christian.koe...@amd.com> >>>>> --- >>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 25 >>>>> - >>>>> 1 file changed, 25 deletions(-) >>>>> >>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >>>>> index 7bf5ba7..524abca 100644 >>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >>>>> @@ -538,31 +538,6 @@ static int amdgpu_ttm_io_mem_reserve(struct >>>>> ttm_bo_device *bdev, struct ttm_mem_ >>>>>return -EINVAL; >>>>>mem->bus.base = adev->mc.aper_base; >>>>>mem->bus.is_iomem = true; >>>>> -#ifdef __alpha__ >>>>> - /* >>>>> - * Alpha: use bus.addr to hold the ioremap() return, >>>>> - * so we can modify bus.base below. >>>>> - */ >>>>> - if (mem->placement & TTM_PL_FLAG_WC) >>>>> - mem->bus.addr = >>>>> - ioremap_wc(mem->bus.base + >>>>> mem->bus.offset, >>>>> -mem->bus.size); >>>>> - else >>>>> - mem->bus.addr = >>>>> - ioremap_nocache(mem->bus.base + >>>>> mem->bus.offset, >>>>> - mem->bus.size); >>>>> - if (!mem->bus.addr) >>>>> - return -ENOMEM; >>>>> - >>>>> - /* >>>>> - * Alpha: Use just the bus offset plus >>>>> - * the hose/domain memory base for bus.base. >>>>> - * It then can be used to build PTEs for VRAM >>>>> - * access, as done in ttm_bo_vm_fault(). >>>>> - */ >>>>> - mem->bus.base = (mem->bus.base & 0x0UL) + >>>>> - adev->ddev->hose->dense_mem_base; >>>>> -#endif >>>>>break; >>>>>default: >>>>>return -EINVAL; >>>>> >>>> Maybe leave an #error line, or make AMDGPU depend on !ALPHA in Kconfig, >>>> to prevent somebody from trying this driver on an Alpha machine, and it >>>> mysteriously failing due to the lack of this? >>>> >>>> Either way, >>>> >>>> Acked-by: Michel Dänzer <michel.daen...@amd.com> >>> Does this code even work on alpha (or compile for that matter)? >> If it doesn't compile, that makes it obvious to somebody who tries >> compiling it on Alpha that there's something wrong. Whereas if we just >> remove it, the driver might build but probably won't work. > > According to Wikipedia the last Alpha was build in 2004, the first GCN 1 > hardware we support shipped in 2014. > > That's a decade between those and I have strong doubts that any Alpha > board has physically PCIe compatible slots. That's a good point about PCIe. git grep -i PCIe arch/alpha in the kernel tree doesn't turn up anything. > Anyway, I will just add a !ALPHA to Kconfig. You've convinced me it's not necessary. The patch is Reviewed-by: Michel Dänzer <michel.daen...@amd.com> as is. -- Earthling Michel Dänzer | http://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: [PATCH] drm: Harmonize CIK ASIC support in radeon and amdgpu (v2)
On 11/04/17 10:38 AM, Michel Dänzer wrote: > On 11/04/17 08:21 AM, Felix Kuehling wrote: >> Provide convenient compile time and boot time options for selecting >> CIK ASIC support in either or both drivers. >> >> v2: git add missing files > > [...] > >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig >> index 483059a..f85f81c 100644 >> --- a/drivers/gpu/drm/Kconfig >> +++ b/drivers/gpu/drm/Kconfig >> @@ -148,6 +148,57 @@ config DRM_AMDGPU >> >> source "drivers/gpu/drm/amd/amdgpu/Kconfig" >> >> +choice DRM_CIK_SUPPORT >> +prompt "Support for AMD CIK ASICs" >> +default DRM_CIK_RADEON >> +depends on DRM_AMDGPU || DRM_RADEON >> +help >> + Choose the driver used to support AMD CIK ASICs. >> + >> +config DRM_CIK_RADEON >> +bool "Radeon" >> +depends on DRM_RADEON >> +select DRM_RADEON_CIK >> +select DRM_RADEON_CIK_ENABLED >> +help >> + The Radeon driver was traditionally used to support CIK ASICs. >> + >> +config DRM_CIK_AMDGPU >> +bool "AMD GPU" >> +depends on DRM_AMDGPU >> +select DRM_AMDGPU_CIK >> +select DRM_AMDGPU_CIK_ENABLED >> +help >> + The AMD GPU driver has more active development for features and >> + performance. If you choose this driver, you also need the amdgpu >> + DDX driver for X.org. >> + >> +config DRM_CIK_BOTH_DEFAULT_RADEON >> +bool "Both, use Radeon by default" >> +depends on DRM_AMDGPU && DRM_RADEON >> +select DRM_RADEON_CIK >> +select DRM_RADEON_CIK_ENABLED >> +select DRM_AMDGPU_CIK >> +help >> + This option is useful for driver developers who want to test >> + both drivers while running the same kernel. The active driver >> + can be selected using the module parameters radeon.enable_cik >> + and amdgpu.enable_cik. >> + >> +config DRM_CIK_BOTH_DEFAULT_AMDGPU >> +bool "Both, use AMD GPU by default" >> +depends on DRM_AMDGPU && DRM_RADEON >> +select DRM_RADEON_CIK >> +select DRM_AMDGPU_CIK >> +select DRM_AMDGPU_CIK_ENABLED >> +help >> + This option is useful for driver developers who want to test >> + both drivers while running the same kernel. The active driver >> + can be selected using the module parameters radeon.enable_cik >> + and amdgpu.enable_cik. >> + >> +endchoice > > I wonder if we really need all these Kconfig options. I was thinking we > could simply always compile CIK support in amdgpu, and make > DRM_AMDGPU_CIK choose between using amdgpu or radeon by default for CIK. BTW, if we decide we do need the new options, let's call them something like DRM_AMD_CIK_* to make it clearer where they belong to. -- Earthling Michel Dänzer | http://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: [PATCH 1/3] drm/radeon: Make CIK support in Radeon conditional (v2)
On 12/04/17 01:13 AM, Felix Kuehling wrote: > On 17-04-10 09:39 PM, Michel Dänzer wrote: >> On 11/04/17 03:13 AM, Felix Kuehling wrote: >>> On 17-04-09 09:28 PM, Michel Dänzer wrote: >>>> On 10/04/17 09:56 AM, Michel Dänzer wrote: >>>>> On 08/04/17 05:15 AM, Felix Kuehling wrote: >>>>>> Advertise CIK PCI IDs only when they are not supported by amdgpu. >>>>>> Use the CONFIG_DRM_AMDGPU_CIK to check so that a single option in >>>>>> the kernel config keeps both drivers in sync. >>>>>> >>>>>> This is the simplest possible change. A more complete solution >>>>>> may want to conditionally disable more CIK-specific code in the >>>>>> Radeon driver. >>>>>> >>>>>> v2: Add CONFIG_DRM_RADEON_FORCE_CIK option >>>>>> >>>>>> Signed-off-by: Felix Kuehling <felix.kuehl...@amd.com> >>>>> I don't think this is good enough a solution. >>>> To elaborate, my main objection is that people who still want to be able >>>> to use the radeon driver for CIK/SI GPUs with CONFIG_DRM_AMDGPU_CIK >>>> enabled have to enable the new CONFIG_DRM_RADEON_FORCE_CIK/SI option, >>>> and then they're merely back to square one, in the current situation >>>> where it's not clearly defined which driver will end up being used for >>>> such GPUs. >>> So what's the usage model here? I think the situation that both AMDGPU >>> and Radeon support CIK is for developers only. "Normal end users" would >>> never be in this situation. >> I agree in the long term, but for now, there's still too many bugs which >> force users to use one or the other driver. Since this patch would >> require distros to choose one driver for all of their users, with no way >> to override at runtime, it would probably result in bad user experiences >> and/or a support nightmare at least in the short term. > > Right now the only sane configuration that a distro can choose is to > support CIK with radeon and not build CIK support into amdgpu. That > choice will still be available. So nothing changes for a risk-averse > distribution. Right. That said, CIK support in amdgpu seems to be getting pretty solid overall (and it's a requirement for Vulkan), so (something like) your latest patch will allow distros to keep radeon as the default for now, but make it easy for adventurous users to try out amdgpu. FWIW, some distros (at least openSuse AFAIK) are already enabling CONFIG_DRM_AMDGPU_CIK in their kernels, exposing their users to the gamble of which driver gets to drive their CIK GPUs. Thank you for getting the ball rolling on improving this situation! > If a distribution's choice does not work for all users, and end users > have to change the preference at runtime, that's already a bad user > experience. Just having the runtime option available doesn't make it a > better user experience, because most user won't know that there is a > choice and won't know that their issues can be fixed that way. If nothing else, it'll allow us to give suggestions for easy workarounds in bug reports. -- Earthling Michel Dänzer | http://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: [PATCH] drm/amdgpu: Add kernel parameter to manage memory error handling.
Hi Dave,
Please send patches inline instead of as attachments, ideally using git
send-email.
> @@ -212,6 +213,9 @@ module_param_named(cg_mask, amdgpu_cg_mask, uint, 0444);
> MODULE_PARM_DESC(pg_mask, "Powergating flags mask (0 = disable power
> gating)");
> module_param_named(pg_mask, amdgpu_pg_mask, uint, 0444);
>
> +MODULE_PARM_DESC(ecc_mask, "ECC/EDC flags mask (0 = disable ECC/EDC)");
"0 = disable ECC/EDC" implies that they're enabled by default? Was that
already the case before this patch?
> @@ -1664,6 +1664,24 @@ static int gfx_v8_0_do_edc_gpr_workarounds(struct
> amdgpu_device *adev)
> if (adev->asic_type != CHIP_CARRIZO)
> return 0;
>
> + DRM_INFO("gfx_v8_0_do_edc_gpr_workarounds(): ecc_flags: 0x%08x\n",
> + adev->ecc_flags);
> +
> + /*
> + * Check if EDC has been requested.
> + * For Carrizo, EDC is the best/safest mode WRT error handling.
> + */
> + if (!(adev->ecc_flags
> + & (AMD_ECC_SUPPORT_BEST | AMD_ECC_SUPPORT_EDC))) {
> + DRM_INFO("gfx_v8_0_do_edc_gpr_workarounds(): "
> + "skipping workarounds and not enabling EDC.\n");
> +
> + return 0;
> + }
> +
> + DRM_INFO("gfx_v8_0_do_edc_gpr_workarounds(): "
> + "running workarounds and enabling EDC.\n");
These DRM_INFOs are too chatty, maybe make them e.g. DRM_DEBUG_DRIVER.
--
Earthling Michel Dänzer | http://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: [PATCH] drm: Harmonize CIK ASIC support in radeon and amdgpu (v2)
On 12/04/17 01:05 AM, Felix Kuehling wrote: > On 17-04-11 12:01 AM, Michel Dänzer wrote: >> One issue with this per-driver enable_cik option is that if the user >> only enables it in the driver where it's disabled by default, without >> also disabling it in the driver where it's enabled by default, it's back >> to the current situation where both drivers try to use the same GPUs, >> and it's up to chance which one actually gets to. >> >> That's why I was thinking about also having a shared command line option >> respected by both drivers, e.g. amd_cik_driver=amdgpu/radeon . That >> would be the preferred way to choose the driver at runtime. > > The shared option could not be in either amdgpu or radeon. Otherwise > we'd create a cross-dependency between the drivers. It would have to be > in drm, I guess? > >> Note that the per-driver enable_cik option will still be needed to be >> able to override the kernel command line when manually loading the drivers. > > Why? I could make the shared option writable in > /sys/module/drm/parameters/amd_cik_driver so you can change it before > loading the module. I was thinking of a pure kernel command line option which is parsed by both drivers, not a module parameter. One possibility would be making each driver also parse the other driver's module parameter on the kernel command line. I.e. radeon would parse amdgpu.enable_cik=0 on the kernel command line and set its own enable_cik parameter to 1, and vice versa. This would probably require making the default value of the enable_cik options e.g. -1, and only parsing the other driver's option in that case. If you don't want to tackle that, I can give it a go as a follow-up patch. We do need to settle on whether all those Kconfig options are needed though; I think they're overkill. -- Earthling Michel Dänzer | http://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: [PATCH 1/3] drm/radeon: Make CIK support in Radeon conditional (v2)
On 08/04/17 05:15 AM, Felix Kuehling wrote: > Advertise CIK PCI IDs only when they are not supported by amdgpu. > Use the CONFIG_DRM_AMDGPU_CIK to check so that a single option in > the kernel config keeps both drivers in sync. > > This is the simplest possible change. A more complete solution > may want to conditionally disable more CIK-specific code in the > Radeon driver. > > v2: Add CONFIG_DRM_RADEON_FORCE_CIK option > > Signed-off-by: Felix Kuehling <felix.kuehl...@amd.com> I don't think this is good enough a solution. I want to be able to choose the driver to use at runtime, for each GPU individually. To make that possible, we probably need some kind of kernel command line option which is respected by both radeon and amdgpu drivers, plus possibly additional per-driver module parameters which can override that kernel command line option. CONFIG_DRM_AMDGPU_CIK/SI would then simply define which driver gets to drive CIK/SI GPUs by default. -- Earthling Michel Dänzer | http://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: [PATCH 1/3] drm/radeon: Make CIK support in Radeon conditional (v2)
On 10/04/17 09:56 AM, Michel Dänzer wrote: > On 08/04/17 05:15 AM, Felix Kuehling wrote: >> Advertise CIK PCI IDs only when they are not supported by amdgpu. >> Use the CONFIG_DRM_AMDGPU_CIK to check so that a single option in >> the kernel config keeps both drivers in sync. >> >> This is the simplest possible change. A more complete solution >> may want to conditionally disable more CIK-specific code in the >> Radeon driver. >> >> v2: Add CONFIG_DRM_RADEON_FORCE_CIK option >> >> Signed-off-by: Felix Kuehling <felix.kuehl...@amd.com> > > I don't think this is good enough a solution. To elaborate, my main objection is that people who still want to be able to use the radeon driver for CIK/SI GPUs with CONFIG_DRM_AMDGPU_CIK enabled have to enable the new CONFIG_DRM_RADEON_FORCE_CIK/SI option, and then they're merely back to square one, in the current situation where it's not clearly defined which driver will end up being used for such GPUs. > CONFIG_DRM_AMDGPU_CIK/SI would then simply define which driver gets to > drive CIK/SI GPUs by default. To avoid the above, I'd say this should be the first step: Make CONFIG_DRM_AMDGPU_CIK/SI define which driver will register for CIK/SI GPUs by default. This does require some way to override it at runtime, though. A simple initial solution for that might be "force_cik"/"force_si" module parameters in both drivers. Setting force_cik/si=1/0 would make the driver register for / not register for CIK/SI GPUs. -- Earthling Michel Dänzer | http://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
[PATCH xf86-video-amdgpu] Set correct DRM event context version
From: Daniel Stone <dani...@collabora.com> DRM_EVENT_CONTEXT_VERSION is the latest context version supported by whatever version of libdrm is present. We were blindly asserting we supported whatever version that may be, even if we actually didn't. With libdrm 2.4.78, setting a higher context version than 2 will attempt to call the page_flip_handler2 vfunc if it was non-NULL, which being a random chunk of stack memory, it might well have been. Set the version as 2, which should be bumped only with the appropriate version checks. Signed-off-by: Daniel Stone <dani...@collabora.com> (Ported from xserver commit 0c8e6ed85810e96d84173a52d628863802a78d82) Signed-off-by: Michel Dänzer <michel.daen...@amd.com> --- 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 2cdea90ad..f58d28f1a 100644 --- a/src/drmmode_display.c +++ b/src/drmmode_display.c @@ -2362,7 +2362,7 @@ Bool drmmode_pre_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, int cpp) xf86InitialConfiguration(pScrn, TRUE); - drmmode->event_context.version = DRM_EVENT_CONTEXT_VERSION; + drmmode->event_context.version = 2; drmmode->event_context.vblank_handler = amdgpu_drm_queue_handler; drmmode->event_context.page_flip_handler = amdgpu_drm_queue_handler; -- 2.11.0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH xf86-video-ati] Set correct DRM event context version
From: Daniel Stone <dani...@collabora.com> DRM_EVENT_CONTEXT_VERSION is the latest context version supported by whatever version of libdrm is present. We were blindly asserting we supported whatever version that may be, even if we actually didn't. With libdrm 2.4.78, setting a higher context version than 2 will attempt to call the page_flip_handler2 vfunc if it was non-NULL, which being a random chunk of stack memory, it might well have been. Set the version as 2, which should be bumped only with the appropriate version checks. Signed-off-by: Daniel Stone <dani...@collabora.com> (Ported from xserver commit 0c8e6ed85810e96d84173a52d628863802a78d82) Signed-off-by: Michel Dänzer <michel.daen...@amd.com> --- 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 ab11583a6..9911c0a6a 100644 --- a/src/drmmode_display.c +++ b/src/drmmode_display.c @@ -2538,7 +2538,7 @@ Bool drmmode_pre_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, int cpp) xf86InitialConfiguration(pScrn, TRUE); - drmmode->event_context.version = DRM_EVENT_CONTEXT_VERSION; + drmmode->event_context.version = 2; drmmode->event_context.vblank_handler = radeon_drm_queue_handler; drmmode->event_context.page_flip_handler = radeon_drm_queue_handler; -- 2.11.0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm: Harmonize CIK ASIC support in radeon and amdgpu (v2)
On 11/04/17 08:21 AM, Felix Kuehling wrote: > Provide convenient compile time and boot time options for selecting > CIK ASIC support in either or both drivers. > > v2: git add missing files > > Signed-off-by: Felix Kuehling <felix.kuehl...@amd.com> [...] > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > index 6238e2e..84d393d 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > @@ -109,6 +109,11 @@ > int amdgpu_pos_buf_per_se = 0; > int amdgpu_cntl_sb_buf_per_se = 0; > int amdgpu_param_buf_per_se = 0; > +#ifdef CONFIG_DRM_AMDGPU_CIK_ENABLED > +int amdgpu_enable_cik = 1; > +#else > +int amdgpu_enable_cik = 0; > +#endif > > MODULE_PARM_DESC(vramlimit, "Restrict VRAM for testing, in megabytes"); > module_param_named(vramlimit, amdgpu_vram_limit, int, 0600); > @@ -234,6 +239,10 @@ > MODULE_PARM_DESC(param_buf_per_se, "the size of Off-Chip Pramater Cache per > Shader Engine (default depending on gfx)"); > module_param_named(param_buf_per_se, amdgpu_param_buf_per_se, int, 0444); > > +#ifdef DRM_AMDGPU_CIK > +MODULE_PARAM_DESC(enable_cik, "Enable CIK support"); > +module_param_named(enable_cik, amdgpu_enable_cik, int, 0444); > +#endif One issue with this per-driver enable_cik option is that if the user only enables it in the driver where it's disabled by default, without also disabling it in the driver where it's enabled by default, it's back to the current situation where both drivers try to use the same GPUs, and it's up to chance which one actually gets to. That's why I was thinking about also having a shared command line option respected by both drivers, e.g. amd_cik_driver=amdgpu/radeon . That would be the preferred way to choose the driver at runtime. Note that the per-driver enable_cik option will still be needed to be able to override the kernel command line when manually loading the drivers. Maybe there's a better way to handle both cases that I haven't thought of. -- Earthling Michel Dänzer | http://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: [PATCH xf86-video-ati] Set correct DRM event context version
On 10/04/17 06:42 PM, Emil Velikov wrote: > On 10 April 2017 at 09:37, Michel Dänzer <mic...@daenzer.net> wrote: >> From: Daniel Stone <dani...@collabora.com> >> >> DRM_EVENT_CONTEXT_VERSION is the latest context version supported by >> whatever version of libdrm is present. We were blindly asserting we >> supported whatever version that may be, even if we actually didn't. >> >> With libdrm 2.4.78, setting a higher context version than 2 will attempt >> to call the page_flip_handler2 vfunc if it was non-NULL, which being a >> random chunk of stack memory, it might well have been. >> > Should be safe since we use xnfcalloc [in RADEONGetRec]. That's a good point, thanks (applies equally to the modesetting driver AFAICT); I'll drop the second paragraph from the commit log. > Regardless, the amdgpu and ati patches are > Reviewed-by: Emil Velikov <emil.l.veli...@gmail.com> Thanks! -- Earthling Michel Dänzer | http://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
