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

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Thu Jul 26 21:42:26 PDT 2012


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

--- Comment #36 from Roland Scheidegger <sroland at vmware.com> 2012-07-26 21:42:26 PDT ---
(In reply to comment #33)
> Also, IIRC, blender uses GL_SELECT for which is currently always software. 
> There is a patch to hw accelerate it, but it never made it into master:
> http://cgit.freedesktop.org/mesa/mesa/log/?h=hw_gl_select
Oh yes that will also cause swrast (I don't know how frequent its use of
GL_SELECT vs. some random operation like DrawPixels causing fallbacks is).
That patch wouldn't help though for the classic drivers.

(In reply to comment #35)
> I'm not sure to understand all the facts ( I'm a newbie in opengl/multimedia
> programming ), maybe, as you said the best solution would be to modify Blender,
> 
> but there is one thing I don't understand: why blender is very fast if I use
> the software mode for opengl with 8.0.4 mesa lib ( by using the command "export
> LIBGL_ALWAYS_SOFTWARE=1" before running blender ) ?
> 
> is it because only the CPU power works here for opengl instructions and not the
> graphic card ? ( in this case swrast works differently ? )
> 
> it's weird to see the graphic performances decreasing when I use the normal
> mode ( graphic card acceleration ) with Blender and see the exact opposite when
> I use the software mode for opengl operations in mesa 8.0.4
Yes typically you'd expect hardware to be (much) faster.
The problem here though is however that (likely) all the drawing operations are
fairly cheap, but the graphic chip is doing nothing but constantly copying the
buffers from graphic card memory to system memory and back due to these
fallbacks. Something you don't have to do if the buffers just stay in system
memory because you only use the cpu to access them.
And the cost of that is going to kill you - now I don't know what exactly
blender is doing but when it crashed the function was called icon_draw_rect(),
so it's probably fair to assume this was some simple, small rectangle to draw.
Most likely really just a couple of pixels, but the gpu will most likely blit
an area corresponding the the whole window from card memory to system memory
(and back) for being able to draw these couple of pixels.
And if it was drawing say 20 small icons it will copy that whole large buffer
20 times back and forth...
Now as said the code in earlier mesa versions didn't have to copy the whole
buffers but could copy them partially, so the cost of the fallbacks was
generally smaller for cases like this, but on the flipside it didn't quite work
right some of the time neither. And the new code makes things easier for swrast
itself - the effort has gone to avoid fallbacks whenever possible instead.

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


More information about the mesa-dev mailing list