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.
Created attachment 100768 [details] dmesg
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?
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.
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. :)
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?
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.
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.
Can you try with 3.14? This might be a regression with Christian's pflip changes in 3.15 and 3.16.
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?
maybe they sync to vblank, then perform the front-back swap manually? That swap operation may take way too much time?
(In reply to comment #7) > can_flip returns true. Does radeon_do_pageflip() fail then? If so, can you narrow down why?
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.
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.
Can you continue narrowing down why the driver is failing to flip then?
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).
(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.
> 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.
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.
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
(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.
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 :(
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).
(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.
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.