dri-devel June 2010

dri-devel@lists.freedesktop.org

71 participants
237 discussions

[Bug 26428] [KMS] doom3-demo aborts early on rv280
by bugzilla-daemon＠freedesktop.org 12 Jun '10

12 Jun '10

https://bugs.freedesktop.org/show_bug.cgi?id=26428 --- Comment #15 from Alex Deucher <agd5f(a)yahoo.com> 2010-06-12 10:23:27 PDT --- I'll send the patches to Dave and stable. -- 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] drm/radeon/kms: CS checker texture fixes for r1xx/r2xx/r3xx
by Alex Deucher 12 Jun '10

12 Jun '10

From: Roland Scheidegger <sroland(a)vmware.com> fixes: https://bugs.freedesktop.org/show_bug.cgi?id=28459 agd5f: apply to r1xx/r2xx as well. Signed-off-by: Roland Scheidegger <sroland(a)vmware.com> Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> --- drivers/gpu/drm/radeon/r100.c | 3 +++ drivers/gpu/drm/radeon/r200.c | 3 +++ drivers/gpu/drm/radeon/r300.c | 5 +++++ 3 files changed, 11 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c index cf89aa2..d66ae7d 100644 --- a/drivers/gpu/drm/radeon/r100.c +++ b/drivers/gpu/drm/radeon/r100.c @@ -1628,6 +1628,7 @@ static int r100_packet0_check(struct radeon_cs_parser *p, case RADEON_TXFORMAT_RGB332: case RADEON_TXFORMAT_Y8: track->textures[i].cpp = 1; + track->textures[i].compress_format = R100_TRACK_COMP_NONE; break; case RADEON_TXFORMAT_AI88: case RADEON_TXFORMAT_ARGB1555: @@ -1639,12 +1640,14 @@ static int r100_packet0_check(struct radeon_cs_parser *p, case RADEON_TXFORMAT_LDUDV655: case RADEON_TXFORMAT_DUDV88: track->textures[i].cpp = 2; + track->textures[i].compress_format = R100_TRACK_COMP_NONE; break; case RADEON_TXFORMAT_ARGB8888: case RADEON_TXFORMAT_RGBA8888: case RADEON_TXFORMAT_SHADOW32: case RADEON_TXFORMAT_LDUDUV8888: track->textures[i].cpp = 4; + track->textures[i].compress_format = R100_TRACK_COMP_NONE; break; case RADEON_TXFORMAT_DXT1: track->textures[i].cpp = 1; diff --git a/drivers/gpu/drm/radeon/r200.c b/drivers/gpu/drm/radeon/r200.c index 85617c3..a03f893 100644 --- a/drivers/gpu/drm/radeon/r200.c +++ b/drivers/gpu/drm/radeon/r200.c @@ -450,6 +450,7 @@ int r200_packet0_check(struct radeon_cs_parser *p, case R200_TXFORMAT_RGB332: case R200_TXFORMAT_Y8: track->textures[i].cpp = 1; + track->textures[i].compress_format = R100_TRACK_COMP_NONE; break; case R200_TXFORMAT_AI88: case R200_TXFORMAT_ARGB1555: @@ -461,6 +462,7 @@ int r200_packet0_check(struct radeon_cs_parser *p, case R200_TXFORMAT_DVDU88: case R200_TXFORMAT_AVYU4444: track->textures[i].cpp = 2; + track->textures[i].compress_format = R100_TRACK_COMP_NONE; break; case R200_TXFORMAT_ARGB8888: case R200_TXFORMAT_RGBA8888: @@ -468,6 +470,7 @@ int r200_packet0_check(struct radeon_cs_parser *p, case R200_TXFORMAT_BGR111110: case R200_TXFORMAT_LDVDU8888: track->textures[i].cpp = 4; + track->textures[i].compress_format = R100_TRACK_COMP_NONE; break; case R200_TXFORMAT_DXT1: track->textures[i].cpp = 1; diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c index b2f9efe..7e81db5 100644 --- a/drivers/gpu/drm/radeon/r300.c +++ b/drivers/gpu/drm/radeon/r300.c @@ -881,6 +881,7 @@ static int r300_packet0_check(struct radeon_cs_parser *p, case R300_TX_FORMAT_Y4X4: case R300_TX_FORMAT_Z3Y3X2: track->textures[i].cpp = 1; + track->textures[i].compress_format = R100_TRACK_COMP_NONE; break; case R300_TX_FORMAT_X16: case R300_TX_FORMAT_Y8X8: @@ -892,6 +893,7 @@ static int r300_packet0_check(struct radeon_cs_parser *p, case R300_TX_FORMAT_B8G8_B8G8: case R300_TX_FORMAT_G8R8_G8B8: track->textures[i].cpp = 2; + track->textures[i].compress_format = R100_TRACK_COMP_NONE; break; case R300_TX_FORMAT_Y16X16: case R300_TX_FORMAT_Z11Y11X10: @@ -902,14 +904,17 @@ static int r300_packet0_check(struct radeon_cs_parser *p, case R300_TX_FORMAT_FL_I32: case 0x1e: track->textures[i].cpp = 4; + track->textures[i].compress_format = R100_TRACK_COMP_NONE; break; case R300_TX_FORMAT_W16Z16Y16X16: case R300_TX_FORMAT_FL_R16G16B16A16: case R300_TX_FORMAT_FL_I32A32: track->textures[i].cpp = 8; + track->textures[i].compress_format = R100_TRACK_COMP_NONE; break; case R300_TX_FORMAT_FL_R32G32B32A32: track->textures[i].cpp = 16; + track->textures[i].compress_format = R100_TRACK_COMP_NONE; break; case R300_TX_FORMAT_DXT1: track->textures[i].cpp = 1; -- 1.7.0.1

