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]
Nope, didn't solve it. But it did change the error a bit. See attached screen
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
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
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
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. ***