dri-devel September 2011

dri-devel@lists.freedesktop.org

68 participants
507 discussions

[Bug 27069] OpenGl is slower on dri2
by bugzilla-daemon＠freedesktop.org 01 Sep '11

01 Sep '11

https://bugs.freedesktop.org/show_bug.cgi?id=27069 --- Comment #3 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2011-09-01 16:20:12 PDT --- This problem still exists, UMS(as far as 3D is still working with it) is much faster than KMS. Unfortunately the only app that's still working with UMS in Mesa 7.11 is glxgears. On my r250 GPU glxgeares runs at 2600 fps with UMS, 1070 with KMS(default Window size). At 1400x1050 the numbers are 370 fps(UMS) and 60 fps(KMS). I don't think vsync causes the issue, disabling it seems to work fine, at least for windowed apps. etracer is still a lot slower with KMS than it used to be. At 1400x1050 and otherwise default settings it runs at 15-20 fps. With an ancient Mesa version I tested today(6.4.2) it runs at a pretty okish 60 fps at the same settings. The problem seems to be on the GPU side. Whenever the problem occurs the CPU is idle and the GPU working, and increasing the rendering resolution makes the problem worse. The unfortunate situation this creates is that the 6 years old Mesa on my old hard drive vastly outperforms Mesa 7.11 in many rendering situations. I could not spot any CPU side problems, but the GPU slowness makes it hard to test. My unscientific guess is that in setups where the KMS GPU slowness doesn't matter Mesa 7.11 is about 50% faster than Mesa 6.4.2. (etracer with a tiny resolution, long view range and lots of objects) I'll test r300 on a Radeon X1600 GPU over the weekend. This GPU/driver combo is pretty slow as well, but I'm not sure if r300 still supports UMS. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[PATCH -next 0/8] vmwgfx compatibility-affecting changes
by Thomas Hellstrom 01 Sep '11

01 Sep '11

A set of changes and cleanups that affects the kernel-user-interface in a non-backwards-compatible way. This is intended to be the last major bump before we exit staging, but there may be a couple of minor bumps in upcoming patches, as we add new features. In-Reply-To:

1 8

[PATCH 02/10] vmwgfx: Add support for depth 8
by Thomas Hellstrom 01 Sep '11

01 Sep '11

