https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #34 from Roland Scheidegger <srol...@vmware.com> 2012-07-26 20:24:37 PDT --- (In reply to comment #31) > Unfortunately I think this is expected. Previously swrast didn't map whole > buffers, only parts of them. For much simpler and more robust code though > swrast fallbacks now maps the full buffers, an operation which is hideously > expensive at least with radeons (as you've got to blit back the buffers from > the card memory to system memory). I believe blender draws some little things > on a large buffer, so the performance of the swrast fallback is fully > dominated > by copying the buffers around, the actual cost of the drawing operation in the > swrast fallback is completely irrelevant. This is also why it's much faster to > just use swrast to begin with as then you don't need to copy the buffers > around > (you should see this if you some some profiling tool like sysprof, oprofile, > perf). > I'm not sure how this could be solved really, I think the best option would be > to modify blender so it doesn't rely on these legacy features leading to > fallbacks. Or similarly try to accelerate these in metaops so it doesn't need > to fallback. > A third option would be to try to figure out the area accessed and only map > those parts (to swrast it would still look like the whole buffer would be > mapped to keep things simple, but the driver would only blit the needed > parts). > The infrastructure for that isn't there and I'm not sure it's desired in any > case, and it would probably only work for the draw buffers and not for > textures > neither. Forgot to mention, there's also another possible problem which could be avoided in the driver: it currently will do all the copying of the whole buffer always. Suppose the app does several glDrawPixels calls each just drawing a couple of pixels and each resulting in a fallback (I don't know if that is really happening with blender but it would be quite possible). The driver will do the whole-buffer copy for each of these calls - it would be possible to defer that (until the buffer is used for accelerated drawing again, so if the app does several DrawPixels some resulting in fallbacks some not it wouldn't help). But noone is really working much on these drivers nowadays. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
