dri-devel August 2010

dri-devel@lists.freedesktop.org

82 participants
335 discussions

[REGRESSION] [2.6.36-rc1] [DRM INTEL] [drm:intel_calculate_wm] *ERROR* Insufficient FIFO for plane, expect flickering: entries required = 36, available = 28.
by Maciej Rutecki 19 Aug '10

19 Aug '10

Last known good: 2.6.35 Failing kernel: 2.6.36-rc1 During boot kernel display this message: [ 0.831906] [drm:intel_calculate_wm] *ERROR* Insufficient FIFO for plane, expect flickering: entries required = 36, available = 28. [ 0.895058] [drm:intel_calculate_wm] *ERROR* Insufficient FIFO for plane, expect flickering: entries required = 36, available = 28. [ 0.895066] [drm:intel_calculate_wm] *ERROR* Insufficient FIFO for plane, expect flickering: entries required = 36, available = 28. [ 0.895287] [drm:intel_calculate_wm] *ERROR* Insufficient FIFO for plane, expect flickering: entries required = 36, available = 28. [ 0.916426] [drm:intel_calculate_wm] *ERROR* Insufficient FIFO for plane, expect flickering: entries required = 36, available = 28. Systems seems work OK, but in 2.6.35 I don't have this message. On another system with 2.6.36-rc1 kernel I have the same message. lspci: http://unixy.pl/maciek/download/kernel/2.6.36-rc1/zlom/lspci.txt .config: http://unixy.pl/maciek/download/kernel/2.6.36-rc1/zlom/config-2.6.36-rc1 dmesg: http://unixy.pl/maciek/download/kernel/2.6.36-rc1/zlom/dmesg-2.6.36-rc1.txt Regards -- Maciej Rutecki http://www.maciek.unixy.pl

3 2

[PATCH] drm/radeon/kms: fix agp mode setup on cards that use pcie bridges
by Alex Deucher 18 Aug '10

18 Aug '10

