https://bugs.freedesktop.org/show_bug.cgi?id=40554
Summary: r200 falls back to software when clearing FBOs Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r200 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: stefandoesinger@gmx.at
Created an attachment (id=50814) --> (https://bugs.freedesktop.org/attachment.cgi?id=50814) Sample application
glClear(GL_COLOR_BUFFER_BIT) causes a software fallback when a FBO is bound. The line in the debug output that signals this fallback is
r200Clear: swrast clear, mask: 100
0x100 is BUFFER_BIT_COLOR0 as far as I can see, which is indeed not handled in that function. I have attached a sample application that is a side product of attempting to reproduce bug 40552. The sample doesn't crash(yet), but it reproduces the software fallback.
https://bugs.freedesktop.org/show_bug.cgi?id=40554
--- Comment #1 from Roland Scheidegger sroland@vmware.com 2011-09-02 17:21:26 PDT --- Hmm I guess at least when using the kernel_mm path (which is just _mesa_meta_Clear) there shouldn't be any swrast fallback. Not quite sure though how well fbos will actually work... The old kernel clear path is quite a mess anyway (though it has to be said fastzclear was fast...).
https://bugs.freedesktop.org/show_bug.cgi?id=40554
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #2 from Stefan Dösinger stefandoesinger@gmx.at --- This bug appears to have been fixed. I no longer get any software fallback debug output in my sample application, and the performance of Wine with FBOs is too high to suspect that there are any SW fallbacks.
https://bugs.freedesktop.org/show_bug.cgi?id=40554
--- Comment #3 from Roland Scheidegger sroland@vmware.com --- FWIW the relevant commit fixing this bug was de694b6b10b7ce23a00cd7296a955f162704ee62.
https://bugs.freedesktop.org/show_bug.cgi?id=40554
--- Comment #4 from Stefan Dösinger stefandoesinger@gmx.at --- Clearing by drawing geometry? Isn't that somewhat inefficient? Doesn't the hardware have a nicer way to deal with this?
It's now also applying ATI_fragment_shader shaders when clearing. I'll send a patch for that.
https://bugs.freedesktop.org/show_bug.cgi?id=40554
--- Comment #5 from Roland Scheidegger sroland@vmware.com --- (In reply to comment #4)
Clearing by drawing geometry? Isn't that somewhat inefficient? Doesn't the hardware have a nicer way to deal with this?
There are two normal methods how you can do ordinary buffer clears on this hw. 1) With the 2d blitter. 2) With the 3d engine (by drawing a tri/quad). In practice, both should most likely have the same performance, as it should be limited by memory bandwidth. I believe in theory the 2d blitter might be faster for this class of hardware, but IIRC you also get problems with 3d engine caches etc. Also, if you use 2d blit, you need to clear color and depth buffer separately. For depth/stencil buffer, you could use fast z clears (in some cases - it is tricky, for instance can't clear depth and stencil individually and not with pixel granularity viewport), which just sets a bit per tile saying this block is cleared. All hyperz functionality (which fast z clear is) is however defunct since dri2 (dri1 had it working mostly, was never enabled by default).
It's now also applying ATI_fragment_shader shaders when clearing. I'll send a patch for that.
Hmm yes that sounds wrong.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org