[Mesa-dev] [Bug 47375] Blender crash on startup after upgrade to mesa 8.0.1

[bugzilla-daemon at freedesktop.org]

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

--- Comment #34 from Roland Scheidegger <sroland at 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.