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.
Please attach your xorg log, dmesg output, and glxinfo output.
Does disabling ColorTiling fix the problem?
Created attachment 55178 [details] dmesg log
Created attachment 55179 [details] xorg log
Disabled color tiling - problem stays. Blender 2.61 is the best example for slowness - someone could tried it.
Created attachment 55180 [details] glxinfo log
tests/fog is also slow on open.
Created attachment 55655 [details] oprofiled blender
Created attachment 55656 [details] oprofiled fog
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.
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.
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.
So yeah, making gliv to work fast as before, but without coruptions in alpha blended transitions, and this bug can be closed :).
Created attachment 71848 [details] Two example images which show coruptions in alpha blended transitions with gliv
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 ;).
Created attachment 72076 [details] corruption in gliv
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 :).
(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. How we collect and use information is described in our Privacy Policy.