Asics that use an AGP to PCIE bridge don't have the AGP_STATUS register so just use whatever mode the host side setup. Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> Cc: Jerome Glisse <glisse(a)freedesktop.org> --- drivers/gpu/drm/radeon/radeon_agp.c | 8 +++++++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_agp.c b/drivers/gpu/drm/radeon/radeon_agp.c index f40dfb7..bd2f33e 100644 --- a/drivers/gpu/drm/radeon/radeon_agp.c +++ b/drivers/gpu/drm/radeon/radeon_agp.c @@ -156,7 +156,13 @@ int radeon_agp_init(struct radeon_device *rdev) } mode.mode = info.mode; - agp_status = (RREG32(RADEON_AGP_STATUS) | RADEON_AGPv3_MODE) & mode.mode; + /* chips with the agp to pcie bridge don't have the AGP_STATUS register + * Just use the whatever mode the host sets up. + */ + if (rdev->family <= CHIP_RV350) + agp_status = (RREG32(RADEON_AGP_STATUS) | RADEON_AGPv3_MODE) & mode.mode; + else + agp_status = mode.mode; is_v3 = !!(agp_status & RADEON_AGPv3_MODE); if (is_v3) { -- 1.7.1.1

1 0

[PATCH 0/2] RFC: allow driver to plugin alternative to drm_mm
by Ben Skeggs 18 Aug '10

18 Aug '10

From: Ben Skeggs <bskeggs(a)redhat.com> In order to properly deal with GPU reordering of blocks in physical VRAM, Nouveau needs to be able to have better control over VRAM allocations. Currently nouveau is extremely wasteful and forces massive amounts of padding/alignment to avoid buffer corruption issues. radeon/vmwgfx haven't been tested, but nouveau works as well as it did previously. Ben Skeggs (2): drm/ttm: introduce utility function to free an allocated memory node drm/ttm: restructure to allow driver to plug in alternate memory manager drivers/gpu/drm/nouveau/nouveau_bo.c | 26 ++--- drivers/gpu/drm/nouveau/nouveau_channel.c | 6 +- drivers/gpu/drm/nouveau/nouveau_notifier.c | 2 +- drivers/gpu/drm/nouveau/nouveau_sgdma.c | 4 +- drivers/gpu/drm/nouveau/nv50_crtc.c | 3 +- drivers/gpu/drm/nouveau/nv50_display.c | 2 +- drivers/gpu/drm/nouveau/nv50_instmem.c | 2 +- drivers/gpu/drm/radeon/radeon_object.c | 6 +- drivers/gpu/drm/radeon/radeon_ttm.c | 34 ++----- drivers/gpu/drm/ttm/Makefile | 3 +- drivers/gpu/drm/ttm/ttm_agp_backend.c | 3 +- drivers/gpu/drm/ttm/ttm_bo.c | 104 +++++--------------- drivers/gpu/drm/ttm/ttm_bo_manager.c | 148 ++++++++++++++++++++++++++++ drivers/gpu/drm/ttm/ttm_bo_util.c | 12 +-- drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c | 3 +- include/drm/ttm/ttm_bo_api.h | 3 +- include/drm/ttm/ttm_bo_driver.h | 25 +++++- 17 files changed, 238 insertions(+), 148 deletions(-) create mode 100644 drivers/gpu/drm/ttm/ttm_bo_manager.c -- 1.7.2

3 6

[Bug 29013] New: [r300g] translate_rgb_op: unknown opcode ILLEGAL OPCODE
by bugzilla-daemon＠freedesktop.org 18 Aug '10

18 Aug '10

https://bugs.freedesktop.org/show_bug.cgi?id=29013 Summary: [r300g] translate_rgb_op: unknown opcode ILLEGAL OPCODE Product: Mesa Version: git Platform: Other OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: remi.meier(a)gmail.com Created an attachment (id=36952) --> (https://bugs.freedesktop.org/attachment.cgi?id=36952) RADEON_DEBUG="fp" output A small fragment shader produces the following output: -------------------------------------------------------------- r300: Unknown TGSI/RC opcode: CAL r300: Unknown TGSI/RC opcode: BGNSUB r300: Unknown TGSI/RC opcode: ENDSUB r300 FP: Compiler Error: r500_fragprog_emit.c::translate_rgb_op(): translate_rgb_op: unknown opcode ILLEGAL OPCODE Using a dummy shader instead. If there's an 'unknown opcode' message, please file a bug report and attach this log. -------------------------------------------------------------- The shader looks like this: -------------------------------------------------------------- vec3 floatToColor(float x) { if(x == 1.0) return vec3(0, 0, 0); } void main() { gl_FragColor.rgb = floatToColor(1); } -------------------------------------------------------------- RADEON_DEBUG="fp" output is attached -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 1

[Bug 29437] New: [r300g] glean/glsl1-function fails with unknown opcode errors
by bugzilla-daemon＠freedesktop.org 18 Aug '10

18 Aug '10

https://bugs.freedesktop.org/show_bug.cgi?id=29437 Summary: [r300g] glean/glsl1-function fails with unknown opcode errors Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: plaes(a)plaes.org Kernel: 2.6.35 Mesa: git master d64a119c28376d7ce069dcec044ff9af7f93ff9c Results for glean/glsl1-function with early return (1) Returncode: 0 Errors: r300: Unknown TGSI/RC opcode: CAL r300: Unknown TGSI/RC opcode: BGNSUB r300: Unknown TGSI/RC opcode: ENDSUB r300 FP: Compiler Error: r300_fragprog_emit.c::translate_rgb_opcode(): translate_rgb_opcode: Unknown opcode ILLEGAL OPCODE Using a dummy shader instead. If there's an 'unknown opcode' message, please file a bug report and attach this log. Output: ---------------------------------------------------------------------- GLSL test 1: test basic Shading Language functionality. glsl1: Running single test: function with early return (1) FAILURE: Shader test: function with early return (1) Expected color: 0.25, 0.25, 0.25, 0.25 Observed color: 0, 0, 0, 1 glsl1: FAIL rgba8, db, z24, s8, win+pmap, id 33 0 tests passed, 1 tests failed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 2

[Bug 26999] _mesa_reference_renderbuffer: Assertion `oldRb->Magic == 0xaabbccdd' failed
by bugzilla-daemon＠freedesktop.org 17 Aug '10

17 Aug '10

https://bugs.freedesktop.org/show_bug.cgi?id=26999 prl <prl-bugs.freedesktop.org(a)quignogs.org.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |prl-bugs.freedesktop.org@qu | |ignogs.org.uk --- Comment #7 from prl <prl-bugs.freedesktop.org(a)quignogs.org.uk> 2010-08-17 09:57:16 PDT --- Well done Julien, thanks very much. I hit this bug with KDE on Fedora 13; I'm happy to help with testing on Fedora. -- 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 26999] _mesa_reference_renderbuffer: Assertion `oldRb->Magic == 0xaabbccdd' failed
by bugzilla-daemon＠freedesktop.org 17 Aug '10

17 Aug '10

https://bugs.freedesktop.org/show_bug.cgi?id=26999 --- Comment #6 from Julien Viard de Galbert <julien(a)vdg.blogsite.org> 2010-08-17 04:13:57 PDT --- Well I don't think 'make clean' will rewrite the code, also I did build it by rebuilding the debian package, and generally this starts by a 'make clean'. Note that I did rebuild the debian package, not the latest of your code, but according to git [1] today's struct via_context has not changed much. [1] http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/unichrome/v… The problem come from the 'struct via_renderbuffer' inside this structure (line 160-164) also line 159 explicitly says it should not be here, so the writer somehow new this was not that clean. What my gdb session showed is that the 'struct via_context' get freed while there are still some reference to the 'struct via_renderbuffer'. So when the references gets cleared, the assert occurs because the referenced 'struct via_renderbuffer' has already been freed. (for more details, go and actually read my post on debian bts). Maybe the caller should not make the 'struct via_context' be freed in the first place, however 'struct via_renderbuffer' use a smart reference counting (inherited from the 'struct gl_renderbuffer') so if it was referenced properly this would not append. I propose to replace the 'struct via_renderbuffer' inside 'struct via_context' by pointers and use the proper reference counting. If this is the right direction, I'll try to provide a patch. However the comment on line 159 sound more like there should not be 'via_renderbuffer' here at all... So if someone can point me to the relevant documentation (to get more insight on how it should be done) I'll work on it. -- 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

DRI/DRM profiling for performance analysis?
by Pasi Kärkkäinen 17 Aug '10

17 Aug '10

Hello, Do we currently have a method of profiling DRI/DRM drivers? I was thinking that it would be interesting to: 1) Execute a benchmark, or some "timedemo" of a game 2) See how many times each dri/drm driver function is called, maybe top 20 most often called functions, and the total cpu time used for those functions. So you could see that: 1) some function is called often, but it doesn't take much total cpu time. 2) some function is called just a couple of times, but it takes a lot of cpu time. And everything in between.. would be good hints to use for optimizing the apps/drivers, and for comparison between different versions.. Does this make sense? -- Pasi