1 2

[Bug 26428] [KMS] doom3-demo aborts early on rv280
by bugzilla-daemon＠freedesktop.org 12 Jun '10

12 Jun '10

https://bugs.freedesktop.org/show_bug.cgi?id=26428 --- Comment #14 from Andrew Randrianasulu <randrik(a)mail.ru> 2010-06-12 10:09:45 PDT --- (In reply to comment #13) > Created an attachment (id=36235) View: https://bugs.freedesktop.org/attachment.cgi?id=36235 Review: https://bugs.freedesktop.org/review?bug=26428&attachment=36235 > fix calculation of compressed mipmaps > > Totally untested too but this addresses issue 2 I mentioned. With that only the > strange cube_info.offset and mipmap handling I have no idea how that's supposed > to work would remain (at least as far as the more obvious issues in texture > tracking are concerned). This patch + patch from comment #12 + another patch from bug #28459 seems to fix problem kernel-side :) Thanks a lot! -- 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] drm/radeon/kms: fix bandwidth calculation when sideport is present
by Alex Deucher 12 Jun '10

12 Jun '10

Fixes fdo bug 27529: https://bugs.freedesktop.org/show_bug.cgi?id=27529 Reported-by: steckdenis(a)yahoo.fr Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> Cc: stable <stable(a)kernel.org> --- drivers/gpu/drm/radeon/rs690.c | 6 +----- 1 files changed, 1 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/radeon/rs690.c b/drivers/gpu/drm/radeon/rs690.c index bcc3319..64b94a8 100644 --- a/drivers/gpu/drm/radeon/rs690.c +++ b/drivers/gpu/drm/radeon/rs690.c @@ -228,10 +228,6 @@ void rs690_crtc_bandwidth_compute(struct radeon_device *rdev, fixed20_12 a, b, c; fixed20_12 pclk, request_fifo_depth, tolerable_latency, estimated_width; fixed20_12 consumption_time, line_time, chunk_time, read_delay_latency; - /* FIXME: detect IGP with sideport memory, i don't think there is any - * such product available - */ - bool sideport = false; if (!crtc->base.enabled) { /* FIXME: wouldn't it better to set priority mark to maximum */ @@ -300,7 +296,7 @@ void rs690_crtc_bandwidth_compute(struct radeon_device *rdev, /* Maximun bandwidth is the minimun bandwidth of all component */ rdev->pm.max_bandwidth = rdev->pm.core_bandwidth; - if (sideport) { + if (rdev->mc.igp_sideport_enabled) { if (rdev->pm.max_bandwidth.full > rdev->pm.sideport_bandwidth.full && rdev->pm.sideport_bandwidth.full) rdev->pm.max_bandwidth = rdev->pm.sideport_bandwidth; -- 1.7.0.1

1 0

[PATCH 1/2] drm/kms: add crtc disable function
by Alex Deucher 12 Jun '10

12 Jun '10

