https://bugs.freedesktop.org/show_bug.cgi?id=44499

--- Comment #2 from Alex Deucher agd5f@yahoo.com 2012-01-05 10:02:38 PST --- Does disabling ColorTiling fix the problem?

https://bugs.freedesktop.org/show_bug.cgi?id=44499

--- Comment #4 from smoki smoki00790@gmail.com 2012-01-05 10:26:10 PST --- Created attachment 55179 --> https://bugs.freedesktop.org/attachment.cgi?id=55179 xorg log

https://bugs.freedesktop.org/show_bug.cgi?id=44499

--- Comment #6 from smoki smoki00790@gmail.com 2012-01-05 10:35:36 PST --- Created attachment 55180 --> https://bugs.freedesktop.org/attachment.cgi?id=55180 glxinfo log

https://bugs.freedesktop.org/show_bug.cgi?id=44499

--- Comment #9 from smoki smoki00790@gmail.com 2012-01-16 16:37:29 UTC --- Created attachment 55656 --> https://bugs.freedesktop.org/attachment.cgi?id=55656 oprofiled fog

https://bugs.freedesktop.org/show_bug.cgi?id=44499

--- Comment #10 from Roland Scheidegger sroland@vmware.com 2012-01-17 08:50:18 PST --- 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.

https://bugs.freedesktop.org/show_bug.cgi?id=44499

--- Comment #12 from smoki smoki00790@gmail.com ---

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.

https://bugs.freedesktop.org/show_bug.cgi?id=44499

--- Comment #14 from smoki smoki00790@gmail.com --- Created attachment 71848 --> https://bugs.freedesktop.org/attachment.cgi?id=71848&action=edit Two example images which show coruptions in alpha blended transitions with gliv

https://bugs.freedesktop.org/show_bug.cgi?id=44499

--- Comment #16 from smoki smoki00790@gmail.com --- Created attachment 72076 --> https://bugs.freedesktop.org/attachment.cgi?id=72076&action=edit corruption in gliv

https://bugs.freedesktop.org/show_bug.cgi?id=44499

--- Comment #18 from smoki smoki00790@gmail.com --- (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...

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 ;).