dri-devel September 2012

dri-devel@lists.freedesktop.org

134 participants
706 discussions

[Bug 30122] New: r600 scrambled render when using 2d texture sample for 1d texture co-ord in fragment shader
by bugzilla-daemon＠freedesktop.org 12 Sep '12

12 Sep '12

https://bugs.freedesktop.org/show_bug.cgi?id=30122 Summary: r600 scrambled render when using 2d texture sample for 1d texture co-ord in fragment shader Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: thomas.jones(a)utoronto.ca Created an attachment (id=38612) --> (https://bugs.freedesktop.org/attachment.cgi?id=38612) small program that triggers the bug Using a shader like this results in a strange scrambled rendering: uniform sampler2D src; uniform sampler1D pal; void main() { gl_FragColor = texture1D(pal, texture2D(src, gl_TexCoord[0].xy).x); } it looks like in addition to just being messed up it also gets the texture co-ordinates wrong (I'm rending with GL_QUADS, the two triangles that make up the quad seem to be interpolating differently across the middle) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 6

Memory eviction in ttm
by Maarten Lankhorst 12 Sep '12

12 Sep '12

Hey Thomas, I'm playing around with moving reservations from ttm to global, but how ttm ttm is handling reservations is getting in the way. The code wants to move the bo from the lru lock at the same time a reservation is made, but that seems to be slightly too strict. It would really help me if that guarantee is removed. Is it true that only the ttm_mem_evict code depends on it? And in that case wouldn't it be better to attempt to free any buffer that can be reserved without blocking first, instead of blocking on the first entry in the list? This would make integration a lot easier, since I could wait with taking the lru lock until after reservation is complete, or any time before unreserving. ~Maarten

2 2

[PATCH] nouveau: Fix kernel log mangling
by Daniel J Blueman 12 Sep '12

12 Sep '12

Add missing newline to prevent the following kernel log line getting appended to the currnet one. Signed-off-by: Daniel J Blueman <daniel(a)quora.org> --- drivers/gpu/drm/nouveau/nouveau_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/drivers/gpu/drm/nouveau/nouveau_dp.c index 7e289d2..2a9294f 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dp.c +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c @@ -61,7 +61,7 @@ auxch_init(struct drm_device *dev, int ch) ctrl = nv_rd32(dev, 0x00e4e4 + (ch * 0x50)); udelay(1); if (!timeout--) { - AUX_ERR("begin idle timeout 0x%08x", ctrl); + AUX_ERR("begin idle timeout 0x%08x\n", ctrl); return -EBUSY; } } while (ctrl & 0x03010000); -- 1.7.10.4

1 0

[PATCH 3/9] drivers/gpu/drm/ttm/ttm_page_alloc_dma.c: Remove useless kfree
by Peter Senna Tschudin 12 Sep '12

12 Sep '12

From: Peter Senna Tschudin <peter.senna(a)gmail.com> Remove useless kfree() and clean up code related to the removal. The semantic patch that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r exists@ position p1,p2; expression x; @@ if (x@p1 == NULL) { ... kfree@p2(x); ... return ...; } @unchanged exists@ position r.p1,r.p2; expression e <= r.x,x,e1; iterator I; statement S; @@ if (x@p1 == NULL) { ... when != I(x,...) S when != e = e1 when != e += e1 when != e -= e1 when != ++e when != --e when != e++ when != e-- when != &e kfree@p2(x); ... return ...; } @ok depends on unchanged exists@ position any r.p1; position r.p2; expression x; @@ ... when != true x@p1 == NULL kfree@p2(x); @depends on !ok && unchanged@ position r.p2; expression x; @@ *kfree@p2(x); // </smpl> Signed-off-by: Peter Senna Tschudin <peter.senna(a)gmail.com> --- drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c index 4f9e548..969d765 100644 --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c @@ -1060,7 +1060,7 @@ int ttm_dma_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages) _manager = kzalloc(sizeof(*_manager), GFP_KERNEL); if (!_manager) - goto err_manager; + goto err; mutex_init(&_manager->lock); INIT_LIST_HEAD(&_manager->pools); @@ -1078,9 +1078,6 @@ int ttm_dma_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages) } ttm_dma_pool_mm_shrink_init(_manager); return 0; -err_manager: - kfree(_manager); - _manager = NULL; err: return ret; }

1 0

[Bug 31246] New: Reproducible hangs on piglit tests with 5850
by bugzilla-daemon＠freedesktop.org 12 Sep '12

12 Sep '12

https://bugs.freedesktop.org/show_bug.cgi?id=31246 Summary: Reproducible hangs on piglit tests with 5850 Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: temp9476-freedesktop(a)yahoo.no Ignoring the occasional random hang, I have found that the following tests create a lockup of the system every time: glsl-fs-main-return glsl-vs-main-return glsl-max-varyings glsl-fs-vec4-indexing-temp-dst-in-nested-loop-combined glsl-vs-vec4-indexing-temp-dst-in-nested-loop-combined How would I go about debugging these further? It would be very nice if the piglit tests would at least fail, not hang... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 9

[Bug 30693] New: [R600c KWin 4.5.2] Blur does not work with RV670 (it works with RV710)
by bugzilla-daemon＠freedesktop.org 12 Sep '12

12 Sep '12