From: Michel Dänzer <daenzer(a)vmware.com> Signed-off-by: Michel Dänzer <daenzer(a)vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom(a)vmware.com> --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 3 +++ drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 11 +++++++++++ 2 files changed, 14 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c index dfe32e6..7539b56 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c @@ -567,6 +567,9 @@ static int vmw_kms_new_framebuffer_surface(struct vmw_private *dev_priv, case 15: format = SVGA3D_A1R5G5B5; break; + case 8: + format = SVGA3D_LUMINANCE8; + break; default: DRM_ERROR("Invalid color depth: %d\n", mode_cmd->depth); return -EINVAL; diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c index 7b8115a..c6d09a6 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c @@ -83,6 +83,15 @@ static void vmw_ldu_crtc_gamma_set(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b, uint32_t start, uint32_t size) { + struct vmw_private *dev_priv = vmw_priv(crtc->dev); + int i; + + for (i = 0; i < size; i++) { + DRM_DEBUG("%d r/g/b = 0x%04x / 0x%04x / 0x%04x\n", i, r[i], g[i], b[i]); + vmw_write(dev_priv, SVGA_PALETTE_BASE + i * 3 + 0, r[i] >> 8); + vmw_write(dev_priv, SVGA_PALETTE_BASE + i * 3 + 1, g[i] >> 8); + vmw_write(dev_priv, SVGA_PALETTE_BASE + i * 3 + 2, b[i] >> 8); + } } static void vmw_ldu_crtc_destroy(struct drm_crtc *crtc) @@ -547,6 +556,8 @@ static int vmw_ldu_init(struct vmw_private *dev_priv, unsigned unit) drm_crtc_init(dev, crtc, &vmw_legacy_crtc_funcs); + drm_mode_crtc_set_gamma_size(crtc, 256); + drm_connector_attach_property(connector, dev->mode_config.dirty_info_property, 1); -- 1.7.4.4

2 11

radeon power_profile "default" causes laptop overheating and crashes
by Pasi Kärkkäinen 01 Sep '11

01 Sep '11

Hello, I have a laptop with Mobility Radeon HD 3650, and the opensource radeon driver makes the laptop overheat and crash (or kernel does thermal emergency shutdowns). Even when the laptop is totally *idle* the system overheats! As a default power_profile "default" is in use (and causes problems): # cat /sys/class/drm/card0/device/power_profile default I can workaround the issue with: # echo low > /sys/class/drm/card0/device/power_profile .. which makes the temperature go down 10-20 degrees celsius, and the fans slow down and the system feels much cooler. I've seen this problem with Linux 2.6.35 (Fedora 14), Linux 2.6.38 (Fedora 15) and Linux 3.0.0 (Fedora 16 alpha). Is there anything I should try to troubleshoot the problem? Is "default" power_profile supposed to cause overheating? Using proprietary AMD fglrx driver doesn't have this problem, fglrx works out-of-the-box and the laptop does not overheat. dmesg from Linux 3.0.0 here: http://pasik.reaktio.net/fedora/f16/dmesg-hp-elitebook-8530p-f16-alpha.txt Thanks, -- Pasi

1 1

[Bug 25052] kernel modesetting still does not work
by bugzilla-daemon＠bugzilla.kernel.org 01 Sep '11

01 Sep '11

https://bugzilla.kernel.org/show_bug.cgi?id=25052 Bernhard M. Wiedemann <kernelbmw(a)lsmod.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kernelbmw(a)lsmod.de --- Comment #25 from Bernhard M. Wiedemann <kernelbmw(a)lsmod.de> 2011-09-01 18:24:02 --- I retried last week with linux-3.0 and found nomodeset to be necessary to get not just to framebuffer console but into KDE4.7 without the system hanging with a Vendor: pci 0x10de "nVidia Corporation" Device: pci 0x06fd "Quadro NVS 295" SubVendor: pci 0x10de "nVidia Corporation" SubDevice: pci 0x062e and similar on my Vendor: pci 0x10de "nVidia Corporation" Device: pci 0x0641 "GeForce 9400 GT" SubVendor: pci 0x1462 "Micro-Star International Co., Ltd." SubDevice: pci 0x133a could be a nouveau bug. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 0

[PATCH] drm/radeon/kms: make sure pci max read request size is valid on evergreen+
by alexdeucher＠gmail.com 01 Sep '11

01 Sep '11

From: Alex Deucher <alexander.deucher(a)amd.com> If the bios or OS sets the pci max read request size to 0 or an invalid value (6,7), it can result in a hang or slowdown. Check and set it to something sane if it's invalid. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=42162 Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)kernel.org --- drivers/gpu/drm/radeon/evergreen.c | 24 ++++++++++++++++++++++++ drivers/gpu/drm/radeon/ni.c | 3 +++ 2 files changed, 27 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen.c b/drivers/gpu/drm/radeon/evergreen.c index d8b725d..1e040f5 100644 --- a/drivers/gpu/drm/radeon/evergreen.c +++ b/drivers/gpu/drm/radeon/evergreen.c @@ -41,6 +41,28 @@ static void evergreen_gpu_init(struct radeon_device *rdev); void evergreen_fini(struct radeon_device *rdev); static void evergreen_pcie_gen2_enable(struct radeon_device *rdev); +#define PCI_DEVICE_CNTL 0x60 +#define PCI_MAX_READ_REQUEST_SIZE_SHIFT 12 +#define PCI_MAX_READ_REQUEST_SIZE_MASK (7 << 12) + +void evergreen_fix_pci_max_read_req_size(struct radeon_device *rdev) +{ + u16 tmp; + + pci_read_config_word(rdev->pdev, PCI_DEVICE_CNTL, &tmp); + + /* if bios or OS sets MAX_READ_REQUEST_SIZE to an invalid value, fix it + * to avoid hangs or perfomance issues + */ + if ((((tmp & PCI_MAX_READ_REQUEST_SIZE_MASK) >> PCI_MAX_READ_REQUEST_SIZE_SHIFT) == 0) || + (((tmp & PCI_MAX_READ_REQUEST_SIZE_MASK) >> PCI_MAX_READ_REQUEST_SIZE_SHIFT) == 6) || + (((tmp & PCI_MAX_READ_REQUEST_SIZE_MASK) >> PCI_MAX_READ_REQUEST_SIZE_SHIFT) == 7)) { + tmp &= ~PCI_MAX_READ_REQUEST_SIZE_MASK; + tmp |= (2 << PCI_MAX_READ_REQUEST_SIZE_SHIFT); + pci_write_config_word(rdev->pdev, PCI_DEVICE_CNTL, tmp); + } +} + void evergreen_pre_page_flip(struct radeon_device *rdev, int crtc) { /* enable the pflip int */ @@ -1865,6 +1887,8 @@ static void evergreen_gpu_init(struct radeon_device *rdev) WREG32(GRBM_CNTL, GRBM_READ_TIMEOUT(0xff)); + evergreen_fix_pci_max_read_req_size(rdev); + cc_gc_shader_pipe_config = RREG32(CC_GC_SHADER_PIPE_CONFIG) & ~2; cc_gc_shader_pipe_config |= diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c index d916c82..d6cb534 100644 --- a/drivers/gpu/drm/radeon/ni.c +++ b/drivers/gpu/drm/radeon/ni.c @@ -39,6 +39,7 @@ extern int evergreen_mc_wait_for_idle(struct radeon_device *rdev); extern void evergreen_mc_program(struct radeon_device *rdev); extern void evergreen_irq_suspend(struct radeon_device *rdev); extern int evergreen_mc_init(struct radeon_device *rdev); +extern void evergreen_fix_pci_max_read_req_size(struct radeon_device *rdev); #define EVERGREEN_PFP_UCODE_SIZE 1120 #define EVERGREEN_PM4_UCODE_SIZE 1376 @@ -724,6 +725,8 @@ static void cayman_gpu_init(struct radeon_device *rdev) WREG32(GRBM_CNTL, GRBM_READ_TIMEOUT(0xff)); + evergreen_fix_pci_max_read_req_size(rdev); + mc_shared_chmap = RREG32(MC_SHARED_CHMAP); mc_arb_ramcfg = RREG32(MC_ARB_RAMCFG); -- 1.7.1.1

2 2

Re: [PATCH v2] drm/radeon: Print gart initialization details on all chipsets
by Michel Dänzer 01 Sep '11

01 Sep '11

DRM patches need to be submitted to the dri-devel list, moving there. On Die, 2011-08-30 at 00:17 +0200, Tormod Volden wrote: > From: Tormod Volden <debian.tormod(a)gmail.com> > > This was previously done for r300 only. Use %p instead of %08X for > printing the table address. sizeof(dma_addr_t) can be 8 even when sizeof(void*) is 4. > Also fix typo in gart warning messages. > > Signed-off-by: Tormod Volden <debian.tormod(a)gmail.com> [...] > diff --git a/drivers/gpu/drm/radeon/radeon_gart.c b/drivers/gpu/drm/radeon/radeon_gart.c > index a533f52..40f851b 100644 > --- a/drivers/gpu/drm/radeon/radeon_gart.c > +++ b/drivers/gpu/drm/radeon/radeon_gart.c > @@ -142,7 +142,7 @@ void radeon_gart_unbind(struct radeon_device *rdev, unsigned offset, > u64 page_base; > > if (!rdev->gart.ready) { > - WARN(1, "trying to unbind memory to unitialized GART !\n"); > + WARN(1, "trying to unbind memory to uninitialized GART !\n"); While you're at it, 'unbind from'? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer

2 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2011