Bug 79850

Summary: [awesomenauts][radeonsi] pageflip is clearly missing vblank with vsync on
Product: DRI Reporter: Sylvain BERTRAND <sylvain.bertrand>
Component: DRM/RadeonAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED NOTABUG QA Contact:
Severity: normal    
Priority: medium    
Version: DRI git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg.0.log
none
dmesg
none
linux config file
none
dmesg.xz none

Description Sylvain BERTRAND 2014-06-09 20:36:24 UTC
Created attachment 100767 [details]
Xorg.0.log

While playing the game, I can see the page flip tearing happening at the top of the screen with vsync on.

log files included.
Comment 1 Sylvain BERTRAND 2014-06-09 20:36:58 UTC
Created attachment 100768 [details]
dmesg
Comment 2 Michel Dänzer 2014-06-10 06:30:02 UTC
Are you sure it's using page flipping? If you write 2 to /sys/module/drm/parameters/debug, do you get messages like

 [drm:radeon_crtc_page_flip] flip-ioctl() cur_fbo = ffff880100f89000, cur_bbo = ffff88000d714800

in dmesg?
Comment 3 Sylvain BERTRAND 2014-06-10 17:13:16 UTC
Created attachment 100833 [details]
linux config file

I don't get anything in dmesg after increasing drm debug to 2 in sysfs. But I wonder if the fedora rawhide debug kernel has the proper enabled options for drm debugging. I attached the linux config file to allow you to quickly check.
Comment 4 Michel Dänzer 2014-06-11 02:13:01 UTC
If /sys/module/drm/parameters/debug exists and accepts the write without error, it should work. You can easily double-check by writing e.g. 15 to it, which enables all DRM debugging output. :)
Comment 5 Sylvain BERTRAND 2014-06-11 16:43:49 UTC
Created attachment 100889 [details]
dmesg.xz

erf... you are right... I get vblank waits, but no page flips, I guess the game or mesa is doing so manually (BAD!). Then mesa or game pb?

I located another issue: vsync cannot be enabled in dota2, shall I opened another bug, or since it's an issue kind of related to that one, shall we keep going in this report?
Comment 6 Michel Dänzer 2014-06-12 07:07:04 UTC
First of all, if you are using a compositing manager, make sure it unredirects fullscreen windows. Also make sure vblank_mode isn't set to 0 in ~/.drirc or /etc/drirc or as an environment variable.

With that ruled out, we'll need to work backwards why the driver can't use page flipping. The final decision on that happens in the X driver's can_flip function in radeon_dri2.c. From a remote shell, attach gdb to the X server process and set a breakpoint on that function. If it gets called, check which of its conditions are not met.
Comment 7 Sylvain BERTRAND 2014-06-13 15:18:17 UTC
done.

can_flip returns true.

Check with the first linux 3.16, vsync still does not want to be enabled in dota2, and still the front and backbuffer swap is clearly visible in awesomenauts with vsync enabled.
Comment 8 Alex Deucher 2014-06-13 15:34:21 UTC
Can you try with 3.14?  This might be a regression with Christian's pflip changes in 3.15 and 3.16.
Comment 9 Sylvain BERTRAND 2014-06-13 16:03:50 UTC
used fedora 3.14.7, same thing.

Tried also "life goes on" game. In some levels the page flip is clearly seen and the vsync setting seems ignored (3.14 end 3.16 linux). Mesa?
Comment 10 Sylvain BERTRAND 2014-06-13 16:19:26 UTC
maybe they sync to vblank, then perform the front-back swap manually? That swap operation may take way too much time?
Comment 11 Michel Dänzer 2014-06-16 08:01:50 UTC
(In reply to comment #7)
> can_flip returns true.

Does radeon_do_pageflip() fail then? If so, can you narrow down why?
Comment 12 Michel Dänzer 2014-06-24 08:44:25 UTC
I noticed artifacts as you're describing in armagetronad. It's actually DRI2CanFlip() which failed, because the window pixmap is not the screen pixmap. This turned out to be because SDL 1.2 enables backing store when supported: https://bugzilla.libsdl.org/show_bug.cgi?id=2602

Even if awesomenauts doesn't use SDL 1.2, it might be worth disabling backing store via

 Option "BackingStore" "off"

in xorg.conf or the -bs Xorg command line switch.
Comment 13 Sylvain BERTRAND 2014-06-24 14:35:25 UTC
Disabled the backing store in xorg.conf for the radeon driver. Checked in Xorg.0.log it is properly disabled. Tested awesomenauts and life goes on.
Still happening.
Comment 14 Michel Dänzer 2014-06-24 14:39:27 UTC
Can you continue narrowing down why the driver is failing to flip then?
Comment 15 Sylvain BERTRAND 2014-06-24 16:33:14 UTC
Don't take it personally, but I don't usually work on MIT/BSD licensed code on my free time because of ethics. If AMD drops all "closed source" components for linux, then I think it will be ok.

Nevertheless, I'll see what I can reasonably do. I did shot down some pesky bugs in the DRM driver because I was refactoring the code for a custom radeon southern islands driver (I'm sylware, ask Alex. D.).

