On 06/24/2015 08:00 PM, Alex Deucher wrote:
On Sun, Jun 21, 2015 at 6:36 PM, Mario Kleiner
<[email protected]> wrote:
On 06/05/2015 03:10 PM, Alex Deucher wrote:

On Fri, Jun 5, 2015 at 8:33 AM, Mario Kleiner
<[email protected]> wrote:

Mismatched tile split bits between source pixmap
and target screen pixmap caused present_check_flip
to reject page flips on at least RV730 (Radeon HD 4670).
(Source pixmap had 0x1, Target screen pixmap had 0x6000001)

Mask those tile split bits out to make the check pass and
page flipping under DRI3/Present work.

Maybe we should mask out more bits?


I'm not sure if it's safe to do that.  Tile split is part of the
tiling configuration in the display registers on evergreen and newer.
It's probably better to try and figure out why the surfaces end up
with different tiling parameters and fix that.

Alex


Alex, you're right. Just sent out a new patch which hopefully fixes it
properly for pre-evergreen, at least it seems to do so in my testing.

While looking at it, i found one minor thing which i don't know if it
matters, probably not, so just fyi:


eg_tile_split() in evergreen_accel.c and eg_tile_split_opp() in
radeon_bo_helper.c of the ddx assign the "default" case in the the
switch(tile_split) statements inconsistently, iow. eg_tile_split_opp() isn't
the "inverse" of eg_tile_split():

eg_tile_split(): default: and 4096 bytes map to flag 6.
eg_tile_split_opp(): default and flag 4 map to 1024 bytes.

Mesa otoh does it consistently:

src/gallium/drivers/r600/evergreen_state.c:
eg_tile_split(): default and 1024 bytes map to flag 4.

src/gallium/winsys/radeon/drm/radeon_drm_bo.c:

eg_tile_split(): default and flag 4 map to 1024 bytes.
eg_tile_split_rev(): default and 1024 bytes map to flag 4.

So it seems the eg_tile_split() "default" case in the ddx evergreen_accel.c
is inconsistent with other definitions.

That should probably be fixed up.

Alex


I'll prepare a patch to fix that one mismatched default, so default: always maps to flag 4.

thanks,
-mario
_______________________________________________
xorg-driver-ati mailing list
[email protected]
http://lists.x.org/mailman/listinfo/xorg-driver-ati

Reply via email to