2 2

[PATCH] drm/radeon/kms: fix typo in radeon_compute_pll_gain
by Alex Deucher 17 Aug '10

17 Aug '10

Looks like this got copied from the ddx wrong. Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> Cc: stable(a)kernel.org --- drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c index 989df51..305049a 100644 --- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c +++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c @@ -272,7 +272,7 @@ static uint8_t radeon_compute_pll_gain(uint16_t ref_freq, uint16_t ref_div, if (!ref_div) return 1; - vcoFreq = ((unsigned)ref_freq & fb_div) / ref_div; + vcoFreq = ((unsigned)ref_freq * fb_div) / ref_div; /* * This is horribly crude: the VCO frequency range is divided into -- 1.7.1.1

1 0

headers_check warnings in drm headers
by Sam Ravnborg 16 Aug '10

16 Aug '10

When I ran "make headers_check" on upstream I got following set of warnings for the drm headers: usr/include/drm/drm_mode.h:85: found __[us]{8,16,32,64} type without #include <linux/types.h> usr/include/drm/i915_drm.h:120: found __[us]{8,16,32,64} type without #include <linux/types.h> usr/include/drm/mga_drm.h:260: found __[us]{8,16,32,64} type without #include <linux/types.h> usr/include/drm/radeon_drm.h:758: found __[us]{8,16,32,64} type without #include <linux/types.h> usr/include/drm/via_drm.h:117: found __[us]{8,16,32,64} type without #include <linux/types.h> When I looked through the files I noticed a few things: 1) Several files uses a mixture of native types and linux types. For example "unsigned int" and "__u32" in the same file. 2) drm.h contains: #if defined(__linux__) #include <linux/types.h> #include <asm/ioctl.h> typedef unsigned int drm_handle_t; #else /* One of the BSDs */ #include <sys/ioccom.h> #include <sys/types.h> typedef int8_t __s8; typedef uint8_t __u8; typedef int16_t __s16; typedef uint16_t __u16; typedef int32_t __s32; typedef uint32_t __u32; typedef int64_t __s64; typedef uint64_t __u64; typedef unsigned long drm_handle_t; #endif Why this when no-one else require this treatment? 3) Lots of typedefs... All in all - too much to dig into without knowing the background for the current state. At a minimum please get the warnings fixed. Sam

2 1

← Newer
1
...
18
19
20
21
22
23
24
...
34
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2010