The bottom square and number in the mesa demo arbocclude are rendering red. It seems r600c has been doing this for some time, bith swrasts are OK and before this commit r600g got it right also. e7ec53273547335863b2377bea9d35aa9c114c6b is the first bad commit commit e7ec53273547335863b2377bea9d35aa9c114c6b Author: Mathias Fröhlich <Mathias.Froehlich@web.de> Date: Sun Jan 23 22:16:56 2011 +0100 r600g: Implement asyncronous query results.
(In reply to comment #0) Forgot to say this is with d-r-t kernel and git ddx on a rv790.
Is this still an issue with the latest mesa from git master?
for me even llvmpipe shows bottom square and corresponding text as red Using mesa (llvmpipe/r600g) up to commit 7d9e0ea7393c14cbf2d58364726951b14e0d4fc7 (glx: Properly check for a valid fd in dri2CreateScreen().)
(In reply to comment #2) > Is this still an issue with the latest mesa from git master? Yes it's still the same.
I don't think this is a bug, its just how the demo works, it paints red if the results aren't ready when first asked, which is perfectly within spec from what I can see.
(In reply to comment #5) > Dave Airlie wrote: > I don't think this is a bug, its just how the demo works, it paints red if the > results aren't ready when first asked, which is perfectly within spec from what > I can see. I can reproduce the same result: with softpipe all squares have the same color with llvmpipe and r600g the bottom square is red Should we close this bug as NOTABUG?
Created attachment 67045 [details] screenshot with softpipe
Created attachment 67046 [details] screenshot with llvmpipe, r600g
(In reply to comment #5) > I don't think this is a bug, its just how the demo works, it paints red if > the results aren't ready when first asked, which is perfectly within spec > from what I can see. Closing as per the comment above.
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.