[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #38 from ryszardz...@yahoo.com 2012-06-02 23:45:20 PDT --- I just checked back with the bug to see how the development is going and seems either I am doing something wrong or that patches updated by Jerome Glisse would need to be updated again for kernel 3.4 or 3.5-rc1 and mesa git master as they do not apply for me :( -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50618] Slow video playback with 40mbits mpeg2+vdpau
https://bugs.freedesktop.org/show_bug.cgi?id=50618 --- Comment #4 from nathanhi 2012-06-02 14:15:58 PDT --- >> Ahh, I am using mplayer1. Well, I also tried it with mplayer1 - The results are the same. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 50618] Slow video playback with 40mbits mpeg2+vdpau
https://bugs.freedesktop.org/show_bug.cgi?id=50618 --- Comment #3 from Andy Furniss 2012-06-02 13:29:04 PDT --- (In reply to comment #2) > >> mplayer -vo vdpau:fps=-1 -vc ffmpeg12vdpau: MPlayer: 14%, Xorg: 6,3% ( > >> Your > >> system is too SLOW to play this! ) -> Too slow! 1-10 fps > > > > I am curious what -vo vdpau:fps=-1 means. Using svn mplayer that just > > throws an > > unknown vdpau parameter for me. > > -vo vdpau:fps=-1 disables all framedrop logic and timing adjustments. Are you > using mplayer1 or 2? Ahh, I am using mplayer1. Maybe trying with that would be worth a go - or maybe 40mbit is just too much for onboard GPU. I use a "real card" so even if 40mbit worked for me, it wouldn't mean anything for you I guess. I'll make one and try soon - AFK for tonight. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] radeon: Make PM info available to all, not just debug users
Hi all
This moves the pm_info file from debugfs to next to the other two power files.
Requested by several users at Phoronix.
PS: Please CC me. Also please be gentle, it's my first step in kernel-land ;)
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/radeon/radeon_pm.c | 86 ++-
1 files changed, 44 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 0882554..7aab18f 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -45,7 +45,6 @@ static const char *radeon_pm_state_type_name[5] = {
};
static void radeon_dynpm_idle_work_handler(struct work_struct *work);
-static int radeon_debugfs_pm_init(struct radeon_device *rdev);
static bool radeon_pm_in_vbl(struct radeon_device *rdev);
static bool radeon_pm_debug_check_in_vbl(struct radeon_device *rdev, bool
finish);
static void radeon_pm_update_profile(struct radeon_device *rdev);
@@ -437,8 +436,49 @@ fail:
return count;
}
+static ssize_t radeon_get_pm_info(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev));
+ struct radeon_device *rdev = ddev->dev_private;
+
+ ssize_t curpos, len = PAGE_SIZE;
+ char *tmp;
+
+ curpos = snprintf(buf, len,
+ "default engine clock: %u0 kHz\n"
+ "current engine clock: %u0 kHz\n"
+ "default memory clock: %u0 kHz\n",
+ rdev->pm.default_sclk,
+ radeon_get_engine_clock(rdev),
+ rdev->pm.default_mclk);
+ len -= curpos;
+
+ if (rdev->asic->get_memory_clock) {
+ tmp = buf + curpos;
+ curpos += snprintf(tmp, len, "current memory clock: %u0 kHz\n",
radeon_get_memory_clock(rdev));
+ len = PAGE_SIZE - curpos;
+ }
+
+ if (rdev->pm.current_vddc) {
+ tmp = buf + curpos;
+ curpos += snprintf(tmp, len, "voltage: %u mV\n",
rdev->pm.current_vddc);
+ len = PAGE_SIZE - curpos;
+ }
+
+ if (rdev->asic->get_pcie_lanes) {
+ tmp = buf + curpos;
+ curpos += snprintf(tmp, len, "PCIE lanes: %d\n",
radeon_get_pcie_lanes(rdev));
+ len = PAGE_SIZE - curpos;
+ }
+
+ return curpos;
+}
+
static DEVICE_ATTR(power_profile, S_IRUGO | S_IWUSR, radeon_get_pm_profile,
radeon_set_pm_profile);
static DEVICE_ATTR(power_method, S_IRUGO | S_IWUSR, radeon_get_pm_method,
radeon_set_pm_method);
+static DEVICE_ATTR(power_info, S_IRUGO, radeon_get_pm_info, NULL);
static ssize_t radeon_hwmon_show_temp(struct device *dev,
struct device_attribute *attr,
@@ -639,14 +679,14 @@ int radeon_pm_init(struct radeon_device *rdev)
ret = device_create_file(rdev->dev, &dev_attr_power_method);
if (ret)
DRM_ERROR("failed to create device file for power
method\n");
+ ret = device_create_file(rdev->dev, &dev_attr_power_info);
+ if (ret)
+ DRM_ERROR("failed to create device file for power
info\n");
#ifdef CONFIG_ACPI
rdev->acpi_nb.notifier_call = radeon_acpi_event;
register_acpi_notifier(&rdev->acpi_nb);
#endif
- if (radeon_debugfs_pm_init(rdev)) {
- DRM_ERROR("Failed to register debugfs file for PM!\n");
- }
DRM_INFO("radeon: power management initialized\n");
}
@@ -843,41 +883,3 @@ static void radeon_dynpm_idle_work_handler(struct
work_struct *work)
mutex_unlock(&rdev->pm.mutex);
ttm_bo_unlock_delayed_workqueue(&rdev->mman.bdev, resched);
}
-
-/*
- * Debugfs info
- */
-#if defined(CONFIG_DEBUG_FS)
-
-static int radeon_debugfs_pm_info(struct seq_file *m, void *data)
-{
- struct drm_info_node *node = (struct drm_info_node *) m->private;
- struct drm_device *dev = node->minor->dev;
- struct radeon_device *rdev = dev->dev_private;
-
- seq_printf(m, "default engine clock: %u0 kHz\n", rdev->pm.default_sclk);
- seq_printf(m, "current engine clock: %u0 kHz\n",
radeon_get_engine_clock(rdev));
- seq_printf(m, "default memory clock: %u0 kHz\n", rdev->pm.default_mclk);
- if (rdev->asic->pm.get_memory_clock)
- seq_printf(m, "current memory clock: %u0 kHz\n",
radeon_get_memory_clock(rdev));
- if (rdev->pm.current_vddc)
- seq_printf(m, "voltage: %u mV\n", rdev->pm.current_vddc);
- if (rdev->asic->pm.get_pcie_lanes)
- seq_printf(m, "PCIE lanes: %d\n", radeon_get_pcie_lanes(rdev));
-
- return 0;
-}
-
-static struct drm_info_list radeon_pm_info_list[] = {
- {"radeon_pm_info", radeon_debug
[Bug 50618] Slow video playback with 40mbits mpeg2+vdpau
https://bugs.freedesktop.org/show_bug.cgi?id=50618 --- Comment #2 from nathanhi 2012-06-02 12:06:12 PDT --- >> mplayer -vo vdpau:fps=-1 -vc ffmpeg12vdpau: MPlayer: 14%, Xorg: 6,3% ( >> Your >> system is too SLOW to play this! ) -> Too slow! 1-10 fps > > I am curious what -vo vdpau:fps=-1 means. Using svn mplayer that just throws > an > unknown vdpau parameter for me. -vo vdpau:fps=-1 disables all framedrop logic and timing adjustments. Are you using mplayer1 or 2? Source: man mplayer2: fps= Override autodetected display refresh rate value (the value is needed for framedrop to allow video playback rates higher than display refresh rate, and for vsync-aware frame timing adjustments). Default 0 means use autodetected value. A positive value is interpreted as a refresh rate in Hz and overrides the autodetected value. A negative value disables all timing adjustment and framedrop logic. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 50618] Slow video playback with 40mbits mpeg2+vdpau
https://bugs.freedesktop.org/show_bug.cgi?id=50618 --- Comment #1 from Andy Furniss 2012-06-02 11:33:15 PDT --- (In reply to comment #0) > mplayer -vo vdpau:fps=-1 -vc ffmpeg12vdpau: MPlayer: 14%, Xorg: 6,3% ( > Your > system is too SLOW to play this! ) -> Too slow! 1-10 fps I am curious what -vo vdpau:fps=-1 means. Using svn mplayer that just throws an unknown vdpau parameter for me. FWIW R600 + -vc ffmpeg12vdpau doesn't quite produce perfect output anyway. There are some cumulative errors that build between I frames. Depending on content and how close you look they may or may not be obvioius. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 50618] New: Slow video playback with 40mbits mpeg2+vdpau
https://bugs.freedesktop.org/show_bug.cgi?id=50618 Bug #: 50618 Summary: Slow video playback with 40mbits mpeg2+vdpau Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: nathanhirschauer at verfriemelt.org Created attachment 62425 --> https://bugs.freedesktop.org/attachment.cgi?id=62425 mediainfo output of the video file When playing an MPEG2-video with high bitrate (>40 MBps) on my Mobility Radeon HD 3450 (best graphics card EVER! :3) with VDPAU I get very low framerates when using hardware video decoding, cpu decoding is fine, here a quick comparison (no -benchmark results because mplayer did something weird there): The mediainfo output of the video file is attached to the bug report. CPU usages with different mplayer parameters: mplayer without vdpau: MPlayer: 44,7%; Xorg: 12,8% -> Runs fine, 26fps mplayer -vo vdpau: MPlayer: 43,4%, Xorg: 12,6% -> Runs also file, 26fps mplayer -vo vdpau:fps=-1 -vc ffmpeg12vdpau: MPlayer: 14%, Xorg: 6,3% ( Your system is too SLOW to play this! ) -> Too slow! 1-10 fps You may contact me via IRC (freenode, #radeon -> nathanhi) for the video file. I'm using mesa from git (git-775ba11), Xorg 1.12.1.902, xf86-video-ati git-c1b9b2c, libdrm git-481234f and Kernel 3.3.7. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 49654] Heavy flickering on LVDS panel when not using the native resolution
https://bugs.freedesktop.org/show_bug.cgi?id=49654 Niels Ole Salscheider changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Niels Ole Salscheider 2012-06-02 09:09:48 PDT --- Seems to be fixed for kernel 3.5. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 50618] Slow video playback with 40mbits mpeg2+vdpau
https://bugs.freedesktop.org/show_bug.cgi?id=50618 --- Comment #4 from nathanhi 2012-06-02 14:15:58 PDT --- >> Ahh, I am using mplayer1. Well, I also tried it with mplayer1 - The results are the same. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50616] glClear occasionally taking >60ms
https://bugs.freedesktop.org/show_bug.cgi?id=50616 --- Comment #1 from Lauri Kasanen 2012-06-02 06:32:41 PDT --- http://kiwi6.com/file/95a4z148f2 (550kb) The timing output from apitrace. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 50616] New: glClear occasionally taking >60ms
https://bugs.freedesktop.org/show_bug.cgi?id=50616 Bug #: 50616 Summary: glClear occasionally taking >60ms Classification: Unclassified Product: Mesa Version: 8.0 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: curaga at operamail.com I have a test app that draws 65k point sprites, apitrace: http://kiwi6.com/file/0c0512r1no (980kb). Apitrace says that on average glClear takes 28ms, and many clear calls take over 60ms. Surely it shouldn't take that long? If it were because of tearing prevention, it should take at most 16ms (1/60Hz). -- vblank_mode=0 had no change, oprofile says Mesa takes less than 2% cpu. Latencytop shows radeon_fence_wait taking between 3 and 5ms during rendering. -- Mesa 8.0.3 Linux 3.2.17 HD4350 / r600g -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 50618] Slow video playback with 40mbits mpeg2+vdpau
https://bugs.freedesktop.org/show_bug.cgi?id=50618 --- Comment #3 from Andy Furniss 2012-06-02 13:29:04 PDT --- (In reply to comment #2) > >> mplayer -vo vdpau:fps=-1 -vc ffmpeg12vdpau: MPlayer: 14%, Xorg: 6,3% ( > >> Your > >> system is too SLOW to play this! ) -> Too slow! 1-10 fps > > > > I am curious what -vo vdpau:fps=-1 means. Using svn mplayer that just > > throws an > > unknown vdpau parameter for me. > > -vo vdpau:fps=-1 disables all framedrop logic and timing adjustments. Are you > using mplayer1 or 2? Ahh, I am using mplayer1. Maybe trying with that would be worth a go - or maybe 40mbit is just too much for onboard GPU. I use a "real card" so even if 40mbit worked for me, it wouldn't mean anything for you I guess. I'll make one and try soon - AFK for tonight. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50618] Slow video playback with 40mbits mpeg2+vdpau
https://bugs.freedesktop.org/show_bug.cgi?id=50618 --- Comment #2 from nathanhi 2012-06-02 12:06:12 PDT --- >> mplayer -vo vdpau:fps=-1 -vc ffmpeg12vdpau: MPlayer: 14%, Xorg: 6,3% ( >> Your >> system is too SLOW to play this! ) -> Too slow! 1-10 fps > > I am curious what -vo vdpau:fps=-1 means. Using svn mplayer that just throws > an > unknown vdpau parameter for me. -vo vdpau:fps=-1 disables all framedrop logic and timing adjustments. Are you using mplayer1 or 2? Source: man mplayer2: fps= Override autodetected display refresh rate value (the value is needed for framedrop to allow video playback rates higher than display refresh rate, and for vsync-aware frame timing adjustments). Default 0 means use autodetected value. A positive value is interpreted as a refresh rate in Hz and overrides the autodetected value. A negative value disables all timing adjustment and framedrop logic. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50618] Slow video playback with 40mbits mpeg2+vdpau
https://bugs.freedesktop.org/show_bug.cgi?id=50618 --- Comment #1 from Andy Furniss 2012-06-02 11:33:15 PDT --- (In reply to comment #0) > mplayer -vo vdpau:fps=-1 -vc ffmpeg12vdpau: MPlayer: 14%, Xorg: 6,3% ( > Your > system is too SLOW to play this! ) -> Too slow! 1-10 fps I am curious what -vo vdpau:fps=-1 means. Using svn mplayer that just throws an unknown vdpau parameter for me. FWIW R600 + -vc ffmpeg12vdpau doesn't quite produce perfect output anyway. There are some cumulative errors that build between I frames. Depending on content and how close you look they may or may not be obvioius. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50618] New: Slow video playback with 40mbits mpeg2+vdpau
https://bugs.freedesktop.org/show_bug.cgi?id=50618 Bug #: 50618 Summary: Slow video playback with 40mbits mpeg2+vdpau Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: nathanhirscha...@verfriemelt.org Created attachment 62425 --> https://bugs.freedesktop.org/attachment.cgi?id=62425 mediainfo output of the video file When playing an MPEG2-video with high bitrate (>40 MBps) on my Mobility Radeon HD 3450 (best graphics card EVER! :3) with VDPAU I get very low framerates when using hardware video decoding, cpu decoding is fine, here a quick comparison (no -benchmark results because mplayer did something weird there): The mediainfo output of the video file is attached to the bug report. CPU usages with different mplayer parameters: mplayer without vdpau: MPlayer: 44,7%; Xorg: 12,8% -> Runs fine, 26fps mplayer -vo vdpau: MPlayer: 43,4%, Xorg: 12,6% -> Runs also file, 26fps mplayer -vo vdpau:fps=-1 -vc ffmpeg12vdpau: MPlayer: 14%, Xorg: 6,3% ( Your system is too SLOW to play this! ) -> Too slow! 1-10 fps You may contact me via IRC (freenode, #radeon -> nathanhi) for the video file. I'm using mesa from git (git-775ba11), Xorg 1.12.1.902, xf86-video-ati git-c1b9b2c, libdrm git-481234f and Kernel 3.3.7. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] radeon: Make PM info available to all, not just debug users
Hi all
This moves the pm_info file from debugfs to next to the other two power files.
Requested by several users at Phoronix.
PS: Please CC me. Also please be gentle, it's my first step in kernel-land ;)
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/radeon/radeon_pm.c | 86 ++-
1 files changed, 44 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 0882554..7aab18f 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -45,7 +45,6 @@ static const char *radeon_pm_state_type_name[5] = {
};
static void radeon_dynpm_idle_work_handler(struct work_struct *work);
-static int radeon_debugfs_pm_init(struct radeon_device *rdev);
static bool radeon_pm_in_vbl(struct radeon_device *rdev);
static bool radeon_pm_debug_check_in_vbl(struct radeon_device *rdev, bool
finish);
static void radeon_pm_update_profile(struct radeon_device *rdev);
@@ -437,8 +436,49 @@ fail:
return count;
}
+static ssize_t radeon_get_pm_info(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev));
+ struct radeon_device *rdev = ddev->dev_private;
+
+ ssize_t curpos, len = PAGE_SIZE;
+ char *tmp;
+
+ curpos = snprintf(buf, len,
+ "default engine clock: %u0 kHz\n"
+ "current engine clock: %u0 kHz\n"
+ "default memory clock: %u0 kHz\n",
+ rdev->pm.default_sclk,
+ radeon_get_engine_clock(rdev),
+ rdev->pm.default_mclk);
+ len -= curpos;
+
+ if (rdev->asic->get_memory_clock) {
+ tmp = buf + curpos;
+ curpos += snprintf(tmp, len, "current memory clock: %u0 kHz\n",
radeon_get_memory_clock(rdev));
+ len = PAGE_SIZE - curpos;
+ }
+
+ if (rdev->pm.current_vddc) {
+ tmp = buf + curpos;
+ curpos += snprintf(tmp, len, "voltage: %u mV\n",
rdev->pm.current_vddc);
+ len = PAGE_SIZE - curpos;
+ }
+
+ if (rdev->asic->get_pcie_lanes) {
+ tmp = buf + curpos;
+ curpos += snprintf(tmp, len, "PCIE lanes: %d\n",
radeon_get_pcie_lanes(rdev));
+ len = PAGE_SIZE - curpos;
+ }
+
+ return curpos;
+}
+
static DEVICE_ATTR(power_profile, S_IRUGO | S_IWUSR, radeon_get_pm_profile,
radeon_set_pm_profile);
static DEVICE_ATTR(power_method, S_IRUGO | S_IWUSR, radeon_get_pm_method,
radeon_set_pm_method);
+static DEVICE_ATTR(power_info, S_IRUGO, radeon_get_pm_info, NULL);
static ssize_t radeon_hwmon_show_temp(struct device *dev,
struct device_attribute *attr,
@@ -639,14 +679,14 @@ int radeon_pm_init(struct radeon_device *rdev)
ret = device_create_file(rdev->dev, &dev_attr_power_method);
if (ret)
DRM_ERROR("failed to create device file for power
method\n");
+ ret = device_create_file(rdev->dev, &dev_attr_power_info);
+ if (ret)
+ DRM_ERROR("failed to create device file for power
info\n");
#ifdef CONFIG_ACPI
rdev->acpi_nb.notifier_call = radeon_acpi_event;
register_acpi_notifier(&rdev->acpi_nb);
#endif
- if (radeon_debugfs_pm_init(rdev)) {
- DRM_ERROR("Failed to register debugfs file for PM!\n");
- }
DRM_INFO("radeon: power management initialized\n");
}
@@ -843,41 +883,3 @@ static void radeon_dynpm_idle_work_handler(struct
work_struct *work)
mutex_unlock(&rdev->pm.mutex);
ttm_bo_unlock_delayed_workqueue(&rdev->mman.bdev, resched);
}
-
-/*
- * Debugfs info
- */
-#if defined(CONFIG_DEBUG_FS)
-
-static int radeon_debugfs_pm_info(struct seq_file *m, void *data)
-{
- struct drm_info_node *node = (struct drm_info_node *) m->private;
- struct drm_device *dev = node->minor->dev;
- struct radeon_device *rdev = dev->dev_private;
-
- seq_printf(m, "default engine clock: %u0 kHz\n", rdev->pm.default_sclk);
- seq_printf(m, "current engine clock: %u0 kHz\n",
radeon_get_engine_clock(rdev));
- seq_printf(m, "default memory clock: %u0 kHz\n", rdev->pm.default_mclk);
- if (rdev->asic->pm.get_memory_clock)
- seq_printf(m, "current memory clock: %u0 kHz\n",
radeon_get_memory_clock(rdev));
- if (rdev->pm.current_vddc)
- seq_printf(m, "voltage: %u mV\n", rdev->pm.current_vddc);
- if (rdev->asic->pm.get_pcie_lanes)
- seq_printf(m, "PCIE lanes: %d\n", radeon_get_pcie_lanes(rdev));
-
- return 0;
-}
-
-static struct drm_info_list radeon_pm_info_list[] = {
- {"radeon_pm_info", radeon_
[Bug 49654] Heavy flickering on LVDS panel when not using the native resolution
https://bugs.freedesktop.org/show_bug.cgi?id=49654 Niels Ole Salscheider changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Niels Ole Salscheider 2012-06-02 09:09:48 PDT --- Seems to be fixed for kernel 3.5. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: PCI resources above 4GB
On Tue, May 29, 2012 at 5:19 PM, Bjorn Helgaas wrote: > On Mon, May 21, 2012 at 11:27 AM, Steven Newbury > wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 18/05/12 10:08, Yinghai Lu wrote: >>> On Fri, May 18, 2012 at 12:45 AM, Yinghai Lu >>> wrote: On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu wrote: > On Thu, May 17, 2012 at 5:34 AM, Steven Newbury > wrote: >> -BEGIN PGP SIGNED MESSAGE- Strange, the busn branch >> is merged with for-pci-res-alloc, but for some reason it >> isn't working. Only the bridge is detected, not the devices >> behind it. > > Can you post the boot log ? maybe recently reordering patches > applying sequence break it. Never mind, found the problem. >>> >>> updated for-pci-res-alloc branch. please check it. >>> >> Tested and working fine now. > > Can you attach dmesg logs without Yinghai's patches (where I assume it > doesn't work) and with them (where it *does* work) to the bugzilla? I > assume https://bugzilla.kernel.org/show_bug.cgi?id=10461 is still the > relevant report. > > I'm confused because I thought your _CRS showed no apertures above > 4GB, and I'm trying to figure out how Yinghai's patches can help if > that's the case. Your _CRS *doesn't* show any apertures above 4GB, but you're booting with "pci=nocrs", so we ignore them anyway. Doing hotplug with "pci=nocrs" is not a supportable proposition. Patches that help in the "pci=nocrs" case might be acceptable, but only if there is clearly no risk to the "pci=use_crs" case. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50616] glClear occasionally taking >60ms
https://bugs.freedesktop.org/show_bug.cgi?id=50616 --- Comment #1 from Lauri Kasanen 2012-06-02 06:32:41 PDT --- http://kiwi6.com/file/95a4z148f2 (550kb) The timing output from apitrace. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50616] New: glClear occasionally taking >60ms
https://bugs.freedesktop.org/show_bug.cgi?id=50616 Bug #: 50616 Summary: glClear occasionally taking >60ms Classification: Unclassified Product: Mesa Version: 8.0 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: cur...@operamail.com I have a test app that draws 65k point sprites, apitrace: http://kiwi6.com/file/0c0512r1no (980kb). Apitrace says that on average glClear takes 28ms, and many clear calls take over 60ms. Surely it shouldn't take that long? If it were because of tearing prevention, it should take at most 16ms (1/60Hz). -- vblank_mode=0 had no change, oprofile says Mesa takes less than 2% cpu. Latencytop shows radeon_fence_wait taking between 3 and 5ms during rendering. -- Mesa 8.0.3 Linux 3.2.17 HD4350 / r600g -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