Moreover, I follow the page flip thread on DRI dev mailing list... things seems still broken there.

The fedora rawhide SDK is a pain, and my dev systems are clean 64 bits (then no steam/games debugging).
Comment 16 Michel Dänzer 2014-06-25 01:06:42 UTC
(In reply to comment #15)
> Don't take it personally,

Don't worry.

> but I don't usually work on MIT/BSD licensed code on my free time because of
> ethics.

All I'm asking is to follow the X radeon execution flow in gdb.


> Moreover, I follow the page flip thread on DRI dev mailing list... things
> seems still broken there.

Since the problem here is that page flipping is not actually used, none of that applies of course.


> The fedora rawhide SDK is a pain, and my dev systems are clean 64 bits (then
> no steam/games debugging).

Not sure how that is relevant.
Comment 17 Sylvain BERTRAND 2014-06-25 12:50:01 UTC
> All I'm asking is to follow the X radeon execution flow in gdb.
When I gdb can_flip on fedora rawhide, the inner fonction source was wrong regarding the instruction pointer.
That, probably because of code optimization, then I gdb the assembly. This is much more work. Would have been much easier recompiling with the right printf.
But I'm not interested in learning fedora SDK...
> Not sure how that is relevant.
For the reason stated above, it is, unfortunately. But you did not know.

I'll check if the instruction pointer is in sync with source code for this function.
Comment 18 Sylvain BERTRAND 2014-06-27 18:14:30 UTC
Ok... I did a bit of gdb.

It's a bloody mess, many things are optimized out and breakpoints are not working consistently.

I got the DRI2CanFlip function to return FALSE for those lines:
dri2.c:934 and dri2.c:945

That said, I was unlucky about can_flip debugging, since I hit only the TRUE returning code paths of DRI2CanFlip.
Comment 19 Sylvain BERTRAND 2014-06-29 23:10:38 UTC
news:

I did dive reluctantly into rpm dev (with debug info).

I got my self a xorg server compiled properly for debugging with gdb and its related debufinfo.

Only dri2.c:934 make DRI2CanFlip return FALSE. I check my xorg server log and I got:
[    13.506] (**) RADEON(0): Option "BackingStore" "off"
[    13.506] (**) RADEON(0): Backing store disabled
Comment 20 Michel Dänzer 2014-06-30 04:01:01 UTC
(In reply to comment #19)
> Only dri2.c:934 make DRI2CanFlip return FALSE.

That's while awesomenauts is running fullscreen? So can_flip() also returns FALSE in that case, contrary to comment #7?

Apart from backing store, possible reasons I can think of for the window pixmap not being the screen pixmap are:

* A compositing manager is running, which doesn't unredirect fullscreen windows.
  This includes things like xcompmgr -a, which doesn't involve any special
  effects like shadows or translucency.
* The awesomenauts window is redirected automatically, e.g. because it uses a
  visual which is incompatible with the root window visual.
Comment 21 Sylvain BERTRAND 2014-07-01 14:53:14 UTC
Ok. I made a mistake. I inverted the result I debugged for can_flip! It was returning FALSE not TRUE... my mistake and my bad.

Now, I got debug version of the ati dri stuff too. Still some weird breakpoint behavior though. But I managed my way with what was still consistent about breakpoint behaviour.

can_flip never returns TRUE. All the time FALSE.

Yes, awesomenauts does run full screen (1920x1200)
No compositing window manager is running (xfwm with compositing disabled).

Then we may conclude that awesomenauts is not using root pixmap flip compatible pixmaps. I guess that would be the same issue with "life goes on".
It would mean the pixmap transformation is costing too much in time regarding vblank time, making happen the swap in the middle of the visible screen.

dirty :(
Comment 22 Sylvain BERTRAND 2014-07-01 15:24:37 UTC
additional info:
 - I did swap my TAHITI XT (7970) with a JUNIPER PRO (5750), the pixmap transformation seems GPU bound since the tearing appears quite lower on JUNIPER PRO than with TAHITI XT.

 - The vsync setting seems ignored by awesomenauts (does not change anything on or off).
Comment 23 Michel Dänzer 2014-07-02 05:52:18 UTC
(In reply to comment #21)
> It would mean the pixmap transformation is costing too much in time
> regarding vblank time, making happen the swap in the middle of the visible
> screen.

When the window pixmap is not the screen pixmap, a GLX/DRI2 buffer swap involves two copies: one from the DRI2 back buffer to the window pixmap, and one from the window pixmap to the screen pixmap. It's unrealistic for the second copy to finish before the end of the vertical blank period, resulting in the visible tearing.


(In reply to comment #22)
>  - I did swap my TAHITI XT (7970) with a JUNIPER PRO (5750), the pixmap
> transformation seems GPU bound since the tearing appears quite lower on
> JUNIPER PRO than with TAHITI XT.

Could be due to EXA vs. glamor. In the latter case, the copies described above are rasterized as two triangles each, which makes the tearing more noticeable.
Comment 24 Sylvain BERTRAND 2014-07-02 15:16:23 UTC
The overall cost (sw and hw) of the code paths used to perform pixmaps to root pixmap conversion should be aggressively minimized.

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.