[Bug 44499] r280 and xbmc - choppy menu and video playback

[bugzilla-daemon@freedesktop.org]

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.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.