When switching between antialiased and non-antialiased rendering a few times, sometimes the red spot in Java2Demo's BullsEys demo is rendered cyan. This sometimes happens quite often, sometimes takes a while As this is with the "old" Java2D backend, what Java2D does is to issue thousands of small GetImage requests - at a larger size it takes several seconds for the demo to draw it a single time. I also noticed corrupted text, which is also rendered by Java2D's software fallbacks. This is on: Fedora 16 + latest updates intel git i945GM
Created attachment 57417 [details] screenshot of the cyan spot
forgot to mention: When I save a screenshot using xfce's screenshot utility, the spot is saved as red - although it is shown as cyan on screen. I don't think the screenshot-tool causes a repaint (as it would take a few seconds) - so I don't really know what is going on here.
I'm not sure what's going on there either ;-) The non-antialiased bulls-eye is just draw with lots of GetImage; PutImage and so is hideously slow and I can't see anyway of improving that - the time just seems to be mostly lost in comms overhead between GPU, ddx and client. So how that ends up with a colour shift, I've no idea, but as you indicate that's not the first example I've seen whilst using your java demos. No closer to the answer though.
The old Java2D backend will hopefully be soon replaced by its Xrender based counterpart, which is enabled by default in java8 - however I have to fix a few things until its ready for prime time ;) Those java related bugs are really low priority, I am only reporting those because of its obscure useage patterns the java pipeline exposes bugs maybe causing problem elsewhere too. I created some screencasts: Red spot turning cyan (with some violett below): http://www.youtube.com/watch?v=YgqVXwB8u64 Screenshot of cyan spot beeing red (!?): http://www.youtube.com/watch?v=6mr5qqAJSxY The screenshot thing is really weird, I can't imagine an expose is issued - as slow as its drawn it would be visible. However, in the screenshot, the spot is red - on screen its cyan.
The sequence of events should be something like: GetImage -> create shadow pixmap, copy roi from GPU to shadow, copy to client PutImage -> copy from client into shadow ...repeat... at vblank, or upon use elsewhere: upload dirty pixels from shadow to GPU The fact that the screenshot shows red implies that the shadow contains the correct values, so it is somewhere in the copy to the GPU. The copy can be done in two modes (with a few minor variations just for fun): upload in place (if the bo is idle) or perform an indirect upload by copying into a temporary buffer and then blitting onto the GPU bo (if the bo is busy). The goal is share that temporary buffer with many operations and try to copy the data into with the minimum of fuss and cache pollution (hence there are a few methods employed depending upon the state of the temporary buffer). None of which explains just where it goes wrong.
In the case there are no other, more interesting bugs to fix ;) - I did a debug=full run and uploaded the result here: http://93.83.133.214/Xorg.0.log.7z Usually it takes a few tries until I get a cyan center, however with this run even the first non-antialiased run was cyan - so the first put/getimage storm related to the BullsEye in the log should already already triggered the problem. (The antialiased rendering before is done in 32x32 tiles if I remember corrently). Execpt for 1-2 tries I always got cyan centers, or at least a few cyan pixels. I also saw the corrupted text shown in the video - however as its just another get/putimage pair, it might be the same problem.
Another clue: using the vmap paths on gen3 (requires kernel support) I have not observed another failure. Definitely something going astray in the upload into the GTT.
GOTCHA! commit 599cd0e8ef3080fc735860bef4e47107c1c05f9a Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Mar 2 20:18:32 2012 +0000 sna: Align allocations with partial buffers to 64 bytes. A magic number required for so many functions of the GPU. In this particular case it is likely to be that the offset of a texture in the GTT has to have a minimum alignment of 64 bytes. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46415 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Thanks for fixing this issue =)
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.