https://bugs.freedesktop.org/show_bug.cgi?id=60802
Priority: medium Bug ID: 60802 Assignee: dri-devel@lists.freedesktop.org Summary: Kernel 3.8-rc7 breaks rendering on Radeon (confirmed on Cayman) Severity: normal Classification: Unclassified OS: All Reporter: alexandre.f.demers@gmail.com Hardware: Other Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI
Since temporary fix for bug 58354, I'm able to test some applications once again and I've found out some rendering issues. In Unigine Tropics, Unigine Heaven and under another test that used to be OK (I'll come back with its name soon, I think it was Amnesia's render test), some textures are not rendered correctly with kernel 3.8-rc7 (vanilla), but are OK with kernel 3.7.7 from Archlinux 64. I'm pretty sure an earlier 3.8-rcX was rendering OK with the "still unamed" application.
I'm testing with latest mesa and drm on a XFX HD6950.
I'll try to bisect it later.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #1 from Alexandre Demers alexandre.f.demers@gmail.com --- It seems I'll have to bisect because even 3.8-rc1 displays the corruption. I'm attaching a screenshot from RendererFeattest as a corrupted reference.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #2 from Alexandre Demers alexandre.f.demers@gmail.com --- Created attachment 74793 --> https://bugs.freedesktop.org/attachment.cgi?id=74793&action=edit Corrupted texture on background
But the texture on the cubes seems to be ok
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #3 from Alexandre Demers alexandre.f.demers@gmail.com --- (In reply to comment #2)
Created attachment 74793 [details] Corrupted texture on background
But the texture on the cubes seems to be ok
The text is also corrupted
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #4 from Alexandre Demers alexandre.f.demers@gmail.com --- bisected and first bad commit is: 8696e33f06b0c52195152cc6a0e3d52233f486c1 commit 8696e33f06b0c52195152cc6a0e3d52233f486c1 Author: Alex Deucher alexander.deucher@amd.com Date: Thu Dec 13 18:57:07 2012 -0500
drm/radeon: bump version for CS ioctl support for async DMA
Signed-off-by: Alex Deucher alexander.deucher@amd.com
https://bugs.freedesktop.org/show_bug.cgi?id=60802
Alexandre Demers alexandre.f.demers@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Kernel 3.8-rc7 breaks |(bisect |rendering on Radeon |8696e33f06b0c52195152cc6a0e |(confirmed on Cayman) |3d52233f486c1) Kernel | |3.8-rc7 breaks rendering on | |Radeon (confirmed on | |Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=60802
Alex Deucher agd5f@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|(bisect |Corruption with DMA ring on |8696e33f06b0c52195152cc6a0e |cayman |3d52233f486c1) Kernel | |3.8-rc7 breaks rendering on | |Radeon (confirmed on | |Cayman) | Product|DRI |Mesa Component|DRM/Radeon |Drivers/Gallium/r600
--- Comment #5 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #4)
bisected and first bad commit is: 8696e33f06b0c52195152cc6a0e3d52233f486c1 commit 8696e33f06b0c52195152cc6a0e3d52233f486c1 Author: Alex Deucher alexander.deucher@amd.com Date: Thu Dec 13 18:57:07 2012 -0500
drm/radeon: bump version for CS ioctl support for async DMA Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
That just enables the use of DMA by the 3D driver, so the issue is in mesa. This looks like a duplicate of bug 60236.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #6 from Alexandre Demers alexandre.f.demers@gmail.com --- (In reply to comment #5)
(In reply to comment #4)
bisected and first bad commit is: 8696e33f06b0c52195152cc6a0e3d52233f486c1 commit 8696e33f06b0c52195152cc6a0e3d52233f486c1 Author: Alex Deucher alexander.deucher@amd.com Date: Thu Dec 13 18:57:07 2012 -0500
drm/radeon: bump version for CS ioctl support for async DMA Signed-off-by: Alex Deucher <alexander.deucher@amd.com>That just enables the use of DMA by the 3D driver, so the issue is in mesa. This looks like a duplicate of bug 60236.
You are right, that's what I thought about the bad identified commit.
I don't have the same symptoms as in bug 60236, but I'll have a look anyway. Otherwise, I'll use kernel 3.8-rc7 and I'll bisect mesa to track the bug down.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #7 from Alexandre Demers alexandre.f.demers@gmail.com --- So I followed bug 60236. I sync mesa since the proposed mesa patch had already been pushed. I tested with kernel 3.8.0 and the bug was still there. I then applied the proposed kernel patch over 3.8.0 (after fixing it because it was not properly applying), built and restarted using this newly built kernel.
Result: the bug is still there and the same. So this bug is not the same as bug 60236.
I'll try to bisect mesa in the next couple of days.
BTW, I bought Bastion on Steam and tested it. The same bug appears (or not exactly as for the demos depending of the kernel I was using), so it is not limited to some demo cases.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #8 from Alexandre Demers alexandre.f.demers@gmail.com --- Culprit commit in mesa identified as:
325422c49449acdd8df1eb2ca8ed81f7696c38cc is the first bad commit commit 325422c49449acdd8df1eb2ca8ed81f7696c38cc Author: Jerome Glisse jglisse@redhat.com Date: Mon Jan 7 17:45:59 2013 -0500
r600g: add async for staging buffer upload v2
v2: Add virtual address to dma src/dst offset for cayman
Signed-off-by: Jerome Glisse jglisse@redhat.com
:040000 040000 4ef6e784f3acb7f21da0c5e1923810c78917d16d 55f0ce7d9793ce04d392fc7943059545053a9d79 M src
So, it is the same commit as for bug 60236, but applying patches from it doesn't help.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #9 from Jakob Nixdorf flocke@shadowice.org --- I got similar looking corruptions in Counter Strike: Source and Trine 2 (via Steam) since my update from kernel 3.7.9 to 3.8.0 this morning (Arch Linux x86_64, newest mesa from git).
When I get back from the university I will check if I can confirm your commit as the culprit.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #10 from Jakob Nixdorf flocke@shadowice.org --- Ok, I tested it and I can confirm commit 325422c49449acdd8df1eb2ca8ed81f7696c38cc as the culprit for the corruption in Trine 2.
Counter Strike: Source seems to be another problem, I will bisect it tomorrow and open a new bug for it.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #11 from Alexandre Demers alexandre.f.demers@gmail.com --- I also noticed this in dmesg: [ 3385.870124] radeon 0000:01:00.0: GPU fault detected: 146 0x0005d004 [ 3385.870138] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00002400 [ 3385.870146] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x050D0004 [ 3385.870153] radeon 0000:01:00.0: GPU fault detected: 146 0x0005a004 [ 3385.870160] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ 3385.870165] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 [ 3385.870172] radeon 0000:01:00.0: GPU fault detected: 146 0x0005e004 [ 3385.870178] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ 3385.870183] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 [ 3385.870189] radeon 0000:01:00.0: GPU fault detected: 146 0x0025a004 [ 3385.870195] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ 3385.870200] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 [ 3385.870206] radeon 0000:01:00.0: GPU fault detected: 146 0x00059004 [ 3385.870211] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ 3385.870217] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 [ 3385.870223] radeon 0000:01:00.0: GPU fault detected: 146 0x0065e004 [ 3385.870228] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ 3385.870233] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 [ 3385.870239] radeon 0000:01:00.0: GPU fault detected: 146 0x0035a004 [ 3385.870245] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ 3385.870250] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 [ 3385.870256] radeon 0000:01:00.0: GPU fault detected: 146 0x0075e004 [ 3385.870261] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ 3385.870267] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 [
I don't know exactly for how long it has been happening, but this recent for sure since it was not there about 2 weeks ago.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #12 from Jakob Nixdorf flocke@shadowice.org --- I got this too, but this was already there before I updated to the 3.8.0 kernel. So I think it has nothing to do with this problem.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #13 from Alexandre Demers alexandre.f.demers@gmail.com --- (In reply to comment #12)
I got this too, but this was already there before I updated to the 3.8.0 kernel. So I think it has nothing to do with this problem.
Thanks for letting me know. I may know an already opened bug about it...
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #14 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #11)
I also noticed this in dmesg: [ 3385.870124] radeon 0000:01:00.0: GPU fault detected: 146 0x0005d004 [ 3385.870138] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00002400 [ 3385.870146] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x050D0004 [ 3385.870153] radeon 0000:01:00.0: GPU fault detected: 146 0x0005a004 [ 3385.870160] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ 3385.870165] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 [ 3385.870172] radeon 0000:01:00.0: GPU fault detected: 146 0x0005e004 [ 3385.870178] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ 3385.870183] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 [ 3385.870189] radeon 0000:01:00.0: GPU fault detected: 146 0x0025a004 [ 3385.870195] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ 3385.870200] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 [ 3385.870206] radeon 0000:01:00.0: GPU fault detected: 146 0x00059004 [ 3385.870211] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ 3385.870217] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 [ 3385.870223] radeon 0000:01:00.0: GPU fault detected: 146 0x0065e004 [ 3385.870228] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ 3385.870233] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 [ 3385.870239] radeon 0000:01:00.0: GPU fault detected: 146 0x0035a004 [ 3385.870245] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ 3385.870250] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 [ 3385.870256] radeon 0000:01:00.0: GPU fault detected: 146 0x0075e004 [ 3385.870261] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ 3385.870267] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 [
I don't know exactly for how long it has been happening, but this recent for sure since it was not there about 2 weeks ago.
Can you bisect mesa to see when this started?
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #15 from Alexandre Demers alexandre.f.demers@gmail.com --- Yes, I will. Should I begin by looking on the kernel's side or on mesa's side?
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #16 from Jakob Nixdorf flocke@shadowice.org --- I am currently bisecting mesa to see where the dmesg output starts.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #17 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #15)
Yes, I will. Should I begin by looking on the kernel's side or on mesa's side?
It's most likely a mesa issue.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #18 from Jakob Nixdorf flocke@shadowice.org --- Ok, just finished bisecting, this is the first commit with the dmesg errors:
e110c98cae0ceae47db6cf26c08707505ce92479 is the first bad commit commit e110c98cae0ceae47db6cf26c08707505ce92479 Author: Alex Deucher alexander.deucher@amd.com Date: Sun Jan 27 22:13:52 2013 -0500
r600g: don't emit WAIT_UNTIL on cayman/TN (v2)
It shouldn't be needed and older kernels don't support it.
v2: Replace with PS partial flush as before.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=59945
Signed-off-by: Alex Deucher alexander.deucher@amd.com Reviewed-by: Marek Olšák maraeo@gmail.com
And if I remember correctly I first noticed it with kernel 3.7.5 or 3.7.6, but I thing this was also around the time this mesa commit was pushed so it may have nothing to do with this kernel versions.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #19 from Alexandre Demers alexandre.f.demers@gmail.com --- (In reply to comment #18)
Ok, just finished bisecting, this is the first commit with the dmesg errors:
e110c98cae0ceae47db6cf26c08707505ce92479 is the first bad commit commit e110c98cae0ceae47db6cf26c08707505ce92479 Author: Alex Deucher alexander.deucher@amd.com Date: Sun Jan 27 22:13:52 2013 -0500
r600g: don't emit WAIT_UNTIL on cayman/TN (v2) It shouldn't be needed and older kernels don't support it. v2: Replace with PS partial flush as before. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=59945 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Marek Olšák <maraeo@gmail.com>And if I remember correctly I first noticed it with kernel 3.7.5 or 3.7.6, but I thing this was also around the time this mesa commit was pushed so it may have nothing to do with this kernel versions.
I'll double check if I'm getting the same thing as you. If this is right, we should open a different bug to track it.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #20 from Alexandre Demers alexandre.f.demers@gmail.com --- (In reply to comment #18)
Ok, just finished bisecting, this is the first commit with the dmesg errors:
e110c98cae0ceae47db6cf26c08707505ce92479 is the first bad commit commit e110c98cae0ceae47db6cf26c08707505ce92479 Author: Alex Deucher alexander.deucher@amd.com Date: Sun Jan 27 22:13:52 2013 -0500
r600g: don't emit WAIT_UNTIL on cayman/TN (v2) It shouldn't be needed and older kernels don't support it. v2: Replace with PS partial flush as before. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=59945 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Marek Olšák <maraeo@gmail.com>And if I remember correctly I first noticed it with kernel 3.7.5 or 3.7.6, but I thing this was also around the time this mesa commit was pushed so it may have nothing to do with this kernel versions.
I ended up with a different commit than yours when bisecting: 325422c49449acdd8df1eb2ca8ed81f7696c38cc is the first bad commit commit 325422c49449acdd8df1eb2ca8ed81f7696c38cc
It's the one just prior yours and it is also the one identified as being the culprit of the current bug (comment 8). Could you check a second time?
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #21 from Jakob Nixdorf flocke@shadowice.org --- (In reply to comment #20)
I ended up with a different commit than yours when bisecting: 325422c49449acdd8df1eb2ca8ed81f7696c38cc is the first bad commit commit 325422c49449acdd8df1eb2ca8ed81f7696c38cc
It's the one just prior yours and it is also the one identified as being the culprit of the current bug (comment 8). Could you check a second time?
I just build 325422c49449acdd8df1eb2ca8ed81f7696c38cc but I can't trigger any dmesg output. What do you use to test for it?
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #22 from Jakob Nixdorf flocke@shadowice.org --- Ok, I managed to get the dmesg output using piglit and the r600.tests, so I think this confirms 325422c49449acdd8df1eb2ca8ed81f7696c38cc as culprit.
But I think the commit I identified (e110c98cae0ceae47db6cf26c08707505ce92479) is bad too, because there I only needed to start steam to get the errors.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #23 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #22)
Ok, I managed to get the dmesg output using piglit and the r600.tests, so I think this confirms 325422c49449acdd8df1eb2ca8ed81f7696c38cc as culprit.
Can you identify the a specific piglit test that triggers the fault messages and attach the fault messages it generates?
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #24 from Jakob Nixdorf flocke@shadowice.org --- (In reply to comment #23)
Can you identify the a specific piglit test that triggers the fault messages and attach the fault messages it generates?
I won't be at my computer for awhile, but I will try as soon as I come back.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #25 from Alexandre Demers alexandre.f.demers@gmail.com --- For the info, I use a now-unavailable demo used to test features for Amnesia (RendererFeattest). It is no where to be found anymore I think. It is a quick and progressive test (starting with almost nothing and adding or testing different features on every change). I'd be happy to use piglit tests, but last time I tried a couple of weeks ago, it was still locking my computer.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #26 from Jakob Nixdorf flocke@shadowice.org --- Now that I'm back I have a question: is there any simple way to single-step through all tests in the r600.tests, or do I have to do it manually ?
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #27 from Tom Stellard tstellar@gmail.com --- (In reply to comment #26)
Now that I'm back I have a question: is there any simple way to single-step through all tests in the r600.tests, or do I have to do it manually ?
When I want to identify which test is causing a GPU hang, I pass the -c 0 option to piglit-run.py to disable concurrent tests and then run piglit over ssh. This way you can still see the terminal output after the GPU hangs.
For example:
ssh tstellar@cayman-box cd piglit DISPLAY=:0 ./piglit-run.py -c 0 tests/quick-driver-tests
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #28 from Jakob Nixdorf flocke@shadowice.org --- The first test to trigger the dmesg output is:
spec/EXT_framebuffer_multisample/accuracy
but it also causes my system to freeze (ssh too), so I have no fail message.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #29 from Alexandre Demers alexandre.f.demers@gmail.com --- I'm sure the rendering corruption comes from a wrongly set address for Cayman (not shifted correctly at some point). It reminds me of bug 38173 and its fixes.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #30 from Jakob Nixdorf flocke@shadowice.org --- What do you mean by fixed, this bug or the one you linked? Because I still get the same corruptions in Trine 2 and some textures in CS:S with the newest git version of mesa.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #31 from Alexandre Demers alexandre.f.demers@gmail.com --- (In reply to comment #30)
What do you mean by fixed, this bug or the one you linked? Because I still get the same corruptions in Trine 2 and some textures in CS:S with the newest git version of mesa.
"and its fixes" refered to the bug I linked (bug 38173). I'm also still experiencing corruption with latest git.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #32 from Alex Deucher agd5f@yahoo.com --- Created attachment 75658 --> https://bugs.freedesktop.org/attachment.cgi?id=75658&action=edit align dma commands to 8 dwords
Does this patch help? You might also try it in combination with this patch: http://lists.freedesktop.org/archives/mesa-dev/2013-February/035347.html
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #33 from Jakob Nixdorf flocke@shadowice.org --- No, I still get corruption in Trine 2 and on some CS:S textures with this patch (also in combination with the one you linked).
Should I try all 5 patches in the set you linked or only 3/5 ?
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #34 from Alexandre Demers alexandre.f.demers@gmail.com --- (In reply to comment #32)
Created attachment 75658 [details] [review] align dma commands to 8 dwords
Does this patch help? You might also try it in combination with this patch: http://lists.freedesktop.org/archives/mesa-dev/2013-February/035347.html
Tried proposed patch and the 5 patches from the link (the link and the 4 others) and still the same corruption.
However, I noticed the errors seam to have gone with latest mesa from git (no link with the patches, tested with and without them). I ran steam and RendererFeatTest64 and no error appeared in dmesg anymore. What about you Jakob?
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #35 from Jakob Nixdorf flocke@shadowice.org --- Yes, it seems the dmesg errors are gone. I will try piglit later to confirm this.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #36 from Alexandre Demers alexandre.f.demers@gmail.com --- This commit seems to have fixed the "GPU fault detected" message
62329d77b8065b5fd41179d6013c8adf6d86cfc7
Author Brian Paulbrianp@vmware.com Author date 2/25/13 8:00 PM Parent svga: fix comment typos Child r600g: synchronize streamout buffers on r6xx too (v3) Branch master (i965/fs: Put immediate operand as src2) Branch origin/master (i965/fs: Put immediate operand as src2) Follows snb-magic (graw: Add struct pipe_surface forward declaration.)
winsys/null: fix var typo templet->templat
Now, let's get back to the main bug: corruption. Is it me or is there a 4X4 pattern in the corruption? 2^4 or << 4
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #37 from Jakob Nixdorf flocke@shadowice.org --- Created attachment 75725 --> https://bugs.freedesktop.org/attachment.cgi?id=75725&action=edit Corruption in Trine 2
Yes it looks like some regular 4x4 pattern. I made a screenshoot of the Trine 2 startscreen with the corruption in the title and at the borders of the exit dialog.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #38 from Christian König deathsimple@vodafone.de --- (In reply to comment #37)
Created attachment 75725 [details] Corruption in Trine 2
Yes it looks like some regular 4x4 pattern. I made a screenshoot of the Trine 2 startscreen with the corruption in the title and at the borders of the exit dialog.
Is it just me or does this corruption starts to look like a tiling issue? (Do we allready use the DMA for tiling uploads?)
Is the corruption binary repeatable, e.g. does it always look the same? Or does it change allot from one run to another?
If it's the later then it's more likely that it's just random memory you see.
Christian.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #39 from Jakob Nixdorf flocke@shadowice.org --- I just started Trine 2 again and took a second picture. The corruption is definitely exactly the same.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #40 from Alexandre Demers alexandre.f.demers@gmail.com --- (In reply to comment #39)
I just started Trine 2 again and took a second picture. The corruption is definitely exactly the same.
I agree, same thing over here.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #41 from Jakob Nixdorf flocke@shadowice.org --- Just as information: I just built 3.9-rc1 and the corruption is still present and looking exactly the same.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #42 from Alexandre Demers alexandre.f.demers@gmail.com --- (In reply to comment #41)
Just as information: I just built 3.9-rc1 and the corruption is still present and looking exactly the same.
Same here, tested yesterday.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #43 from Alexandre Demers alexandre.f.demers@gmail.com --- Still getting this rendering problem with kernel 3.9.0-rc2 and today's mesa code.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #44 from vincent vljn@ovi.com --- I think I have similar issue with Unigine Heaven 3.0 :
http://people.freedesktop.org/~vlj/00002.jpg http://people.freedesktop.org/~vlj/00003.jpg
A webgl demo that has the issue too is at http://www.findyourwaytooz.com/
It appeared with Kernel 3.8 too. Kernel 3.7.9 did have this.
With a previous Mesa there was the same kind of issue with Lightmark, but with latest mesa it is gone ; maybe the remaining corruption is related to compressed textures ?
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #45 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #44)
It appeared with Kernel 3.8 too. Kernel 3.7.9 did have this.
The DMA rings are only available on 3.8 kernels.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #46 from Alexandre Demers alexandre.f.demers@gmail.com --- (In reply to comment #44)
I think I have similar issue with Unigine Heaven 3.0 :
http://people.freedesktop.org/~vlj/00002.jpg http://people.freedesktop.org/~vlj/00003.jpg
A webgl demo that has the issue too is at http://www.findyourwaytooz.com/
It appeared with Kernel 3.8 too. Kernel 3.7.9 did have this.
With a previous Mesa there was the same kind of issue with Lightmark, but with latest mesa it is gone ; maybe the remaining corruption is related to compressed textures ?
Your screenshots are very similar to what I see with other Unigine's demos. Your webgl demo also seems to exhibit the same corruption issue. I would say you are right about some specific kind of textures not being correctly rendered, while others are. What kind exactly is to be determined.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #47 from Alexandre Demers alexandre.f.demers@gmail.com --- So I played with libtxc (removed it in fact) and tested some demos again. For those that were not completely relying on libtxc, I observed the following: - textures not related to libtxc were displayed correctly - textures related to libtxc were not displayed AND were corresponding to the corrupted textures seen when libtxc was available.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #48 from Anthony Waters awaters1@gmail.com --- I looked into this a little bit and the issue appears to be within evergreen_dma_copy_tile within evergreen_state.c. It looks like when bank_h is 0 it causes the texture to appear bad, but bank_h is allowed to be 0 so I believe the lines cs->buf[cs->cdw++] = (detile << 31) | (array_mode << 27) | (lbpp << 24) | (bank_h << 21) | (bank_w << 18) | (mt_aspect << 16); have the incorrect offsets, but I'm not 100% sure at the moment.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #49 from Anthony Waters awaters1@gmail.com --- Looked into it a bit more and it appears that when bpp is 16 there is a bad texture, I'll see if I can figure it out more later on.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #50 from Anthony Waters awaters1@gmail.com --- I believe I have the source of the bug, it appears that there is a special case for Caymen GPUs that isn't handled in the DMA code path. In evergreen_state.c within the method evergreen_create_sampler_view_custom there is the chunk of code
/* 128 bit formats require tile type = 1 */ if (rscreen->chip_class == CAYMAN) { if (util_format_get_blocksize(pipe_format) >= 16) non_disp_tiling = 1; }
however, within evergreen_dma_copy_tile in the same source file no such code exists. I tested whether this was the case or not by placing the lines of code
if (util_format_get_blocksize(dst->format) >= 16) { printf("Caymen non disp tiling skipping dma tile\n"); return FALSE; }
before the call to evergreen_dma_copy_tile in evergreen_dma_blit, and the corruption no longer appeared. (having this checks skips the DMA path for this case and goes through the normal path, which would be evergreen_create_sampler_view_custom I believe)
I'm not sure which bits in the DMA packet control this setting.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #51 from Alex Deucher agd5f@yahoo.com --- Created attachment 76544 --> https://bugs.freedesktop.org/attachment.cgi?id=76544&action=edit set non_disp tiling bit for cayman
Good catch! I believe the attached patch should fix the issue.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #52 from Alexandre Demers alexandre.f.demers@gmail.com --- (In reply to comment #51)
Created attachment 76544 [details] [review] set non_disp tiling bit for cayman
Good catch! I believe the attached patch should fix the issue.
I don't know for others, but it doesn't fix the corruption over here.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #53 from Alexandre Demers alexandre.f.demers@gmail.com --- (In reply to comment #50)
I believe I have the source of the bug, it appears that there is a special case for Caymen GPUs that isn't handled in the DMA code path. In evergreen_state.c within the method evergreen_create_sampler_view_custom there is the chunk of code
/* 128 bit formats require tile type = 1 */ if (rscreen->chip_class == CAYMAN) { if (util_format_get_blocksize(pipe_format) >= 16) non_disp_tiling = 1; }
however, within evergreen_dma_copy_tile in the same source file no such code exists. I tested whether this was the case or not by placing the lines of code
if (util_format_get_blocksize(dst->format) >= 16) { printf("Caymen non disp tiling skipping dma tile\n"); return FALSE; }before the call to evergreen_dma_copy_tile in evergreen_dma_blit, and the corruption no longer appeared. (having this checks skips the DMA path for this case and goes through the normal path, which would be evergreen_create_sampler_view_custom I believe)
I'm not sure which bits in the DMA packet control this setting.
Your observations are right, using your trick does indeed remove the corruptions.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #54 from Alexandre Demers alexandre.f.demers@gmail.com --- (In reply to comment #51)
Created attachment 76544 [details] [review] set non_disp tiling bit for cayman
Good catch! I believe the attached patch should fix the issue.
Since this bug is pretty much the same as previous one I had identified in comment 29 (pointing to bug 38173) and since the proposed patch is also pretty similar to 1 of the 2 patches needed to fix that identified bug, is it possible there is something missing that would look like the second patch that was needed?
patch 1 from bug 38173 (similar to the one proposed with your attachment 76544): http://cgit.freedesktop.org/mesa/mesa/commit/?id=5e1495b2d9311fa2b320766a1d2... patch 2 from bug 38173 (possibly similar to what is missing to complete your proposed patch): http://cgit.freedesktop.org/mesa/mesa/commit/?id=acca690c259824636ef1ff684a1...
In other words, are we sure we are offsetting the non_disp variable correctly for Cayman? Because according to the second patch, the offset was different.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
Alex Deucher agd5f@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #76544|0 |1 is obsolete| |
--- Comment #55 from Alex Deucher agd5f@yahoo.com --- Created attachment 76557 --> https://bugs.freedesktop.org/attachment.cgi?id=76557&action=edit take 2
Try this patch. The bits of the non_disp field are inverted for compatibility with evergreen.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #56 from Anthony Waters awaters1@gmail.com --- take 2 didn't work for me, I also tried (non_disp << 28) to (non_disp << 30) and those didn't fix it either.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
Alex Deucher agd5f@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #76557|0 |1 is obsolete| |
--- Comment #57 from Alex Deucher agd5f@yahoo.com --- Created attachment 76563 --> https://bugs.freedesktop.org/attachment.cgi?id=76563&action=edit take 3
Only set the non_disp bit for tiled to linear copies.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #58 from Anthony Waters awaters1@gmail.com --- That didn't work either, the L2T path is the one that keeps getting executed. In my case dst_mode is RADEON_SURF_MODE_2D or RADEON_SURF_MODE_1D and src_mode is RADEON_SURF_MODE_LINEAR_ALIGNED.
I'll see if I can get some more specifics about the issue.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #59 from Alexandre Demers alexandre.f.demers@gmail.com --- Alex, a couple of things changed in your last attachment. You removed the L2T part, you reverted the "non_disp = 2" back to "non_disp = 1" and changed the binary offset for 28 (instead of 27). Am I right to understand you set "non_disp" back to 1 because your are offsetting one more bit (according to your comment in v2)?
If that's right, I don't see how v3 is different from v2 except for the L2T change. And since non_disp=1 is not set at all in the main branch, how would that fix the corruption problem. Aren't we back to v0 for the L2T path (which is broken) and to v2 for the T2L path (which is also not better)?
https://bugs.freedesktop.org/show_bug.cgi?id=60802
Alex Deucher agd5f@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #76563|0 |1 is obsolete| |
--- Comment #60 from Alex Deucher agd5f@yahoo.com --- Created attachment 76590 --> https://bugs.freedesktop.org/attachment.cgi?id=76590&action=edit use blitter for compressed textures
This patch fixes the issue here.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #61 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #59)
Alex, a couple of things changed in your last attachment. You removed the L2T part, you reverted the "non_disp = 2" back to "non_disp = 1" and changed the binary offset for 28 (instead of 27). Am I right to understand you set "non_disp" back to 1 because your are offsetting one more bit (according to your comment in v2)?
The non_disp field is two bits on cayman and one bit evergreen. Bit 28 in this packet represents bit 0 of the non_disp field and bit 27 represents bit 1 of the non_disp field so that it's compatible with evergreen. So just setting bit 28 covers us for both evergreen and cayman since we only care about non_dip bit 0.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #62 from Alex Deucher agd5f@yahoo.com --- The way to properly handle T2L or L2T conversions of compressed textures with the DMA engine is to hack up the formats like we do in the blitter code so that it looks like a PIPE_FORMAT_R16G16B16A16_UINT or PIPE_FORMAT_R32G32B32A32_UINT T2L or L2T blit.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
Alex Deucher agd5f@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #76590|0 |1 is obsolete| |
--- Comment #63 from Alex Deucher agd5f@yahoo.com --- Created attachment 76592 --> https://bugs.freedesktop.org/attachment.cgi?id=76592&action=edit take 5
After further investigation this seems to be an alignment issue with large block sizes on the DMA engine on cayman. For now just use the blitter for large block sizes.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #64 from Alexandre Demers alexandre.f.demers@gmail.com --- (In reply to comment #63)
Created attachment 76592 [details] [review] take 5
After further investigation this seems to be an alignment issue with large block sizes on the DMA engine on cayman. For now just use the blitter for large block sizes.
It does the trick for now.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #65 from Alex Deucher agd5f@yahoo.com --- After a little more investigation this weekend, I think I found the root cause. On cayman, 128bpp surfaces require non_disp ordering for hw access to both linear and tiled surfaces. When we use the 3D engine we can set the non_disp ordering on both the tiled and linear sides (via CB or texture), but when we use the DMA engine, we can only set the non_disp ordering on the tiled side, so after a L2T operation with the DMA engine, the data ends up in the wrong order on the tiled side.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
Alex Deucher agd5f@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #66 from Alex Deucher agd5f@yahoo.com --- Pushed: http://cgit.freedesktop.org/mesa/mesa/commit/?id=4409758a046a47b09cdd339f97a...
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #67 from Alexandre Demers alexandre.f.demers@gmail.com --- (In reply to comment #66)
Pushed: http://cgit.freedesktop.org/mesa/mesa/commit/ ?id=4409758a046a47b09cdd339f97afd22107c68f0c
It seems ok over here. Thank you.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org