Created attachment 29999 [details] Screenshot showing the artifacts I have an application based on clutter-gst that I am using for media playback. In software mode (although slow) and on Intel G35 the app displays fine. However, when run on r600 (rv635 in my case) the initial image is pretty good, but when scaled I start getting noise in the image, perhaps a rounding error somewhere? The test application can be fetched from SVN svn checkout http://fosfor.googlecode.com/svn/trunk/ fosfor-read-only It requires, clutter 1.0, clutter gtk 0.10, clutter gst 0.10 and gtk 2.16 (Fedora rawhide statisfies all these requirements) The good news is that the corruption used to be much much worse, and this is almost perfect. If you don't want to install the test app, I am willing to try mesa patches and report good or bad results.
I found that I get fewer artifacts using the 2.6.32-rc1 + drm_next kernels than if I use just the drm_next kernel. And those kernels should be quite close with regards to r600.
Created attachment 30129 [details] Same video but running with drm-next kernel vs the linux-2.6 + drm-next kernel There seems to be much more noise in the drm-next kernel. Also the 2d and 3d performance of the system is MUCH better with drm-next, so I'm not sure why linux-2.6 is so different.
Below is the fragment program it uses: Currently we don't set barrier bit on any of these tex intructions as they don't depend on any prev ins. However they write to same dest, so I guess the result may get overwritten sometimes... # Fragment Program/Shader 0: TEX TEMP[0].y, INPUT[4], texture[0], 2D; 1: ADD TEMP[0].x, TEMP[0].yyyy, CONST[0].-z-z-z-z; 2: TEX TEMP[0].y, INPUT[4], texture[2], 2D; 3: ADD TEMP[0].z, TEMP[0].yyyy, CONST[1].-x-x-x-x; 4: MUL TEMP[0].x, TEMP[0], CONST[0].yyyy; 5: MAD OUTPUT[1].z, TEMP[0], CONST[0].wwww, TEMP[0].xxxx; 6: TEX TEMP[0].y, INPUT[4], texture[1], 2D; 7: ADD TEMP[0].y, TEMP[0], CONST[1].-x-x-x-x; 8: MAD TEMP[0].z, TEMP[0].-x-y-z-w, CONST[1].yyyy, TEMP[0].xxxx; 9: MAD OUTPUT[1].y, TEMP[0].-x-y-z-w, CONST[1].zzzz, TEMP[0].zzzz; 10: MAD OUTPUT[1].x, TEMP[0].yyyy, CONST[1].wwww, TEMP[0]; 11: MOV OUTPUT[1].w, CONST[0].xxxx; 12: END As a workarond for now, you can try: diff --git a/src/mesa/drivers/dri/r600/r700_assembler.c b/src/mesa/drivers/dri/r600/r700_assembler.c index 903b696..139a122 100644 --- a/src/mesa/drivers/dri/r600/r700_assembler.c +++ b/src/mesa/drivers/dri/r600/r700_assembler.c @@ -686,7 +686,7 @@ GLboolean add_tex_instruction(r700_AssemblerBase* pAsm, // If this clause constains any TEX instruction that is dependent on a previous instruction, // set the barrier bit - if( pAsm->pInstDeps[pAsm->uiCurInst].nDstDep > (-1) || pAsm->need_tex_barrier == GL_TRUE ) + if(1 || pAsm->pInstDeps[pAsm->uiCurInst].nDstDep > (-1) || pAsm->need_tex_barrier == GL_TRUE ) { pAsm->cf_current_tex_clause_ptr->m_Word1.f.barrier = 0x1; }
Andre, That patch did make things work much better. Can we get something along this merged into master. Is there any way to detect if the texture is in use and if so, set the bit?
Should be fixed in 869e20bcb7db9c6540eb6b538104303df738d302 7_6_branch currently
commit f8bee0e412ef1e8d5aed884561999fd1bd182494 Merge: 5e77b61 1f5b568 Author: Alex Deucher <alexdeucher@gmail.com> Date: Thu Oct 22 12:29:36 2009 -0400 Merge branch 'master' of git+ssh://agd5f@git.freedesktop.org/git/mesa/mesa Appears to have fixed this issue... Thank you...
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.