Bug 44499 - r280 and xbmc - choppy menu and video playback
Summary: r280 and xbmc - choppy menu and video playback
Status: NEW
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r200 (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-05 09:58 UTC by smoki
Modified: 2014-03-01 15:01 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
dmesg log (38.89 KB, text/plain)
2012-01-05 10:25 UTC, smoki
Details
xorg log (65.24 KB, text/x-log)
2012-01-05 10:26 UTC, smoki
Details
glxinfo log (13.70 KB, application/octet-stream)
2012-01-05 10:35 UTC, smoki
Details
oprofiled blender (120.92 KB, image/png)
2012-01-16 16:36 UTC, smoki
Details
oprofiled fog (95.67 KB, image/png)
2012-01-16 16:37 UTC, smoki
Details
Two example images which show coruptions in alpha blended transitions with gliv (1.35 MB, application/gzip)
2012-12-20 11:30 UTC, smoki
Details
corruption in STK (254.59 KB, image/png)
2012-12-24 13:26 UTC, smoki
Details
corruption in gliv (1.76 MB, image/png)
2012-12-24 13:56 UTC, smoki
Details

Note You need to log in before you can comment on or make changes to this bug.
Description smoki 2012-01-05 09:58:58 UTC
After mesa commit b2596c36c8f73e8bb7a0b1679b491662aeb2f9d9 i can experianced 
choppy/micro/freezes in video playback and also going thorugh menu in xbmc
and other video players using GL based output.
 This can be also seen in many GL games menus like in ppracer/etracer, pingus (from git it now have GL option), etc.  


 Have 9d21b5dd265959b28ab1e4103fb381074ec51a08 currently and same problem. DDX
from current git, xorg 1.10.4, kernel 3.1.6.

 card:1002:5960:17af:2020

 kms.

 Debian.

 Color tilling enabled and 75 fps at 1024x768 in UT4.1 with correct rendering
50 in OpenArena. Drawing tests in gtkperf are first slow later faster.
Comment 1 Alex Deucher 2012-01-05 10:01:47 UTC
Please attach your xorg log, dmesg output, and glxinfo output.
Comment 2 Alex Deucher 2012-01-05 10:02:38 UTC
Does disabling ColorTiling fix the problem?
Comment 3 smoki 2012-01-05 10:25:25 UTC
Created attachment 55178 [details]
dmesg log
Comment 4 smoki 2012-01-05 10:26:10 UTC
Created attachment 55179 [details]
xorg log
Comment 5 smoki 2012-01-05 10:28:45 UTC
 Disabled color tiling - problem stays. 

 Blender 2.61 is the best example for slowness - someone could tried it.
Comment 6 smoki 2012-01-05 10:35:36 UTC
Created attachment 55180 [details]
glxinfo log
Comment 7 smoki 2012-01-13 07:14:35 UTC
 tests/fog is also slow on open.
Comment 8 smoki 2012-01-16 16:36:23 UTC
Created attachment 55655 [details]
oprofiled blender
Comment 9 smoki 2012-01-16 16:37:29 UTC
Created attachment 55656 [details]
oprofiled fog
Comment 10 Roland Scheidegger 2012-01-17 08:50:18 UTC
Not sure what fog test that is, but this and blender show some unaccelerated meta ops. For blender, it's caused by glDrawPixels to z buffer (which will always result in fallback for r200), for fog it's glBitmap (which could be accelerated in theory, presumably some gl state causes the fallback).

The problem might be that in earlier drivers not the whole buffer was mapped (that is, copied/untiled etc. back from video memory), only the spans affected by such swrast operations. But nowadays the whole buffers are mapped. So the cost of something like glDrawPixels of a single pixel to the depth buffer is very high (most likely approximately the same as a glDrawPixels affecting every pixel in the buffer).

I don't know how this could be solved. Generally apps should avoid these operations.
For glDrawPixels to the depth buffer, the chip can't handle outputting depth values from a pixel shader(*). One idea to accelerate this might be to output one vertex per pixel set up appropriately, for only a few pixels that sure would be way faster (might even be faster for all pixels), at least I think it should work. But meta ops can't do that.
For the glBitmap case, it's possible the state preventing acceleration to happen could be incorporated into the code, but it might not be worth the trouble.

I can't tell though if xbmc really hits any of these fallbacks. Its slowness could be due to some entirely different reason.

(*)Actually it can as this is a d3d8 feature. The driver definitely can't, and even if it could the precision would be insufficient for this feature to be really useful. Not to mention you'd need a custom r200 shader.
Comment 11 smoki 2012-12-09 23:47:26 UTC
 I see Blender is fixed now as in https://bugs.freedesktop.org/show_bug.cgi?id=47375 , thanks :).

 According to these checks for fog i've also excluded it (ctx->Fog.Enabled) also for _mesa_meta_Bitmap to test fog test (fog is test from mesa-demos/tests/fog.c) and then it showed up on screen instantly - otherwise it needs some 15 seconds to show.
Comment 12 smoki 2012-12-20 11:00:17 UTC
 OK on the main bug to mention... Good example is gliv - opengl image viewer

 http://guichaz.free.fr/gliv/

 Seems like airlied code tries to hide alpha blended transitions between images,
and because of that there are those choppiness. Previous code is very fast (pre b2596c36c8f73e8bb7a0b1679b491662aeb2f9d9), but shows coruption in alpha blended transitions. Now gliv is very slow even to open some image with this swrast map/unmap, and yes - those alpha blended transitions are not emited - instead there are hiden.

 In xbmc there was no coruptions between image transitions, and in gliv there was
but only on some of the cases with alpha blended transitions... Dont know what is the rule, but it seems only when they are not the same size, or type. etc.
Comment 13 smoki 2012-12-20 11:08:03 UTC
 So yeah, making gliv to work fast as before, but without coruptions in alpha blended transitions, and this bug can be closed :).
Comment 14 smoki 2012-12-20 11:30:56 UTC
Created attachment 71848 [details]
Two example images which show coruptions in alpha blended transitions with gliv
Comment 15 smoki 2012-12-24 13:26:57 UTC
Created attachment 72075 [details]
corruption in STK


 Actually corruption can be easely seen in supertuxkart, non-fbo case usage.

 That is before this commit, don't know why people tries to hide a problem and instead slowing down everything - that way no one can manage to see a problem and maybe manage to try to fix it ;).
Comment 16 smoki 2012-12-24 13:56:34 UTC
Created attachment 72076 [details]
corruption in gliv
Comment 17 smoki 2014-02-25 16:46:31 UTC
 Bug stil here (xorg 1.5, mesa of today git 10.2-devel and newest kernel)... and kernel 3.14-rc1+ make it even double slower :).
Comment 18 smoki 2014-03-01 15:01:23 UTC
(In reply to comment #17)
>  Bug stil here (xorg 1.5, mesa of today git 10.2-devel and newest kernel)...
> and kernel 3.14-rc1+ make it even double slower :).

http://www.phoronix.com/forums/showthread.php?96339-11-Way-Low-End-amp-Older-Open-Source-GPU-Linux-Comparison&p=401336#post401336

 3.13 is good and with 3.14-rc1 it starts to consume cca 500 MHz more CPU when gl render is used for videos ... that is not just with mplayer -vo gl, but videos in games consume exactly the same more CPU power :).

 My CPU doing everything ;).


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.