More explicit than dpms. Same as the encoder disable function. Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> --- drivers/gpu/drm/drm_crtc_helper.c | 5 ++++- include/drm/drm_crtc_helper.h | 3 +++ 2 files changed, 7 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c index 9b2a541..fa1323f 100644 --- a/drivers/gpu/drm/drm_crtc_helper.c +++ b/drivers/gpu/drm/drm_crtc_helper.c @@ -241,7 +241,10 @@ void drm_helper_disable_unused_functions(struct drm_device *dev) struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private; crtc->enabled = drm_helper_crtc_in_use(crtc); if (!crtc->enabled) { - crtc_funcs->dpms(crtc, DRM_MODE_DPMS_OFF); + if (crtc_funcs->disable) + (*crtc_funcs->disable)(crtc); + else + (*crtc_funcs->dpms)(crtc, DRM_MODE_DPMS_OFF); crtc->fb = NULL; } } diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h index 1121f77..7e3c976 100644 --- a/include/drm/drm_crtc_helper.h +++ b/include/drm/drm_crtc_helper.h @@ -63,6 +63,9 @@ struct drm_crtc_helper_funcs { /* reload the current crtc LUT */ void (*load_lut)(struct drm_crtc *crtc); + + /* disable crtc when not in use - more explicit than dpms off */ + void (*disable)(struct drm_crtc *crtc); }; struct drm_encoder_helper_funcs { -- 1.7.0.1

2 3

[PATCH 1/3] Add _DRM_HIDDEN macro
by Julien Cristau 12 Jun '10

12 Jun '10

Introduce a new internal header since that doesn't seem to exist yet. Or maybe I should rename xf86atomic.h instead. --- xf86drm-internals.h | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-) create mode 100644 xf86drm-internals.h diff --git a/xf86drm-internals.h b/xf86drm-internals.h new file mode 100644 index 0000000..bf5ff51 --- /dev/null +++ b/xf86drm-internals.h @@ -0,0 +1,12 @@ +#ifndef XF86DRM_INTERNALS_H +#define XF86DRM_INTERNALS_H + +#if defined(__GNUC__) && (__GNUC__ >= 4) +# define _DRM_HIDDEN __attribute__((visibility("hidden"))) +#elif defined(__SUNPRO_C) && (__SUNPRO_C >= 0x550) +# define _DRM_HIDDEN __hidden +#else /* not gcc >= 4 and not Sun Studio >= 8 */ +# define _X_HIDDEN +#endif /* GNUC >= 4 */ + +#endif -- 1.7.1

2 5

[Bug 26428] [KMS] doom3-demo aborts early on rv280
by bugzilla-daemon＠freedesktop.org 12 Jun '10

12 Jun '10

https://bugs.freedesktop.org/show_bug.cgi?id=26428 --- Comment #13 from Roland Scheidegger <sroland(a)vmware.com> 2010-06-12 07:42:32 PDT --- Created an attachment (id=36235) View: https://bugs.freedesktop.org/attachment.cgi?id=36235 Review: https://bugs.freedesktop.org/review?bug=26428&attachment=36235 fix calculation of compressed mipmaps Totally untested too but this addresses issue 2 I mentioned. With that only the strange cube_info.offset and mipmap handling I have no idea how that's supposed to work would remain (at least as far as the more obvious issues in texture tracking are concerned). -- 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

[Bug 26428] [KMS] doom3-demo aborts early on rv280
by bugzilla-daemon＠freedesktop.org 12 Jun '10

12 Jun '10

https://bugs.freedesktop.org/show_bug.cgi?id=26428 --- Comment #12 from Roland Scheidegger <sroland(a)vmware.com> 2010-06-12 07:38:57 PDT --- Created an attachment (id=36234) View: https://bugs.freedesktop.org/attachment.cgi?id=36234 Review: https://bugs.freedesktop.org/review?bug=26428&attachment=36234 possible fix for bogus cube texture tracking With some luck this could fix the bug, though it only addresses issue 4 I mentioned. -- 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

[Bug 28402] Kernel 2.6.34 freezes randomly
by bugzilla-daemon＠freedesktop.org 12 Jun '10

12 Jun '10

https://bugs.freedesktop.org/show_bug.cgi?id=28402 --- Comment #5 from Aidan Marks <aidan(a)cisco.com> 2010-06-12 05:19:42 PDT --- Also seeing random freezes here on my Thinkpad T60 on 2.6.34 with X1300 mobility radeon. -- 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

Re: [Bug 16148] New: page allocation failure. order:1, mode:0x50d0
by Andrew Morton 11 Jun '10

11 Jun '10

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Mon, 7 Jun 2010 17:32:04 GMT bugzilla-daemon(a)bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=16148 > > Summary: page allocation failure. order:1, mode:0x50d0 > Product: Memory Management > Version: 2.5 > Kernel Version: 2.6.35-rc1 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Page Allocator > AssignedTo: akpm(a)linux-foundation.org > ReportedBy: devnull(a)plzk.org > Regression: No > > > Created an attachment (id=26687) > --> (https://bugzilla.kernel.org/attachment.cgi?id=26687) > dmesg > > Never seen this before. > > 2.6.35-rc1 #1 SMP Mon May 31 21:31:02 CEST 2010 x86_64 GNU/Linux > > [48126.787684] Xorg: page allocation failure. order:1, mode:0x50d0 > [48126.787691] Pid: 1895, comm: Xorg Tainted: G W 2.6.35-rc1 #1 > [48126.787694] Call Trace: > [48126.787709] [<ffffffff811192f5>] __alloc_pages_nodemask+0x5f5/0x6f0 > [48126.787716] [<ffffffff81148695>] alloc_pages_current+0x95/0x100 > [48126.787720] [<ffffffff8114e04a>] new_slab+0x2ba/0x2c0 > [48126.787724] [<ffffffff8114ed0b>] __slab_alloc+0x14b/0x4e0 > [48126.787730] [<ffffffff81403f91>] ? security_vm_enough_memory_kern+0x21/0x30 > [48126.787736] [<ffffffff81556e6a>] ? agp_alloc_page_array+0x5a/0x70 > [48126.787740] [<ffffffff8115087f>] __kmalloc+0x11f/0x1c0 > [48126.787744] [<ffffffff81556e6a>] agp_alloc_page_array+0x5a/0x70 > [48126.787747] [<ffffffff81556ee4>] agp_generic_alloc_user+0x64/0x140 > [48126.787750] [<ffffffff8155717a>] agp_allocate_memory+0x9a/0x140 > [48126.787755] [<ffffffff8156c179>] drm_agp_allocate_memory+0x9/0x10 > [48126.787758] [<ffffffff8156c1d7>] drm_agp_bind_pages+0x57/0x100 > [48126.787765] [<ffffffff81627fe4>] i915_gem_object_bind_to_gtt+0x144/0x340 > [48126.787768] [<ffffffff81628295>] i915_gem_object_pin+0xb5/0xd0 > [48126.787772] [<ffffffff81629a4c>] i915_gem_do_execbuffer+0x6cc/0x14f0 > [48126.787777] [<ffffffff81091ba0>] ? __is_ram+0x0/0x10 > [48126.787783] [<ffffffff8106c76e>] ? lookup_memtype+0xce/0xe0 > [48126.787787] [<ffffffff8162ab11>] ? i915_gem_execbuffer+0x91/0x390 > [48126.787790] [<ffffffff8162ac55>] i915_gem_execbuffer+0x1d5/0x390 > [48126.787794] [<ffffffff816255b0>] ? i915_gem_sw_finish_ioctl+0x90/0xc0 > [48126.787799] [<ffffffff81565a0a>] drm_ioctl+0x32a/0x4b0 > [48126.787802] [<ffffffff8162aa80>] ? i915_gem_execbuffer+0x0/0x390 > [48126.787807] [<ffffffff8116c248>] vfs_ioctl+0x38/0xd0 > [48126.787810] [<ffffffff8116c87a>] do_vfs_ioctl+0x8a/0x580 > [48126.787814] [<ffffffff8116cdf1>] sys_ioctl+0x81/0xa0 > [48126.787820] [<ffffffff8103af02>] system_call_fastpath+0x16/0x1b > David, I have a vague feeling that we've been round this loop before.. Why does agp_alloc_page_array() use __GFP_NORETRY? It's pretty unusual and it's what caused this spew. There's nothing in the changelog and the only relevant commentary appears to be "This speeds things up and also saves memory for small AGP regions", which is inscrutable. Can you please add a usable comment there? Presumably this was added in response to some observed behaviour, but what was it?? If the __GFP_NORETRY is indeed useful and legitimate and given that we have a vmalloc fallback, I'd suggest that we add __GFP_NOWARN there as well to keep the bug reports away. btw, agp_memory.vmalloc_flag can be done away with - it's conventional to use is_vmalloc_addr() for this.

3 6

← Newer
1
...
14
15
16
17
18
19
20
...
24
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2010