https://bugs.freedesktop.org/show_bug.cgi?id=30693 Summary: [R600c KWin 4.5.2] Blur does not work with RV670 (it works with RV710) Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: darkbasic4(a)gmail.com Created an attachment (id=39272) --> (https://bugs.freedesktop.org/attachment.cgi?id=39272) Blur not working Hi, with 2.6.36-rc7|drm-radeon-testing and latest graphic stack snapshot kwin's 4.5.2 blur effect does not work. I have an HD3870, but someone else told me it works with RV710 (http://www.phoronix.com/forums/showthread.php?t=26221). I attached a screenshot. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 13

[Bug 25871] nearest neighbour samples wrong texel (precision/rounding problem)
by bugzilla-daemon＠freedesktop.org 12 Sep '12

12 Sep '12

https://bugs.freedesktop.org/show_bug.cgi?id=25871 --- Comment #11 from Andreas Boll <andreas.boll.dev(a)gmail.com> 2012-09-12 13:56:46 UTC --- (In reply to comment #10) > > It's so long ago I don't remember the exact details. You can easily figure it > out though. The test program creates a 4x4 checker board texture and then uses > a single point on it to draw the triangles. The range [0.25,0.5[ should all be > the same color. The bug was that as you approached 0.5, it started sampling the > next pixel prematurely. > > So change the fragment program to use coordinate 0.4 or something like that. > That colour should be the same as 0.4999... . Looking at the code, white seems > to be the correct colour. Ok I've got it. With coordinate 0.4 I get a white color and with 0.4999 I get black. Additionally I checked the other end of the range: Between the range [0.2480468676,0.498046860099] the color is white. If I change the fragment program to use coordinate 0.2480468675 then the color is black. With 0.4980468601 I get also black. So the issue persists in git mesa master 9.1-devel (git-e81ee67) -- 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 25871] nearest neighbour samples wrong texel (precision/rounding problem)
by bugzilla-daemon＠freedesktop.org 12 Sep '12

12 Sep '12

https://bugs.freedesktop.org/show_bug.cgi?id=25871 --- Comment #10 from Pierre Ossman <pierre-bugzilla(a)ossman.eu> 2012-09-12 13:03:19 UTC --- (In reply to comment #7) > > What is the expected behavior? It's so long ago I don't remember the exact details. You can easily figure it out though. The test program creates a 4x4 checker board texture and then uses a single point on it to draw the triangles. The range [0.25,0.5[ should all be the same color. The bug was that as you approached 0.5, it started sampling the next pixel prematurely. So change the fragment program to use coordinate 0.4 or something like that. That colour should be the same as 0.4999... . Looking at the code, white seems to be the correct colour. -- 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 25871] nearest neighbour samples wrong texel (precision/rounding problem)
by bugzilla-daemon＠freedesktop.org 12 Sep '12

12 Sep '12

https://bugs.freedesktop.org/show_bug.cgi?id=25871 --- Comment #9 from Andreas Boll <andreas.boll.dev(a)gmail.com> 2012-09-12 12:34:21 UTC --- (In reply to comment #8) > might be fixed with this commit: > http://cgit.freedesktop.org/mesa/mesa/commit/?id=f44bda17f515c411071ca8744e… I can't see any difference between mesa git master and mesa 8.0.4 . What is the expected behavior? -- 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 51344] New: massive corruption on RV515
by bugzilla-daemon＠freedesktop.org 12 Sep '12

12 Sep '12

https://bugs.freedesktop.org/show_bug.cgi?id=51344 Bug #: 51344 Summary: massive corruption on RV515 Classification: Unclassified Product: DRI Version: XOrg CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: bugzi11.fdo.tormod(a)xoxy.net Created attachment 63356 --> https://bugs.freedesktop.org/attachment.cgi?id=63356 Xorg.0.log This happened early May on drm-next somewhere between 4f256e8..d3029b4, and is still there in 3.5rc3 (and in current drm-next). Things are smeared out vertically. Looks like desktop background is not corrupted. By turning off "EXABitmaps" there is less corruption. I haven't done git bisecting, only download bisecting from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/ and v3.4-rc6-295-g4f256e8 from May 8th was good and v3.4-rc6-315-gd3029b4 from May 10th was bad. Unfortunately the build from May 9th has been deleted in the meantime so I can not narrow it down further this way. So the commits in question should be: d3029b4 drm/radeon/kms: fix warning on 32-bit in atomic fence printing f2e3922 drm/radeon: make the ib an inline object f237750 drm/radeon: remove r600 blit mutex v2 68470ae drm/radeon: move the semaphore from the fence into the ib 7c0d409 drm/radeon: immediately free ttm-move semaphore c507f7e drm/radeon: rip out the ib pool a8c0594 drm/radeon: simplify semaphore handling v2 c3b7fe8 drm/radeon: multiple ring allocator v3 0085c950 drm/radeon: use one wait queue for all rings add fence_wait_any v2 557017a drm/radeon: define new SA interface v3 2e0d991 drm/radeon: make sa bo a stand alone object e6661a9 drm/radeon: keep start and end offset in the SA 711a972 drm/radeon: add sub allocator debugfs file a651c55 drm/radeon: add proper locking to the SA v3 dd8bea2 drm/radeon: use inline functions to calc sa_bo addr 8a47cc9 drm/radeon: rework locking ring emission mutex in fence deadlock detection v2 3b7a2b2 drm/radeon: rework fence handling, drop fence list v7 bb63556 drm/radeon: convert fence to uint64_t v4 d6999bc drm/radeon: replace the per ring mutex with a global one 133f4cb drm/radeon: fix possible lack of synchronization btw ttm and other ring 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI Radeon Mobility X700 (PCIE) [1002:5653] -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 13

← Newer
1
...
56
57
58
59
60
61
62
...
71
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2012