The Radeon UploadToScreen for the DRI seems broken. Every time Xephyr does a full repaint, it draws outside of the window (apparently the pitch is wrong). If I turn off the DRI, it works fine. Issues I've noticed with Radeon UTS: - Rounding of the width is wrong. Unless it's in padding on the right side of the pixmap, this will result in bad rendering. - No need to do coordinate transformation. That is, unless EXA is behaving wrongly and handing too-large coordinates to the driver. That would be an EXA bug which I should fix (oops). This is a full build of Xserver, EXA, and ATI driver as of no earlier than 2005-04-25 but the behavior is long-standing.
Does this also happen with colour tiling disabled? Looks like UTS doesn't deal with tiling yet.
*** Bug 6740 has been marked as a duplicate of this bug. ***
Created attachment 5501 [details] [review] Handle tiling in UTS Does this patch fix it? Also, Eric, I'm not sure what you mean by 'Rounding of the width is wrong' and 'No need to do coordinate transformation', please elaborate.
Created attachment 5504 [details] screen shot Nope, didn't solve it. But it did change the error a bit. See attached screen shot.
Also Michel, there is something that annoys me with the way HDB works at the moment: We allocate a buffer, we fill the packet command, we call ADVANCE_RING() and then fill the data... What is causing the buffer to be picked up by the engine ? ADVANCE_RING() ? In this case, what prevents the card to start the HDB before we actually write the data to the buffer ? Sounds quite fragile to me ... I think we should rework the whole HDB interface to also include the copy loop and maybe throttle internally on the number of in flight buffers (blocking on interrupts if necessary
Created attachment 5511 [details] [review] Patch to not accelerate broken cases Attached is a patch that fixes the issues noted here, by simply not accelerating in those cases. It hurts performance, but it also fixes several X Test Suite errors along with the real world rendering issues noted here.
I can confirm that the last patch avoids the problem areas.
(In reply to comment #5) > We allocate a buffer, we fill the packet command, we call ADVANCE_RING() > and then fill the data... What is causing the buffer to be picked up by the > engine ? ADVANCE_RING() ? No. The indirect buffer is fired when * it becomes full; can't happen here because we BEGIN_ACCEL the whole packet length in the beginning. * FLUSH_RING() is called, which we don't explicitly (the BlockHandler eventually does). I know this is obscure, but there's really no problem. :)
Created attachment 5515 [details] [review] Handle tiling and clipping in UTS Does this patch work without the workaround?
Afraid not. It didn't change anything.
Bummer. Roland, any idea what's missing in UploadToScreen/HostDataBlit to properly deal with tiling?
(In reply to comment #11) > Bummer. Roland, any idea what's missing in UploadToScreen/HostDataBlit to > properly deal with tiling? I'm not too familiar with exa (yet), but since it looks like exa basically deals with tiling as does xaa, i.e. all pixmaps are still untiled, UTS only really seems to have a problem if the "destination pixmap" is the front buffer. No idea if this can happen but I would assume it should affect the whole screen - so I'm surprised that the original patch (5501) actually changed anything, I think I'm missing something.
Created attachment 5533 [details] [review] Change HostDataBlit interface to take dst_pitch_offset and coordinates I suspect the problem is that the HostDataBlit interface still tries to calculate backwards from just a destination pointer, so I took Eric's advice and changed it to take dst_pitch_offset and coordinates instead. Does this fix it? :}
Hrm... we should fire it at the end of the loop at least and maybe throttle on the number of indirect buffer we allocate... Right now, if we get to do a lot of HDB's between 2 block handlers we might exhaust the pool of indirect buffers... and we sort-of lose the asynchronicity of blits in some cases
(In reply to comment #14) The radeon driver only ever allocates one indirect buffer at a time so far. It should always get fired in time as commands are queued or the BlockHandler kicks in. In particular, with HostDataBlit, one indirect buffer gets allocated, filled and fired per HostDataBlit/HostDataBlitCopyPass pair. When this exhausts all available indirect buffers, the next allocation just waits until the first one has been consumed by the hardware.
Created attachment 5536 [details] [review] Change HostDataBlit interface to take dst_pitch_offset and coordinates, take two Yet another attempt - HostDataParams didn't mask the offset properly. FWIW, this one seems to work fine here with tiling.
The last patch solved the problem. Great work :)
Fixed in CVS, thanks for the suggestions Eric and testing Pierre.
*** Bug 6976 has been marked as a duplicate of this bug. ***
*** Bug 7025 has been marked as a duplicate of this bug. ***
*** Bug 7147 has been marked as a duplicate of this bug. ***
*** Bug 7201 has been marked as a duplicate of this bug. ***
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.